The Dichotomy of being in UX

The age-old question most people in UX ask:

Am I a designer, or in research (via usability testing)?

For me, right now, I'm in both. I know under conventional wisdom of a usability practitioner or designer, this is a big no-no; though we do have at least one other person as a researcher so I'm off the hook for that. However, the second side of that is my colleague is starting to be trained to do some interaction designing. While that's good for the interim, it's not a good long-term solution. It's overhead that we don't need especially at times when much needs to be tested. So right now, we're in need of a great UX Designer.

It has been said time and time again - the people who test should not code. The people who code, should not test. And now, the people who design should not test nor code and vice-versa. But what happens when there's not enough manpower to cover the two parts required in better UX? One person does the designing, the other the testing - but we're not.

I come from a background where it was quite good training in Industrial Design to be able to design, test and redesign through iterations and different phases. And yes, it was indeed challenging to build up a certain amount of objectivity because there is so much emotional energy invested into the prototype and project. But that was a near virtual world, an ideal world where one person could do the amount of work of several, so I don't think it applies here as much.

Yes, more skills are being built and an understanding of the interaction elements in a U.I. is being formed when one person does the job of two. But it will need to end some time soon so we can operate entirely on our strengths and what we want to do, not just what we'll settle on for convenience sake.

There is also a battle in the mind whenever I come across a design I need to redo because of the test results I obtained. While I can remain objective, I can still feel it's not 100%. So now, we test each other's designs.

In the real world, there are teams of people. For a UX Team, there are people who are generalists and those who specialize. This article says it very well. I would think of myself as a generalists with some very good design skills - and I know I'm not the best designer. I also find the most challenging and rewarding part to be the research portion by heading the mockup off at the pass. I consider my analytical skills to be better than my designing skills.

I've heard somewhere:

"It's only when we can operate on our strengths can those around us operate the same way."

So, how about it?

Fear and Usability

Here's a short.

Last week, I learned something that I shared with my colleagues and I am going to share with you right now.

Apparently, there was fear in our UX Team that some of our clients (who were also our participants) in our usability sessions, would do nothing but complain about their problems because of support or implementation issues. The fear was based on how they would undermine our efforts and make a debacle of testing our new application.

Well, if you happen to have such issues, worry no longer.

I told them:

"Firstly, there is no proof that this is going to happen."

"Second, if all we do is make things up and dwell on them, they just might come true. So in this sense, focus will quash any kind of worry."

One thing I said to calm my colleagues was the fact that based on my own experiences:

"Once they see a new screen and that's all they see, and you listen to them with keen ears, all their worries that could become vicious attacks, all disappear. This is because they're concentrating on giving you proper feedback to your study."

Have your participants focus on the task at hand and this will give you the results you want.

Google Chrome - Part 2

Okay, so I haven't really used Google Chrome all that much since I've installed it.  I think that say something about the new browser so many other people are talking about.

Anyway, here's some other things I've discovered:

9.  There's an "incognito" window where cookies, browsing history and other personal information that can be recorded are erased after the browser has been closed.  This leaves no trace for any websites to track the user's whereabouts and browsing habits.  How useful is this really?  Well, you can decide for yourself.

10.  I like the fact that my gmail account is integrated with my blog account using Google Chrome without having to click on the "remember me" checkbox.  A small thing indeed.  I'm just slightly hesitant on having my default Firefox 3 browser remember me for some strange, inexplicable reason.

11.  You can create shortcuts to your desktop easily of websites you've visited.  I haven't done this by doing this manually.  I'm guessing Google figured it's not being done because it's too involved?  Perhaps, but it also could be that not everyone thinks of webpages on the desktop.  The desktop is for documents and applications, not for websites.  This particular user habit would be very hard to change.

12.  It doesn't work well at all with Facebook - a site I frequent daily.  I don't know how many other applications it doesn't like.  Feel free to post a comment to let me know.

All in all, if Google is trying to shift the paradigm of the browser and the mental model of the user and they've completely failed at it.  While it may be embraceable, as it is now, it's not enough of a change to take notice - which is why I've barely touched it from the install date.  If however, they're doing it incrementally, they may have something.  But I believe most of all, it's a great browser for Google to facilitate the impending release of their new smartphone, with the Android O/S installed.  It's also a great way to increase their search engine business aided by mobile computing.

So really, Google Chrome is nothing more than just another browser, for now.  And without any sparkly bits.

First Impressions of Google Chrome

The first thing I notice about this supposedly new browser is that the user's mental model has shifted ever so slightly.  The deviation is enough to make it different from other browsers like Firefox but not too drastic so that it's embraceable.  Here's what's different:

1.  Screen real estate has been given back to the user with the omission of the File/Edit... menu system.  Google's take is that we really do not need that technology.  The message they're sending is that the content is what's most important, not the adminsitrative functions.

2.  It's the tabs that encapsulate the experience - and because of that, the integrated URL and Search field are within the tabs, not the other way around as in Firefox.

3.  The URL and Search fields are one and the same - it's integrated.  Now is the time when simple english can be entered into the URL field instead trying to remember some dot-com address.  You can also choose your own search engine for this integration (though I haven't tried anything other than Google just yet).  This in turn means that search engines will be more important than ever in managing content on the Internet.  It's a push that helps Google's business model.

4.  I can't seem to find my bookmarks in a way I'd like to access them.  It's using cascading menus instead of the stationary left-panel which requires more motor control - which could present a problem to some less-abled users.

5.  Well, I just demoed the application to my colleague showing the integrated URL and Search field and it just crashed my Firefox as it was running at the same time.  Bug!

6.  Transparent administrative and status functions - they don't appear unless you want them or that they show something important.  I'm guessing the whole idea still is to give the screen real estate back to the user.

7.  When creating a new tab to view, you are instantly brought to your most visited sites as a layout preview as well as a short list of the most recent bookmarks.  While this is a great idea, I'm not always insterested in what I've just viewed or bookmarked.  It's a good thing they've kept the "Open in new tab" function when I come across a link.

8.  It's much faster than Firefox 3.

I'll be adding more to this in the near future so please stay tuned.

Anticipatory design done correctly

(This posting was written in November of 2007 and posted finally today.)

(Beware of some car-speak.) I was looking for a specific part for my car because the coolant was leaking from the thermostat plug to the ground. This part was an o-ring and it fit around a plug. The problem was that I didn't want an OEM (original equipment by manufacturer) part as that part is defective and doesn't take into consideration temperature variances, hence the leaking. So began my search through the forums and I took some keywords to Google where I found a supplier. Here's the website: http://www.mcmaster.com At first glance, I wondered if I was in the correct place. But what I've noticed in many e-commerce parts sites is that functionality is high, given that you can find the part, and the usability is somewhat low. That's evidenced by sites like NAPA, AutoZone and AdvancedAutoParts. 99% of the time, you have to go to the store to get the part for a specific vehicle. If the part isn't online after executing a search (especially on obscure parts), it's either not cataloged or the system is incomplete.

Taking a look at the McMaster website, its purpose is different. Among all the thousands of different mechanical parts, hardware and software, the user begins by generating a scent using the search functionality. However, this is no ordinary search engine. At first, I wasn't sure what to type in, so I just entered the part number I found. Results came back positive and that was easy. But the kicker came in my second search where I entered "battery terminal covers". And immediately, anticipatory design kicked-in. A list of suggestions came up for me to select. There were no part numbers or items without pictures. Upon selecting the correct category, part numbers and their corresponding part numbers came on-screen.

Now THIS is what e-commerce should be! I think those other automotive vendors could learn something from McMaster.

Be definitive in your recommendations

...especially when you know a principle you've learned and you need to share that information.

There are times when recommendations are needed because others' expertise are not sufficient. What I'm finding with most people in UX is that they use the word "depends" almost like it's their second breath. I believe there are times that the word "depends" doesn't always work. It can sometimes be misconstrued that we in UX do not know what we're talking about - and because of that, it becomes a credibility issue.

One of the things I very much dislike in people is wishy-washiness, much like how the cartoon Charlie Brown used to be. I'd rather have a definitive answer with options than to just say "depends". I think we owe it to the people we're serving because they don't think like us. To the developers, to the managers out there whom we've been confusing all those times, we need to communicate in such a way that brings home the point.

One thing I like to do is to give the people I serve, options. Options meaning ways to solve an issue or problem because ultimately, it's to the developer or the manager's judgment to go about how they will accomplish the usability objective. Their code and their management makes the product work behind the scenes, so we UX practitioners need to be definitive because the developers and managers are definitive.

No one ever got anywhere being on the fence - they usually get speared by the tip sitting on it too long.

Users will do what it takes to make it work

Are your users trying to be too nice? Are they not telling you the truth? One of the things they also might be doing is to do what it takes to make your software application work - even if it means making them cry.

From the user testing I've seen so far, time and time again I keep seeing the same thing. There are times when the user will do all this other stuff in order to make the application work. All this other stuff meaning having to create additional reports, compiling data into more usable forms, etc...

This is where usability actually fills in the gap. Contextual inquiry is the best method to get at these pain points and to create better efficiencies. It's usually the case wherever there's a case of organizational inefficiency does the user create secondary tasks to compensate for the application's lack functionality.

So build it in! I was once told by a colleague that the user should keep their calculator at hand when going through a financial transaction. That's not the point! To make the user adapt and adjust to our applications by these secondary methods only means that the design isn't good enough. And besides, isn't computing power a lot quicker than that of a calculator?

So when the next time you have a session and you see that the user is really trying, and may be going beyond their immediately means to complete the task, that may tell you something. It might mean back to the drawing board.