steve kwan user experience designer

Tiered complexity in user interfaces

(October 1st, 2007 - 4:43PM)

Recently I've had a lot of discussions about simple vs. advanced user interfaces. It's not uncommon for software to have two paths of entry:

• a "simple" approach, usually a wizard, for non-sophisticated users, and
• an "advanced" approach, usually a screen with lots of input controls, for power users.

This way of thinking dictates that two interfaces are better than one. With two interfaces, you can accomodate simple users with little technical experience, while also accomodating advanced users with little need for wizards. Right? Wrong.

Dual interfaces (simple and advanced) do not work. Users will almost always gravitate towards the simple interface and ignore the advanced one, especially if the simple one meets their needs. This can result in a great deal of application functionality going untouched if it only resides in the advanced interface.

I believe that wherever possible, software engineers should strive for a single interface for their products. Instead of having two interfaces for simple/advanced users, have one interface that accomodates both groups. This is best done by tiering complexity.

Instead of making a simple interface and a separate advanced interface, just make one interface: a simple interface that has links to advanced features. When people aspire to create dual (simple/advanced) interfaces for their products, what they're really doing is avoiding the brainwork required to make the advanced interface simple. Shoving all the advanced features off into a corner where nobody will see them is a usability cop-out.

Consider docmetrics, the flagship product we develop at Vitrium. It's a SaaS solution for marketers. Docmetrics helps marketers learn how customers read their PDF documents.

One of main functions in docmetrics is the ability to view a report on a PDF. However, it's also important to allow marketers to compare two or more documents against each other. Comparing is a very important feature, but is somewhat advanced and won't be used by all users.

We made the decision to put the emphasis on the single document report, and take the emphasis off the comparison feature. We did this by tiering complexity: the system focuses on single document reports, but also provides the ability to compare via links.

Here's a screenshot of the reports screen. Note how the Single document option (1) is at the top where it's likely to get attention, whereas the Compare multiple documents option (2) is lower at the bottom. It's certainly visible for people who are looking for it, but it's not the focus of the application.

Once the user selects a document and views the single document report, we provide all the metrics we've gathered on that document, but we also provide a link to the comparison screen. This way, the user can read the report she's looking for, but she has another chance to compare this document if she wants. See the screenshot below.

So the system makes common (basic) functionality as explicit as possible, but gives the user many options to compare the document. If the user doesn't want to compare, she can always ignore the links. This way we can have one interface with many tiers of complexity, instead of two separate "simple" and "advanced" interfaces.

If you'd like to see this example in action or learn more about docmetrics, I recommend signing up for a docmetrics account. It's free.

("Tiered complexity" is my idea and my term. If you want to use it, go ahead, but take credit for it and you'll face an army of lawyers.)