Quick Summary: In part 1 of this article we covered what I call the user interface “snow plow principle” – the notion that displaying too much information and offering too many options is akin to driving a snow plow to the corner store to get your groceries. Here in part 2 we look at some solutions to the problem.

Packing too much into an interface results in user confusion, information overload, and a poor user experience. Sounds like an outcome worth avoiding, doesn’t it?

Solving this problem doesn’t require rocket science (or snow plow science for that matter), but it does require thinking in ways that you or your team may not be used to. Here are some strategies and tactics to consider.

1. Make simplicity a stated project goal. For some organizations this goes without saying, but many simply pay lip service to user-centered design. User-centered design requires a commitment to research and planning, and it requires that you make the effort to learn what your users want. This knowledge enables you to deliver upon their needs and expectations. A good starting point is to ensure that documents describing your project include simplicity and ease of use as critical design requirements.

2. Learn about your users’ goals and needs. Many organizations and teams base design decisions on assumptions about user needs. This is only marginally better than ignoring users altogether. Even the most knowledgeable members of your team aren’t the customers who actually use the product. In other words, guessing about user needs and goals is a shortcut to building the wrong interface. It’s dangerous to assume you know what your users want; instead, ask them (I’ll cover how to ask in other articles).

You should research and document:

• Who your users are (their demographics, skill sets, work environments)
• What they need from your application or website, and
• How your product fits in to their workflow.

This baseline knowledge enables you to design for simplicity by focusing on:

• What’s most needed
• by the greatest number of users
• in the greatest number of high probability use cases.

Armed with this knowledge, you can move or remove elements and functions that are less important, for example those of little relevance to most users, or those that aren’t needed most of the time.

3. Establish a purpose and goal(s) for each key screen. You should associate a set of user goals and business objectives to every screen of your application or website. For example:

• What should users accomplish or get out of a given screen/page?
• What is the desired user outcome for the screen?
• How does this benefit the user?
• How does it benefit your company?

Understanding the answers to these questions enables you to measure each element of a screen/page against its purpose and its contribution to overall user and company goals.

4. Prioritize interface elements accordingly. Once you have a sense for what’s important to your users and what isn’t, you can adjust the interface to emphasize key functions and information, making these items easy to notice and understand. Remember, these must be the attributes, elements, and functions that are most important to your users in fulfilling their goals, not those most important to the development, design, or marketing team.

5. Supress or move low-probability information and options. This is the “less” aspect of “less is more”. When an interface element isn’t needed often, it should be suppressed or eliminated. This doesn’t necessarily mean hiding less-used options many levels deep. It can mean in essence “hiding them in plain sight” by making them less prominent within a layout. One example of this is replacing a block of disclaimer or explanatory text with a brief overview and a link to “learn more”. Another small example is displaying the most popular/likely items in a list first, for example placing “United States” first in a list of countries on a shipping form if the great majority of your customers are in the United States (also see this related article).

6. Edit what’s left; err on the side of brevity. Once you’ve reduced an interface to its most essential elements, it’s time to ensure that your language is clear and concise, and that your layout enables users to find and understand the key information and options. Whenever possible, disclaimers, instructions, and other text should be brief while still remaining clear and compelling. Writing for the web and for software is an art in itself, and is beyond the scope of this article. I’ll cover more on that at a later time.

7. Test your user experience. The quality of a user experience can be measured. If you’re not measuring yours then you’re “flying blind” and merely guessing at the effectiveness of your product. Test your website or application periodically, even if it’s meeting your business objectives. There are many ways to do this, for example formal or informal user testing, or online surveys. Regardless of the methods, the goal is to ensure that the application or website stays aligned with user needs. When the two diverge, it’s time to make improvements. On a related note, remember that user needs are not static; they change over time. If you haven’t spoken to your users about their needs lately you might be overlooking an important opportunity for improvement.

Paradoxically, there’s much more to say about simplicity; this article only scratches the surface. I plan to cover more on this important topic in the coming weeks and months. In the meantime I hope it provides some food for thought and a starting point for discussion and positive change.

Photo by Joost J. Bakker. Creative Commons licensed.

Related posts:

1. Simple user interfaces: the snow plow principle
2. Streamlining user interfaces, part 1
3. Reduce costs and improve usability with visual standards, part 1

Related posts:

1. 5 reasons to love remote user testing
2. Simple user interfaces: the snow plow principle, part 2

Related posts:

1. 7 reasons to avoid remote user testing
2. Simple user interfaces: the snow plow principle, part 2

Quick summary: Users come to every website or application with expectations, assumptions and biases that are forged from previous experiences. It’s important to understand your users’ biases – and address the ones that affect usability.

I hate to be the one to break it to you, but your users have baggage. Lots of it.

I’m not referring to carry-ons or checked luggage. And I don’t mean deep emotional problems (although they may have those too). I mean that everyone who visits your website or uses your application brings with them certain assumptions and expectations from previous experiences.

Why should you care? Unless you’re willing to understand and accommodate your users’ baggage you may be inadvertently creating a frightfully bad user experience for them. So it’s best to understand your users’ baggage and then determine what you can do about it.

User Expectations and biases

Everyone who uses technology – websites, applications, kiosks, products – walks away from each experience with certain impressions and memories. Sometimes the experience reinforces what we already believed. Other times the experience results in new opinions or assumptions, or changes existing ones. Good, bad or indifferent these memories get filed away and later become part of the filters through which we view the world.

This is important to usability because when someone begins to interact with your product they’re perceiving it through their own unique set of filters. In other words, their previous experiences have a big impact on how they interact with your product – and what they expect from it.

This type of “baggage” takes many forms, for example:

• Stories about others’ experiences. A user coming to your website might have recently read a story in the media about a big online privacy breech, and be wondering just how secure your website really is. Or he/she may have heard a story from a friend or family member about identity theft. This user is likely to be especially sensitive to privacy and security issues and messaging (or lack of it).

• Their own personal experiences. Perhaps your user recently ordered an item but found out a week later that it was out of stock for six months. This user may be wary of making a purchase if they don’t feel a strong sense that the order will be filled promptly.

User baggage isn’t limited to bad experiences. It also takes the form of assumptions and expectations about things like:

• Information architecture (“I expect to find silverware in the housewares section”)
• Data entry (“I expect to put parentheses around my area code”)
• Terminology (“I call them oyster forks, don’t you?”)
• Search syntax (“I expect to search by typing in sentences like ‘show me forks under $10’”)

… and so on. These assumptions and expectations cause users to interact with your website or application in a certain way. The problems often begin when the website or application works in a way that’s contrary to users’ expectations.

What should we do about user expectations and biases?

We need some ways to understand and then address this type of user baggage.

The best way I know to understand what baggage users carry with them is simply to ask. Well, maybe not directly (“Say, what baggage are you saddled with?”). But there are a number of ways to find out, and not surprisingly they’re all consistent with best practices for usability and user experience design. Three of my favorites are:

• User testing. So far there’s no substitute for sitting down with representative users and observing how they interact with your product. It’s an opportunity to uncover important assumptions and expectations, and it can enable you to address the most serious disconnects between what your users expect and what you’re giving them. I’ll cover user testing in considerably more detail in future articles. Naturally user testing isn’t the only way to inform improvements to usability and user experience – but it’s the most powerful.

• Online surveys. Collecting information via quick online surveys is another great way to gain insight into your users’ thoughts. Tools like Survey Monkey can be used to gather information on terminology preferences, for example by displaying a product image and asking users to choose which category it belongs to. The disadvantage to surveys is that you get “what” users think but not “why”. In other words you may be able to determine that most of your users expect to find speakers in a section labeled “studio monitors”, but you won’t necessarily know why they feel that “studio monitors” is a better choice than “speakers” or “sound reinforcement”.

• Remote observation tools. Tools like ClickTale and Userfly enable you to record users’ interactions with your website. You can then play back the recordings later to see exactly what users clicked and typed, and when. These tools can be very helpful in uncovering user baggage. Their primary limitation is that – just like surveys – they don’t address the “why” of user behavior as effectively as user testing. Still, they can be a good starting point for learning where user behaviors and expectations differ from what a website or application delivers.

Regardless of how we gather information from users, once we begin to see what baggage they bring with them we can address it. Again there are a number of ways this can be done, but the two most important are:

• Revising the site or application to more closely match user expectations; or,
• Setting expectations more clearly.

Revising the site or application generally involves things like:

• Using terminology that users expect. If most of your users think that product #218 is an oyster fork, then call it that. Or use more than one name (“Oyster fork/3-pronged fork”).

• Matching information architecture to user expectations. Similarly if users expect to find their oyster forks in a section called “housewares” but you’ve got them in a section called “silver” or “other” then there’s a problem.

• Adding or revising functionality to match expectations. Using the example from above, if users tend to use parentheses when entering phone numbers the ideal solution is for the website or application to simply accommodate parentheses.

Of course there are situations where it may be unfeasible (or undesirable) to change aspects of a website or application to match user expectations. The next best alternative is to set expectations more effectively. This can be done in a variety of ways such as:

• Adding text hints and contextual help. If users tend to make mistakes with data entry (like the earlier example of parentheses around an area code) then it makes sense to either modify your site or application so that it can handle such input, or help set expectations that it can’t. Text hints such as “(numbers only)” or “xxx-xxx-xxxx” can help guide users towards entering data in the format it’s needed.

• Ensuring important messaging is easy to see and clearly written. I’ve touched upon this in several previous articles but to recap: if you want to ensure that customers with privacy and security concerns (and that’s most of them) feel comfortable, it’s important to address these points very clearly. It’s also important to make sure users can actually see and notice these messages. They need to be large enough and presented in places where users will naturally look.

In conclusion

• Users’ previous experiences create filters through which they see and interact with your application or website.
• It’s important to understand your users’ biases and expectations because they can play a big role in ease of use.
• User testing, online surveys, and remote observation are three tools that can help uncover and understand user expectations and biases.
• Once you understand your users’ biases you can work around them; in many cases this involves simple changes like terminology. Sometimes the necessary changes are more complex and involve site structure or information architecture.
• It’s wise to gather information about expectations and biases periodically because they tend to change over time.

Yes, your users have plenty of baggage. But it needn’t result in frightfully bad user experiences.

Photo: striatic. Creative Commons licensed.

Related posts:

1. Why require registration? Part 1
2. Improved error handling, part 1: helping users notice errors
3. Communicating status