The Peanut Butter Theory of User Interface Design

“A good application is one on which a user can find a feature intuitively , even when they didn’t know where to find it in the first place. This can be attained only by creating intuitive, consistent patterns of navigations/actions mimicking the product domain as close as possible”

I completely agree with the first statement, but I would caution you against blind allegiance to the second statement. Simply mimicking competing user interfaces or modeling the real-world version of something isn’t necessarily the best way to make an application usable.

As an example, we’re currently working with a vendor who builds software to handle security cameras. The interface faithfully recreates the bank of TVs you’d see in a mall security office; working on the interface I’m always asking myself if the grid-based videos are laid out that way because it’s the best possible way for people to work with them or if they’re on our screen that way because they were easiest to wire in one area when they were physically on a wall. Maybe we needed to stay with what their users were used to, but maybe stopping and asking, “What do users need to do? How best could that be achieved?” would have led to a better interface. I think too often developers’ egos lead them to think the Average User is too dumb to get anything but what they know.

Shouldn’t you develop for the lowest common denominator though? If a know-nothing can use an application - an expert is going to be able to use it also. That’s what this article is all about - usability. If everyone can use it simply and effectively, it’s a product of good design.

Going from previous articles where Jeff says an application should “Do one thing”, this also applies to a very inexperienced user. If it does too many things, users get lost in all the detail.

That’s why “Simple” and “Advanced” interfaces are so effective in my opinion… it caters for both. It gives basic users what they need, and advanced users what they want. Just make sure that the Simple interface provides all the functionality required by the majority of users - which means making your product as lightweight as possible.

Actually, it’s the Elvis principle of software consisting of peanut butter, jelly and bananas, where:

Peanut butter = interface design
Jelly = testing (and re-testing)
Bananas = documentation

All are usually slathered on, post facto. Worse, I still run into managers and developers who are surprised when you tell them that interface design, testing and documentation EACH take as long as the coding itself, or longer.

Then there’s purchasing, marketing, HR, sales, shipping/download site creation and maintenance… but that’s all another story.

What flavor is “security” as an add on?

Jeff,

“Sometimes the things I post here are simple, even obvious. I personally don’t have a problem with that. Simplicity is hard.”

With you 1000%.

As important as user interface design is, it is also one of those skills like basic programming ability that many, even many professionals in the business, will simply not have, ever. In addition to wondering “Why can’t programmers program?”, I constantly wonder “Why can’t user app developers develop user interfaces?” Many of them just don’t get it.

I’d like to comment on participatory design and the users’ environments.

The book urges participatory design, where the users participate in the design. That’s great, but make sure the participants are users,
not just the (pointy haired) managers or supervisors. Managers tend to come up with UI’s that are easy to learn, but not necessarily the most easy and productive to use. (That may be good if there is high turnover.)

Also, we are talking participatory design, not abdicating UI design to the users. Take into acount other elements of the task environment besides the UI itself, e.g. task related paper on the desktop.

Bad user specified UI can diminish people productivity, cause fatigue, and cause system performance problems.

Example:

The user (management) specified that the initial page would present a list of eligible work items. The user would select which one to work on by clicking a button next to the item.

Sounds OK, huh?

NO.

There were typically a few hundred items in the list.

The work item the user almost always wanted to work on was the one represented by the paper clipped bundle of sheets at the top of the stack of bundles in the user’s in basket on his desk.

The 9 digit work item number was on the top of every sheet in the bundle. The users were all adept at using the numeric keypad.

The UI required that the user scroll scan the onscreen list for the item that matched. That required a lot of scrolling and eye movement between screen and paper. The user could have keyed in the nine digit number in 2-3 seconds.

Worse, the SQL query to retrieve the list, appserver time to format it, and browser time to display it caused poor perceived performance.

Solution: Provide an input field for typical use and an option to bring up the list for atypical usage.

DAKra

Jeff,
Have you read the Humane Interface?
http://www.amazon.com/Humane-Interface-Directions-Designing-Interactive/dp/0201379376/

It’s a book that summarizes many years of study of designing interfaces. It deconstructs interaction with the computer and has some very insightful ideas. The author builds all of the logic up to the ultimate computer interface - a zooming interface. Highly recommended!

Great discussion - in particular, I’d like to add to the post that mentioned participatory design. Any usability professional worth their salt will be able to identify cases where a usability test with actual users will be useful, conduct it in a professional manner while hitting the necessary depth of inquiry, produce an easy-to-consume report, and work with the developers to make sure the changes are implemented in a way that will benefit all the stakeholders involved. Iterative development works in UI design as well as it does in coding.

I also agree with a previous post that mentioned that users will not necessarily tell you how to improve things. It is up to the product team to synthesize solutions out of the feedback that they get from the users.

“The word ‘parameter’ was used extensively [and] test users read this word as ‘perimeter’, a telling sign that the designers had stepped outside the vocabulary that was meaningful to their users.”

[OT] I believe that this misreading also tells how users have become accustomed to the appalling spelling mistakes, ambiguities, and usage errors that clog the net. Sort of like peanut butter, you might say.

The problem with tabbed browser windows is just the implementation.

In the pre-tabbed browser days, I used to have a lot of browser windows open and they would all appear in the taskbar in a group. Tabs are just MDI windows instead of full window instanaces that are subordinated to a controlling dock. sigh if we truly had an objet oriented window system instead building things on a deprecated MDI API this could be fixed and even improved upon to handle this situation.

Interesting - this is in stark contrast to the core Linux design principle, which is build everything with a command-line and make a GUI later if it’s absolutely necessary. I wonder when they’ll get the message that it’s not a viable method of creating usable software.

Windows developers do it too, of course, but it’s more often out of ignorance than principle.