Minimizing Complexity In User Interfaces

Advertisement

Clean. Easy to use. User-friendly. Intuitive. This mantra is proclaimed by many but often gets lost in translation. The culprit: complexity. How one deals with complexity can make or break an application. A complex interface can disorient the user in a mild case and completely alienate them in an extreme case. But if you take measures first to reduce actual complexity and then to minimize perceived complexity, the user will be rewarded with a gratifying experience.

We recently faced this very challenge while designing two Web-based applications, including an enterprise-level content management system. What follows are several techniques that have helped us streamline complex applications into lightweight user experiences.

Grab The Hatchet

The first weapon for fighting the villain of complexity is a hatchet. Studies1 have found that 80% of users use only 20% of software features. Not only are all those unused features a waste of development time, but they frequently detract rather than add value by making the application more difficult to use. Applications that try to do everything often struggle to do anything well. A successful application is a lean application: one that isolates a single problem and solves it brilliantly. As 37signals2 would say, “Underdo your competition.”

The best way to get a lean streamlined application is by eliminating features. When deciding whether a feature is necessary, the default answer should be “No.” Make features really fight to be included. If it doesn’t help the majority of users accomplish their frequent tasks, then it should probably be left out. Don’t get me wrong, being the one who swings the axe is tough, but when customers wax lyrical later on about how easy the application is to use, you can take all the credit.

Hide Complexity

If you can’t kill a complex feature, the next best thing is to hide it. Too often, rarely used yet complex features take up more screen real estate than frequently used yet simple features. This shouldn’t be. A good user interface should make the most common tasks the most prominent and then hide rare tasks so that they don’t get in the way.

When we were redesigning our content management system, we weren’t able to kill one complex feature in particular: the bulk edit function. In the previous version of the CMS, an entire column of a main screen was devoted to the bulk edit basket. The feature consumed about 30% of the screen real estate, but we found that very few people actually used it. Our solution was to introduce a single icon with a number beside it indicating how many items were in the basket. Clicking on the icon or number revealed the list of items in the basket through a modal dialog. This saved a huge amount of space and prevented the majority of users from being distracted from their primary task.

Bulkedit 1 Bulkedit 2

In the words of design guru John Maeda3, “When a small, unassuming object exceeds our expectations, we are not only surprised but pleased.”

Minimize Visual Noise

So far, we’ve discussed minimizing complexity by killing or hiding features. But minimizing “perceived” complexity is also important. UX designer Brandon Walkin4 says, “The amount of visual noise in an interface has a great deal of impact on the perceived complexity of the interface.” Keeping visual noise to a bare minimum will make an interface seem easier to use. The two primary tools for reducing visual noise are white space and contrast.

White space, as defined by Mark Boulton5, “is the space between elements in a composition.” White space should be your default layout tool. One rule of thumb is never to introduce a design element if you could accomplish the same goal with white space. You will be surprised by just how much you can accomplish with white space alone.

While white space should be used in abundance, contrast should be used as little as possible. Design theorist Edward Tufte6, who is responsible for the notion of the “least effective difference,” urges designers to use the smallest visual variation required in order to effectively communicate an idea. Practically, this means emphasizing what’s important and dialing back everything else.

To illustrate both of these points, take a look at this pricing chart from TypeKit7 and then look at the modified version:

Typekit Original8
Original version9.

Typekit Modified
Modified version.

You’ll notice that the modified version contains a dark heavy border, not unlike the default border around HTML tables. Which version does a better job of minimizing visual noise? (The answer, of course, is the original.) Plenty of white space and minimal contrast help reduce visual noise and will make your application feel simpler.

Reduce, Reuse, Recycle

As an application begins to take shape, problems often recur in various parts of the application. And recurring problems characteristically tend to have similar solutions. Look for ways to reuse components of the interface. Reusing elements for different purposes has two advantages: less development time is needed, and a more consistent experience is given to the person using the application. If a user learns how to achieve one task, they can apply that same knowledge to accomplishing a second task as long as it is implemented consistently.

In the process of designing a CMS, we spent a lot of time perfecting form validation. We outlined invalid fields in red and even added red validation bubbles to indicate how many errors were in each section of the form.

Later in the process, a version comparison feature was added to the requirements list. Instead of creating an entirely new mechanism, we piggybacked on the validation framework. Form fields that had changed were outlined in blue, and we used blue bubbles for section totals. It was quick for us to deploy, and the interface was already familiar to users.

Validation

Version Compare

Reusing interface components is another way to reduce perceived complexity because users will then quickly become familiar with the application and know what to expect from it.

The Blank State Should Not Be Blank

The blank state is how an interface appears when no data is available, such as when someone uses an application for the first time. As designers, we spend most of our time figuring out how best to present content, and too often we forget that content simply won’t always be there.

It is vital to build in sensible defaults. The blank state is often the first impression someone has of a product and can be a deciding factor in whether or not they even get started using the application. A good blank state acts as a wayfinding device, helping the user take their first few steps.

Versions

The people behind Versions10 (a subversion client for Mac) obviously put a lot of thought into the blank state of the application. The application prominently highlights the top two actions a user might want to take when using it for the first time.

It bears repeating: don’t forget the blank state!

Showcase

We’ve all seen plenty of cluttered, complex software. Applications that effectively minimize complexity, however, are a bit harder to come by. Here are few that pull it off with flying colors.

Invoice Machine11 is user interface minimalism at its best. The application exemplifies economy of expression and pays extreme attention to detail.

Invoice Machine12

Freckle13 just makes you want to keep track of your time. The conveniently condensed interface shines with energetic color, turning a routine task into something fun.

Freckle Time Tracking14

Image Spark15 combines sleek black-and-white gradients with elegant typography. Its interface has few controls, making it simple to get around.

Image Spark16

Ballpark17 has clear controls and an uncluttered interface, without being sparing in its use of color.

Ballpark18

Krop19, at its core, is just two form fields: location and keyword. It takes literally about five seconds to find relevant job postings.

Krop20

Fever21‘s entire purpose is to reduce the barrier between you and blog posts you’re interested in. It accomplishes this through a simple, unique interface.

Fever22

Screenr23 is an amazingly simple tool for recording screencasts and posting them to Twitter. It is notable not for all of the features it has, but for all of the features it doesn’t have.

Screenr24

Squarespace25 does a great job of hiding complexity. While it is a full-featured Web publishing platform, it does an impressive job of hiding its power behind a simple user interface.

Squaredspace26

The Final Word

First, reduce actual complexity by eliminating unnecessary features and then hiding what you can’t eliminate. Secondly, reduce perceived complexity by minimizing visual noise and reusing elements. And finally, use the blank state to help orient users.

Minimizing complexity in the user interface will help people learn your application more quickly, use it more effectively and be happier all the while. As jazz musician Charles Mingus said, “Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.”

Further Resources

(al)

Footnotes

  1. 1 http://agilesoftwaredevelopment.com/2006/12/kano-model-of-customer-satisfaction
  2. 2 http://gettingreal.37signals.com/ch02_Build_Less.php
  3. 3 http://lawsofsimplicity.com/about/
  4. 4 http://www.brandonwalkin.com/blog/2009/08/10/managing-ui-complexity/
  5. 5 http://www.alistapart.com/articles/whitespace/
  6. 6 http://www.edwardtufte.com/tufte/books_vdqi
  7. 7 http://www.typekit.com/
  8. 8 http://www.typekit.com/
  9. 9 http://www.typekit.com/
  10. 10 http://www.versionsapp.com/
  11. 11 http://invoicemachine.com/
  12. 12 http://invoicemachine.com/
  13. 13 http://letsfreckle.com/
  14. 14 http://letsfreckle.com/
  15. 15 http://www.imgspark.com/
  16. 16 http://www.imgspark.com/
  17. 17 http://getballpark.com/
  18. 18 http://getballpark.com/
  19. 19 http://www.krop.com/
  20. 20 http://www.krop.com/
  21. 21 http://feedafever.com/
  22. 22 http://feedafever.com/
  23. 23 http://screenr.com/
  24. 24 http://screenr.com/
  25. 25 http://www.squarespace.com/
  26. 26 http://www.squarespace.com/
  27. 27 http://37signals.com/svn/posts/1952-i-gave-a-talk-on-ui-fundamentals-for-programmers
  28. 28 http://www.brandonwalkin.com/blog/2009/08/10/managing-ui-complexity/
  29. 29 http://www.cennydd.co.uk/2009/ux-london-in-review/
  30. 30 http://www.d7ux.org/
  31. 31 http://www.amazon.com/Designing-Obvious-Common-Approach-Application/dp/032145345X
  32. 32 http://gettingreal.37signals.com/index.php

↑ Back to top Tweet itShare on Facebook

Tyler Tate is a user interface designer at Vyre in London. He is the creator of the 1KB CSS Grid, and his latest venture is TwigKit.

Advertising
  1. 1

    @Vanco

    Definitely agree with your statements on handling complex data applications. All of the apps listed here are beautifully executed, but they all are so narrow in their scope that the design has not been truly challenged by the complication of displaying, say, 300 data entry fields on a single screen.

    There are a number of ways to handle complex and overwhelming amounts of data – but they are not accomplished by simply applying more white space and “Grabbing the Hatchet”. From requirements gathering to the application prototype the designer must be feverishly focused on condensing the data displayed at any one time and organizing it in a logical way for user interaction.

    Edward Tufte FTW!

    2
  2. 52

    Great article,

    80% of the people use 20% of the functionality: TRUE
    But different functionality : TRUE

    Solution: Why not creating different ‘views’ for different kind of users? Dreamweaver, Eclipse, Netbeans do it or let you customize the 20% that you use.

    Huge data entry pages: These systems are not only hard to use but prone to errors, input fields should be splitted in several screens and/or at least grouped in sections, ways to simplify/automate data entry should be used when possible (Yep I have made these ones).
    More than any other this applications require a simplifying mind behind them.

    Altogether a great read for both developers that tend not to care about this issues and designers that tend to ignore functionality and usability on the sake of misunderstood beauty!

    Thanks!

    1
  3. 103

    As always, love your stuff! Keep the great content rolling!

    1
  4. 154

    I was pleased to see Squarespace on your list. I use them for my blog, GigantiCo, and I recommend it to everyone based on its content management interface (they also have great customer service).

    cheers,
    Chris

    1
  5. 205

    Superb article – really helpful tips.

    1
  6. 256

    Less is more, sometime making the more less is the hardest thing to do. This is definitely an insightful article. Thanks for the read.

    Benga creative

    1
  7. 307

    Removing features is what developers are feeling bad to do… but very often is a must.

    2
  8. 358

    Real good resources and very helpful. I will bookmark this

    1
  9. 409

    I like the article. I have a clear goal in my current software project that aims at creating a really awesome interface and a lot of the focus is on usability and making the interface “get out of your way” so you can focus on the actual content and actions.

    When you create interfaces you have to deal with stuff like spatial memory and “recognize vs. remember”. At the same time you need features because people like to do stuff in different ways.

    So the pure aim is to create all necessary features and present them in the absolutely best way possible.

    Not to tout my own horn but I think that my software is on the right track. I try to mimic interfaces that people are used to and I have tools to let people use the same keyboard shortcuts as the “competitors”, aiming at reducing the stuff they have to relearn.

    In the projects blog I actually wrote a similar article on what I believe is the best approach to designing a good interface:
    http://www.luckymountainhome.com/

    I look forward to your follow up

    2
  10. 460

    Awesome Post.

    1
  11. 511

    So many missing images in this post :(
    Please fix so that we can look at the important examples!
    Great post otherwise :)

    thank you

    -1
  12. 613

    I agree with most of the things that you mention: design consistently, never leave blank pages (I specifically like that tip) , dare to take features out if they are not necessary. I however think that “grabbing the hatchet” is a blunt way of handling things: sometimes a specific feature is needed for one type of user, but it isn’t for another type of user. If you’d just grab the hatchet you’d be doing one user A a favour, but user B wouldn’t be too happy about it.

    When designing applications that reach out to a somewhat broader audience, I think designers need to keep in mind that they can’t just create a fits-all solution. After all, removing features that are deemed necessary by a certain type of user may lead to them abandoning the application, which can then lead to a drop in sales/conversion rate/…

    I have the same opinion on hiding features. While in some situations it might be a good/plausible idea to hide certain features and bundle them in a dropdown for instance, I do think this technique should be used with utmost care, as hiding features can lead to users not knowing (and therefore not using) them … due to the negative impact it might have this should not be used as a rule of thumb while designing intuitive interfaces in my opinion. Throughout Don Norman’s book “The design of everyday things” he refers to this specific item as “the visibility”. In order for something to work according to the user’s conceptual model, controls should be visible … if they are not, there is a good chance the user will err.

    A solution to the “grabbing the hatchet”-technique would be adaptive interfaces, in other words: interfaces that adapt to the user’s level of comfortability with the app (ie: their skill in using it). Utopically, this is probably something every UI designer should strive for when designing in his/her app, but this is rarely possible in real-world scenarios due to all sorts of parameters like cost, production time and mandatory testing loops (which also add to the cost and time).

    Having said that, when there’s little to no budget or time for building adaptive interfaces, sometimes there sadly isn’t much else you can do aside from grabbing the hatchet as it is probably the easiest way to trim down your app to an acceptable level.

    In conclusion I think that grabbing the hatchet and hiding elements are techniques that are used a lot (and will be used a lot in the future as well), but they should not be seen as the ideal solutions to solve new or existing problems, there are better alternatives to handle complexity, such as adaptive interfaces.

    0

↑ Back to top