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.
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.
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).
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.
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.
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).
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?
How do I do it?
The "best" format depends on the task at hand.
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 ...
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).