The Only Design Guidelines You'll Ever Need

For a variety of reasons, I've been thinking a lot about design and usability guidelines. I'm often asked, "What's the standard?" or "What's the best way to do such-and-such?" Well, as anyone who's worked in design knows, the answer is: It depends. Now, that's nothing new, but this morning I've formulated a new set of "über-guidelines", if you will.

1) If you have guidelines and they have been proven with users, follow them.
2) If you have guidelines and they have not been proven with users, follow them for consistency (and offer to prove--and improve--them).
3) If you do not have guidelines, develop and let users prove them.
4) If you do not have guidelines, nor the time to develop and prove them, the designer gets to pick. Just be consistent.

Beyond that, it's a matter of opinion, and the designer--who (by definition) is in the role of, um, "designer"--wins.

Usability and Forms: Default Values

I have a client with whom I've had several lively debates about when to use default values in a complex form. I have searched for studies, writings or heuristic references with no luck. In the mean time, until someone points to better work that someone else has done, I offer the following suggestions for when default values are appropriate:

1. If you are trying to save the user mouse-clicks.
   If you don't care because the form isn't complex enough or you don't have the time or resources to define and implement default values, then don't bother.
2. If the user of the system would most likely select the option chosen.
   If 80% of your audience is U.S., then make U.S. the default with the option to change. (Don't, however, put U.S. on the top, if you care about having an equitable, global form.)
3. If the user is not being asked to make a declaration for legal or compliance purposes.
   Don't default them to the "correct" answer if you want them to make an explicit electronic declaration. Don't default them to the "incorrect" answer, either to make them pick the "correct" answer. A recent usability test I conducted on just such a page showed us that users expect a defaulted answer to be the "correct" answer.
4. If the default option is the "right" option.
   See 3. above.

Additionally, user expectations would be that, if you are providing default values for some controls in a form, you would provide default values for most similar controls in the form (for example, all yes/no combinations or all dropdown selectors would behave similarly).

Don't Assume: Usability in Enterprise Applications

Our organization has a thing we call "Enterprise Applications". It is used to describe applications that are used across the various business groups within the company, and it's also used to describe the people who work on those applications.

Many of the applications are third-party. There are big, BIG players in that space: for customer relationship management, finance, employee forms, HR functions, training records, procurement, and...you get the drift.

My understanding is that there are always efforts underway to unify and integrate the data that is behind all of these systems. I choose to think that's a good thing. Data is great. We all need data.

As a usability engineer, I am often conducting interviews with users of corporate systems to learn about their needs and behaviors. Without fail, when talking about the current process or system, one of these "enterprise" system comes up, and they ask me if I can make it work better. (I have found that some do not distinguish it from the system we are talking about--"IT is IT", which is a fair assessment, or they see our conversation as an opportunity to get a word in with someone who claims to understand usability--a "while we're on the subject..." sort of thing).

Over and over again, we roll out awful user interfaces that come out of the box with the software. We have the expectation that the manufacturer has a huge staff of user experience engineers and has done the research and design to make usable software.

In my informal inquiries into this, I've found that it's usually due to some combination of the following issues. The evaluators and implementers (usually IT people):

• thought it was usable out of the box
• relied on the hope the manufacturer has a huge staff of user experience engineers who did research and design to make usable software
• fixed a couple of things they saw, but did so without involving users
• felt usability work would add expense to the project
• obtained inadequate or incomplete usability services
• never even considered usability

The applications I use on a day to day basis in this arena seem to have been designed primarily for those who are in data-centric roles in the organization. Then some of the functions are stripped away so the average user can use it. Very little, if any, consideration for what they are trying to accomplish.

Here are some lessons I've learned:

1. When evaluating third-party software, include sufficient usability work.

• An heuristic evaluation by one or more "experts", but not enough to say you've done usability work. In the end, the users are the experts in whether or not it's usable.
  
• Well-formed usability engineering does not add to the long-term cost of a project. In fact, it can save money (on training and support costs, to name a couple) and increase employee satisfaction.

2. When implementing third-party software, ensure you have well-defined audiences and clear usage scenarios.

• That doesn't have to mean a 257-page document of every use case including alternates and dependencies.
• A data-centric user interface is great for the 20% of users who understand the data; the other 80% of task-centric users probably need a different interface to support their tasks.
• Knowing your audience and usage scenarios can help you design for effectiveness, as well as usability testing throughout the implementation process.

3. When rolling out third-party software, ensure that users have ample warning, training, reference and help available.

• Don't drop a specialized application on everyone's desktop and expect everyone to immediately understand it or "figure it out".
• Remember that different people have different learning styles, so a multi-pronged approach is good.
  
• Don't assume that the third-party software manufacturer has done good human-centered design. They may have designed a convenient way to manipulate their data, but they are not the experts in how your employees do their jobs.

Usability and Frame of Reference, or "Dude, I'm Not In Your Head"

A musical friend of mine sent me an e-mail with a reference to the following site:

http://looney.goldenagecartoons.com/tv/bbrr/

with the following amusing description:

...for a few of you musical pals of mine, I was just browsing the Bugs Bunny Road Runner Hour home page (a history of that show, just because I loved it), and I came across this fantastic paragraph. Seriously, this is a copy and paste directly from their page. Read on.
--Norah

--
The musical phrase utilized for all of the titles of all Bugs Bunny cartoon shorts, the Tweety-and-Sylvester cartoons with them posed on stage and Sylvester holding Tweety in his hand, and most cartoons with characters other than the regulars, went as follows:

"Da-da-da... da-da. Da-da-da... da-da. Da-da-da-da-da-da. Da."

....Music with the tree-oriented title cards of Tweety-and-Sylvester cartoons, all cartoons titled with the semi-circle of Foghorn, Pepe, Speedy, Yosemite Sam, and Elmer, and all Road Runner cartoons, was a variation on the phrase opening the original theatrical Looney Tunes from the 1940s, 1950s and early 1960s, combined with the closing motif from post-1964 cartoon shorts. First used for cartoons shown on The Road Runner Show, it sounded like this:

"Da. Da-da-da... da-da... da. Da. Da-da-da... da-da-da. DAAA! Da."

Right. So, here's what I get from those musical references:

1. They are instrumental
2. A vague indication of note duration.

Here's what I don't get from those phrases:

1. Meter
2. Actual note durations
3. Actual musical pitches

I don't know about you, but I think actual musical pitches are pretty important in, well, music. (My friend said "I can make a case for the first sequence being the Jurrasic Park theme...")

This reminded me that I had seen some time ago a discussion of how to express music using ASCII notation. A search turned up the following: http://www.wildebst.demon.co.uk/filks/PMS.html

which refers to Phillip Hazel's music writer: http://www.quercite.com/pmw.html

The idea of communicating many aspects of a language (music) in a relatively primitive medium is academically interesting if not entirely practical.

That said, the real point to the story is: don't assume we all hear the music in your head.

Ropes from the Moon

Several things got me thinking about the way we direct traffic recently:

• During reconstruction of the I-35 bridge over the Mississippi River in Minneapolis, lines and lanes were re-drawn on several other major roads to accommodate the extra traffic. After the bridge was finished, some of the re-drawn lines worked so well, they have remained.
• On winter roads covered with ice (or black ice), it's not possible to see the lane dividers.

What if we could have the lane markings always "on top", and easily changed to accommodate rush hour, presidential motorcades, HOV lanes, and so on?

Like football games on television, where they do that cool yard-line marker which is smart enough to go behind the players...or those Bluetooth projected keyboards, and Smartboard technology.

Couldn't we project the lane markers on top of the roads? Now, I recognize that out in the country, you can't project lane markers from outer space*, but in the city, near intersections, we have the infrastructure of lights and signage to house projectors.

Someone else has a similar idea to create your own bike lane: http://blog.wired.com/cars/2009/02/lightlanes-lase.html

I don't know how legal that is, but I love the idea.

---------------------------------
*Reminds me of an infamous grade-school prank. This may be an old wive's tale, but someone told me it happened to them:

(Phone rings)
Victim: Hello?
Prankster: Hello, is Mr. Wall there?
(you know mostly where this is going, but stay with me here...)
Victim: Um, no, I think you have the wrong number.
Prankster: What about Mrs. Wall?
Victim: No, you must have the wrong number. There are no Walls here.
Prankster: Then how do you keep your roof up? Haha!
Victim: WE HAVE ROPES FROM THE MOON. Haha!

Usability and the Wii, Age 6

Playing Little League World Series Baseball on the Wii for the first time with my 6-year-old. (He said he'd "go easy on me" since I had never played.)

While batting, I was having trouble making contact with the ball. The timing was difficult to figure out. There are all these gauges and symbols on the screen that I didn't understand, so the conversation went something like this:

Me: Is there something I can look at on the screen that shows me when I should swing the bat?

Joe: No....well, actually, yes. THE BALL.

Me: Ha-ha. I meant a gauge or something.

Joe: Ha-ha. Yes, I knew what you meant.

Driving and Usability (Loosely)

After a frustrating drive home yesterday, I started thinking about turn signals, why they're important, and why people use (or don't use) them. So, I did a highly informal survey with a very small pool (okay, 5 people that I know personally). Here are the results:

Of the people surveyed:

• 20% claim to use turn signals all the time (Group A)
• 80% admit to not using them all the time (Group B)
• 0% claim to never use them (Group C)

When asked why they don't use turn signals all the time, those in Group B responded that they usually just forget.

Now, I believe there are people in Group C, though I haven't met any (self-admitted, that is). I also believe the pool I found is somewhat skewed, because these are all people close to me, and I usually hang out with considerate people who drive reasonable vehicles and understand that the road and everything on it does not belong to them.

I also searched to see what had been written already about this topic. I should have known that Don Norman had an article about signals. His take is more on how we might get our machines to be as expressive as human faces, but I was intrigued by the bits about the importance of signals in communication and understanding.

http://www.jnd.org/dn.mss/chapter_11_turn_sig.html

When I cycled to work the last two summers, I noticed that the other cyclists smile, wave and greet each other while commuting. I had people ask if I need help when I was fixing a chain. I remember growing up in small-ish towns where people would drive down the main streets and wave to each other.

This doesn't happen in our cars any more. Our obscenely big-assed cars have so many amenities that we have grown accustomed to treating them as isolated bubbles of human existence--an extension of our private living space.

But they're not. We are interacting with the world when we are piloting a moving vehicle among moving vehicles with other pilots.

So, dude: use your turn signal.