Compete on Usability

Visualizations described with Chernoff faces

My final project on information visualizations was well received by my professor and class, so I want to share it here for thoughts and comments.  The goal of the project was to synthesize the key guidelines about creating visualizations and invite exploration of the subject, even from people not well versed in it.

Chernoff faces of vizualization (PDF, 32Kb)

I used information glyphs called Chernoff faces, line drawing cartoons where each face stands for a record and each part of the facial expression, one data dimension. The literature on Chernoff faces is mixed. Some sources report they can be effective at quick categorization of large, detailed datasets.  Other research seems to show they can lead to confusion and distraction, as people read emotions that the glyphs didn't intend to display.

Even if the use of Chernoff faces is not as well-regarded as scatter plots and Tufte railroad maps, I think the project was successful in inviting exploration of the subject in multiple ways.  One reason I chose Chernoff faces was they're a little humorous. I had a long, intense semester's worth of detail to summarize, and I knew I had some burnout to overcome.  It's okay to be a little goofy sometimes, if it gives you fresh energy for an important project.

As a result, I felt really good working on this project, from start to finish. Not only was I in flow the whole time, at the end all the work I put in came together efficiently.  My preparation was enough, but not too much, and the final layout almost assembled itself.  I hope you enjoy the visualization too.

Thinking visually

One reason I haven't been blogging often is the graduate course I'm taking in information visualization.  Not only does it consume most of my free time, it's raised my mental bar for blog posts. There are several reasons I want to have better visuals to encompass my posted thoughts.

Usable information visuals break you out of text's serial tyranny.  It's the nature of verbal information to be linear, but visual encourage divergent, nonlinear thinking. As a consequence of this, techniques like mind mapping are great visualizations for creativity, even if they're composed of pure words. On the other hand, linear outlines are fine for organizing one's thoughts when writing a paper, but they're a poor way to take notes or categorize information for learning.

Unfortunately, one thing holding me back is poor drawing and sketching skills. Multiple books I've read claim that you don't need drawing skills to communicate and persuade with sketches. But I've endured one too many patronizing smiles from peers over my stick figures, spindly lines, and lack of perspective. There's nothing for this except a little guidance and learning, and a lot of practice. Perhaps over the summer, I'll convert this blog to documenting some self-assigned drawing work.  I hope I still have readers left by September!

There's nothing wrong with pencil and paper, but if you want to share sketches with your work team, it's helpful to create them directly on a computer. Some of my coworkers use slick tablet PCs for this, but I need a more conventional, powerful PC laptop that can run Visio and Photoshop at the same time without bogging down.  (As an aside, why isn't there a multitouch tablet Mac?)

Our product is like a ... ?

Following up on last week's brainstorming metaphors post, here's another exercise to generate ideas about positioning your website or product for users.  Say "Our product is like a (noun)," from a set of well known brands or products, and you'll brainstorm product attributes and comparisons. Use these to define and reveal your product.

At its most basic level, the exercise comes down to one sentence, relating your system to well known brands or products. For example, start with "Our [product, website] is like a [Mercedes, iPhone, 4-star hotel, or screwdriver]."  Asking a group of coworkers to answer this question is easy, and it can yield surprising results.

Follow up on the one sentence by asking people about the comparison. Dig into the details until you're sure you understand all the implications. List them, then figure out what makes the attribute true for the product. For example how might eBay be compared to a car?

If I had to choose from cars, eBay is like my parents' minivan.

Why a minivan, and why your parent's?

Well, you can pick up just about anything in it, but it's not flashy or stylish, and it's a little slow and messy.

More on brainstorming

• Balancing brainstorming participants (IxDA)
• Negative brainstorming (ACM Digital Library)
• Brainstorming methods (Usability Body of Knowledge)

Brainstorming via metaphors

I learned a great user experience technique last week that could be helpful in many organizations, even among peers who might greet card sorting or other collaborative methods with a jaded eye roll.  Metaphor problem solving aids the early design process by relating interface choices to a well-known source model in the real world.

Of course, metaphor and mental models are integral to developing almost any graphical user interface, but this is different.  Your source model is not for getting specific ideas about interface design. Think of it more like a checklist. 

Start by choosing a familiar business domain in the real world.  List attributes of the business. Then map them to your software or website. A partial example:

Source: fast food	Target: ecommerce
Cash registers	PayPal widget, shopping cart
Salesperson	Avatar, live chat, affiliate program
Condiments station	Choose colors, sizes, free extras
Signs showing what's available	Big and clear tabs. On hover, show details

Not only is this a fresh way to think differently about UI challenges, you might draw on the model to arrive at new features and usable terminology. In the example, the source was fairly well related to the target, but it doesn't have to be. Try crazy sources: how is your product like an airplane, circus, railroad station, or spaceship? Outlandish metaphors can generate requirements and opportunities that you might have missed.

Avoid being too literal or physical with your metaphor. Pictured is a classic example of this problem, the General Magic MagicCap interface for early 1990s PDAs. A too literal execution of your metaphor can be cumbersome to use in the new medium.  Imagine if tax software only let you fill in the existing tax forms on your computer for printing. Would that be seen as a true step forward, worth paying for?

Instead think of “magic” ways to reduce steps and exceed user expectations.  For example, in online food shopping, it might be nice if the navigation were modeled after familiar store shelves. But it's better to enable search and have the system suggest favorites based on past purchases.  Online, your shopping can be faster ... almost like magic.

User stories and "Internet weddings"

All I had to do was look at the news article title to know it was a bad idea. Live Internet video weddings!  Imagine standing at the altar, about to say "I Do," when your officiant interrupts that the wedding server is down. Weddings are stressful and expensive enough, I thought, without more technology getting in the way.

I read the article, however, and my mind was changed. A number of user stories in the article made me realize this service has a great deal of value to the right audience. For example:

• An elderly, disabled relative can't travel to the wedding site, but she still can get a nice sense of the event.
• One couple has family in Europe and the United States, so they choose a "halfway" wedding spot in the Cayman islands. Relatives who couldn't afford the trip could watch online.
• Surprise! A Hawaii destination wedding involving an older couple was quickly planned as a complete surprise to the bride. The family wasn't left out, though, since they could watch online.

Of course, these user stories have nothing to do with the system's interface, or any important technical details. In user experience, user stories are an early design process technique to start thinking about features the system needs to support. They are distinct from personas (specific, representative, detailed audience profiles based on user research) and scenarios (when users perform a specific task using an interface).

Software developers, particularly those of an Agile persuasion, think of user stories as a quick way to establish requirements. They are, but don't forget their value in building empathy for users. User stories are a great way to share customer experiences with the entire team -- a valuable practice when you are not the audience for your product.

Working with Developers

To follow up on my post about working with designers, here are some tips and things to watch out for when working with developers and engineers.

First Things First

In order to compete on usability, your developers need to have achieved two things.  First, your product must be stable. No design can rescue software that crashes. Second, your product must be feature complete, meaning that all the relevant functionality most important to your target audience is included.  Forced to choose between a product that’s intuitively usable, and a product with more relevant features, customers will almost always choose more features.

Now, it’s still the best practice to integrate usability from the first stages of product development. Just be aware that you don’t get to truly compete on usability until your customers’ needs for stability and features are satisfied.

General tips

Have your developers watch a usability test. Developers sometimes are skeptical about users’ difficulty with certain features, because the functionality is intuitive to them. Seeing is believing here. Don't forget to put what they’re seeing into context. For example, emphasize that users aren’t dumb when they make “dumb mistakes,” they’re just busy, distracted by the system, or unfamiliar with the mental model which the system is based on.

Get involved early. Insert yourself into the development cycle early, when you have the best opportunity to recommend changes before it gets too expensive to change things.

Build relationships. At many companies, developers are a separate tribe. Overcome the barriers and work to build personal relationships, before you have to request them to do some work for you. Invite them out to lunch, strike up a conversation when entering or leaving the office, and seek common ground. The best way to get people to observe your usability tests is to serve snacks.

Lobby for exclusive resources and promote ownership. When developers feel a sense of responsibility for the product's success, user-centered design is an intuitive next step for them.

Here's what you want your developers to be:

• Externally aware. They measure themselves by the best examples they can find, and refer to  competitive threats.
   
• Passionate for their field. You can judge this in several ways. Do they write about their craft in blogs? Attend conferences on their own time?  Take classes to sharpen their skills? 
• Focus on one product area. I prefer a developer who has a lasting role in a product, not a spare part who's constantly being retasked.
• Difficult to distract. I like it when I really have to wave my hands or speak loudly to get a developer's attention. Achieving flow is the key to productivity in most all fields.
   
• Decisive. It’s a lot easier to work with someone who can quickly make decisions when building things, rather than running to a manager every time a new concept arises.
• Won't go home without fixing their bugs. Obviously not everyone can do this, but the best development teams hold themselves to high standards.

On the other hand, watch out for people who are:

• Internally preoccupied or consensus-motivated. If developers are unaware of innovations in their field, or refuse to countenance new ideas, it’s tough to interest them in user experience.
• Apathetic. You want developers to advocate for innovations and positive change, not just do the minimum so they can go home and watch TV.
• Release with obvious bugs in their code. Going back to the stability point above, if you repeatedly uncover showstopper bugs, you start to wonder if the developer cares. You want your engineer to be embarrassed when you find major system bugs. 
• Forced to multitask. Like with any worker, production slows when a developer must switch tasks frequently. Also, multitaskers in software engineering must waste time understanding other people’s code.
• A stickler for business process. Process is important to maintain consistency and quality, but in some organizations it gets out of control.  Process is meant to serve people, not the other way around, so give reality checks when there are too many hoops to jump through.
• Overly defensive. I had a colleague, new to her company, who was having difficulty making herself understood over the phone with a developer. When she acknowledged the communications gap and asked the developer where his cubicle was, so she could come by and explain, he responded, "You don't need to know that."  Red flag!

Of course, many of these points relate to your organization as much as to any specific coworker.

Working with designers

Jakob Nielsen's recent post The Myth of the Genius Designer coincided with a marketing class I'm taking. My grizzled, veteran marketing professor distrusts designers. He punctuates criticisms of TV and radio ads by reflexively blaming "the creatives" for any shortcomings in the message.

I'm a positive guy, so my guidelines for working with designers are not so cynical. Just as you must know your users when building a system, to work best with designers you must understand their challenges.

• Everyone has an opinion about your designs. People who work in engineering, finance, and marketing rarely have colleagues from other departments wander by and offer unsolicited opinions on their code, accounting methods, or ad spending plans. Designers can look forward to this kibitzing every day.
• What are your qualifications? Other professionals can point to their MBA's, CPA's, or MSCE's as evidence of their expertise. On the other hand, designers are disrespected for their lack of business credentials. Few people understand how an art school curriculum prepares people for a design career.
• You're always compensating for other people's constraints. The design must accommodate the limitations of a system's functionality and shift to fit copy changes. But designers never can say, "My design doesn't support that code."

As a user experience specialist, you sometimes can be another source of headaches to designers who don't want more work supporting accessibility, affordance, or the results of user testing. Here are some ways to work better with designers.

• Support your recommendations objectively. Don't be another kibitzer to the designer. Back up your design ideas with human factors principles and user research.
• Present usability as part of design. Communicate to all that usability studies are not about judging or rejecting a design. Collecting and applying user experience is an integral part of the design process.
• Prioritize and work to deadline. If you have a perfectionist designer who fiddles with details too much, help them out by continually returning to business priorities. Never ask for a set of changes without clearly explaining the most important and then asking when they will be done.
• Ac-cen-tuate the positive. Start with mentioning the design's best aspects. Also, keep in mind that while it's easy to poke holes in a design, creating a new, original display or interface is much more difficult. Acknowledge your colleagues' efforts.

Build As I Do, Not As I Say

Here's another problematic quote usability practitioners are used to hearing from clients.

"We don't need usability because we listen closely to our customers and build the features they need, the way they want them."

This viewpoint is prevalent in the enterprise software market. When a customer is worth thousands or millions of dollars, it's very difficult for a business to turn down their feature ideas! Building to customer request seems user-centric and laudable, but often, it's a philosophy leading to expensive, unusable designs.

Instead of building to customer wishlists, focus on what your customers actually do. If they request a new feature, interview them carefully to understand why they want it. You may find that a different type of feature would meet their needs even better. Customers may be adept at what they do, but they're not likely to be interface experts. You must listen to their suggestions, but hear their goals and address those goals with good, usable design.

Sometimes, the feature customers want is one they already have. Consider Microsoft Office. The recent 2007 release concentrated on user interface since, in a customer survey, 90% of requested new features already existed, hidden in the software interface.

Usability reports?

At a party the other night, I met a software developer who happened to be looking for a usability consultant to evaluate his startup's web-based application. This is the first time that's happened to me! I believe it's a sign the usability field continues to mature and gain legitimacy, although that may be confirmation bias.

Anyway, he believed the application needed improvement, but he was very wary about asking for help.  He'd commissioned heuristic analysis with usability consultants in the past but their "Word documents with mockups," (said disparagingly) were not what he was looking for. I didn't understand at first because what he described sounded like a very typical usability report.

After a long discussion, we clarified the problem with the reports. Because he and his development team only can think about usability intermittently, the reports tended to sit around awhile before they were ready to refer back to them. And without lots of extra context, it simply took too long to decipher context and meaning. It seemed like a classic cognitive overload moment.

Do you have a standard report template you use successfully?  And have you ever needed to come up with something more involved to meet client needs?

"I thought that was an ad."

It's a common, and unwelcome, comment during consumer website usability testing. Users first ignore the page's most prominent feature, then fumble around the page's links and text for awhile, before finding the feature some other way or stopping in frustration.

When you ask them if you saw the big, carefully designed component for Feature X, they respond to show you that they perceived it, but they didn't really see it. They thought it was an ad.

Seeing a webpage for the first time, users categorize regions at a glance. Certain design cues will suggest content to them (columns of text, navbars, form elements) and others suggest ads.  Along with that initial glance, most users are conditioned today to look mostly in specific areas for the page content.

Here are the top design aspects that may cue users to think something is not content:

• Shape: Wide rectangles
• Position: Top of the page or on the right side
• Color: A different background color than the rest of the page
• Border: box blindness
• Different fonts from the rest of the page
• Unexpected animation or use of images

This post is really about designing content, not ads, but you can view some additional relevant pointers on banner blindness, animation avoidance, and pop-up closing from Jakob Nielsen.