Post image for Simple user interfaces: the snow plow principle, part 2

Simple user interfaces: the snow plow principle, part 2

by Mike B. Fisher on February 3, 2011

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.

Be Sociable, Share!

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 2

{ 1 trackback }

Tweets that mention Usability and User Experience | Simple user interfaces: the snow plow principle, part 2 --
February 3, 2011 at 12:21 pm

{ 2 comments… read them below or add one }

Dan Leatherman February 3, 2011 at 1:14 pm


Mike B. Fisher February 3, 2011 at 1:58 pm

@Dan: Good one. Step 5 is “be careful you’re not missing a number when you present a numeric list” :-) I’ve corrected it – thanks for mentioning it.

Leave a Comment

Previous post:

Next post: