Think like a user

One key activity in customer relationship management is figuring out where the customer heard of your product. This is often accomplished by a single, innocuous-seeming, but actually critical question on feedback forms: "Where did you hear about us?" For websites, the question is more often couched as: "how did you find us?" The list of answers typically includes "Google," "Print ad," "radio ad," and so on.

Shopping for a new dishwasher recently, I was particularly impressed by the last choice in such a list on the Maytag site: "Guessed the URL." That URL, maytag.com, might seem obvious to the average random web surfer (as it surely is). But, far too often, site designers, even when the company brand is a substantial asset, think like company employees. So, rather than two easy clicks to a product manual, we find two easy clicks to the biographic information on the founders. And, rather than a site map that mirrors the product line, we find a site map that mirrors the org chart, or latest marketing presentation. Product information and customer service is relegated to a sub-branch, or even to a secondary site ("acme-products.com"), while the branded name ("acme.com") is wasted on stock quotes.

Kudos to Maytag, for recognizing that users will, in fact, guess the URL. And good luck to anyone trying to get product information from Sony.


There's more than one book

In the early days of UI design, usability professionals often found themselves acting as usability advocates - forced to defend the value of spending time and resources on making interactions easy. Now that UI has become an accepted value-added for software and websites (and electronics in general), we have another problem.

"So, what are the four F's?," a potential client asked recently. I'm guessing they're Feasibility, Functionality, Form and Future, but I really couldn't tell you for sure. An author of some popular book on UI basics has made them a key phrase, however, and therefore this person expected them to be a given in the field.

A local UI consulting firm offers a more standardized way of evaluating potential UI consultants: they have a certification program. The UI quiz on their website (http://www.humanfactors.com) offers the following question:

Color should not be used in web page design:
a. To show relationships
b. As a code
c. To aid in scanning
d. In many hues
e. To draw attention

These folks think the correct answer is D. A designer who is mostly concerned with esthetic issues would probably agree. A designer who is concerned with universal access would choose A or B, however; 10% of males of Northern European descent are red/green colorblind, and using color to convey critical information risks shutting them out of the interaction. When using color to aid scanning (answer C), the potential problems are even more severe - that kind of perception is usually based on luminance contrast, not hue. If the color chosen to highlight some types of information was the same luminance as the base text color, and the color chosen to highlight others was not, the first information would likely be passed over. Using color to draw attention (answer E) is also problematic - different colors have different psychological effects on the reader. Using color as an attention grabber risks conveying psychological information that may have been unintended.


UI tip of the week: When determining project scope, visit MoSCoW

Clients or project members often approach a new design with a stack of ideas for what should be included. Initial project meetings often include a brainstorming session, either formally arranged (particularly when use cases are being discussed), or arising naturally out of planning discussions. How should this, sometimes overwhelming, pile of stuff be handled?

One way to start the sort is by using the Moscow technique. Write the desired list of interactions and functionalities on index cards or sticky notes. Then, have a meeting with the project principals to arrange them into four piles:

By separating out the drop dead requirements from the rest, project clients can identify what they really want as the core scope of the project, and critical requirements won't get lost in the shuffle. Designers and programmers, on the other hand, get some wiggle room with the rest of the list, and can make judgment calls on whether to spend critical time on things that are only Shoulds or Coulds. The Woulds become a catch-all for things that participants want mentioned somewhere in the planning docs, but don't necessarily want implemented this time around (you'll be amazed at the size of this pile).


Edges are about light, not hue

As most art students know, color has two components - hue and saturation. Things that are less saturated appear to be "lighter." As most biology students know, eyes have two kinds of receptors - rods (which respond to light and dark) and cones (which respond to color). What many designers don't know, however, is that the part of the visual system that detects edges is light based, not hue based.

Why care?

The most obvious reason to care is that, when presenting active areas on websites (buttons, image maps), it is best to have a defined boundary. Using hue differences isn't enough - folks will be able to identify the center of the area, but will have to think about it more than they wanted to. The less obvious, but more insidious, reason is that text recognition is entirely edge-based. As the saturation of the text and background get closer and closer, therefore, text gets harder and harder to read.

What do I do about it?

When choosing colors for text and background, avoid non-websafe colors like the plague (dithering screws up the edges). And chose colors from opposite ends of the saturation chart (not just the color wheel).

(For more information about dithering and websafe colors, check out Lynda Weinman's explanation)


"Tab Order" for fun and profit

Visual browsers are optimized for point-and-click. Expert users, however, know they can use the "tab" key to jump from link to link and from field to field in a form.

Why care?

  1. Forms typically include an action button at the end of the entry fields. However - users tabbing through a page or form are far more likely to over-tab (hit the key too many times) than under-tab. So, if you're asking people to fill out a form that can't be easily canceled (Buy, Subscribe, Join, Commit), DON'T put the action key last in the tab order. It's a lot easier to re-fill a form than to cancel a credit card charge. (Designers often include a "clear form" button - last is a good place for this).
  2. Screen readers and verbal interfaces can be used to tab from link to link in a web page. Users of those devices often have no other way to navigate around the site. However - typical designs often recreate an entire site menu at the top of each page, forcing these users to endlessly tab through the same information before they can get to page content. If those menus are skipped, the site will present a far more usable and less frustrating experience.

How do I do it?

  1. Tab order in a page is by default from left to right and then top to bottom, the same way English text is read. For forms, it's best to match the tab order to the visual appearance, so making sure the action button isn't last on the page will insure it isn't last in the tab order.
  2. Tab order can be specified in a link or field definition using the "tabindex" attribute. This will specify the tab order for Netscape 6.x and the later versions of IE, but will not work in older browsers.
  3. Tab order through a table is left to right and then top to bottom, reading the contents of each cell completely before going over to the next one, and reading across an entire row of cells before going down to the next row (the same rendering scheme as non-graphical browsers). If it REALLY matters, use appropriately nested tables to force any browser to parse the page in the proper order.

There's no such thing as the best format

The "best" format depends on the task at hand.

Consider the humble date selection menu. We have two options:

Which is better?

People don't usually think of months by their number ("Well the kids were home from school so it must have been 07, though I don't think it was 08 yet..."). So if you're asking about events, selecting the month by its name is going to be easier for the user, and ultimately more accurate.

However: Credit cards DO list expiration dates by the month number. Users transcribing data don't bother to translate it into the more common form. So when you're asking a user to enter the expiry date of their credit card, give them a number-based menu.

And in either case, make the default menu choice look different from the other menu choices (not just "January"), so users can tell if they've accidentally skipped a response:


Page titles matter

Why should the page title at the very top of the browser window matter? After all, if someone is looking at your site the text in the center of the screen is vastly more noticeable, flashy graphics and all.

But try minimizing your browser window. The page title becomes the text next to the browser icon. Is your site named "welcome"? So is everybody elses ...


People just copy examples

Good technical writing includes examples of code and interaction in addition to explanations. But people just learning a program (or any other interaction system, including language) start out by copying and adapting known utterances, without much thought about what the individual parts really mean.

Why is this relevant to UI? We present the following true life example example, from the instruction manual for a database program that shall remain nameless, on how to set up a mass mailing for all addresses from several specified states:

UT OR AL OR OR OR NY

Question - What happens when users who have never studied Boolean logic swap out the states in the example for the states they want to use?
(Answer - lots of extra junk mail going to Oregon).