From RPM Wiki
UI Design Principles
| Table of contents |
Preface
The interface of an application is more than just font size and button placement, it is user interaction. The way the user interacts with the system is fundamental to the success (or failure) of the application. Interaction design must play an important part in the development of the application right from the beginning.
What users want is convenience and results. But all they see is the interface. As far as the user is concerned, the interface is the product. (1)
What we need the interface to do for RPM Software
Business
RPM Software is a business, so our ultimate objective is profits. Usable software can increase sales and reduce costs.
The best way to differentiate your product's interface is to make it work. (2)
Desirable
Our main goal is to sell the software. This means foremost the software must meet the needs of the company who would be a customer. It must get the job done. However, long term success of the application requires going beyond just meeting the needs of the decision makers. The best contribution we can make to the success of the software with design is making it wholly desirable. By making software that works, we're meeting the company needs. By making software that's easy we're addressing the personal needs of users. Happy users are our best advocates
If the product merely meets Sally's needs, it forces her to become either an apologist or a survivor (3)
Support
The second direct impact on profit that design can have is in reducing training and support costs. The faster a user is setup, the less assistance user's require, the more resources we can dedicate to selling.
So, how do we design software that people want and that is easy to use?
It's about goals
People use the application to accomplish a goal. That may sounds obvious, but it's easily forgotten behind adding features, positioning links, and choosing colors. The discreet things the user needs to do to accomplish that goal are called tasks. The interface must be focused on the user's current task. We want to keep the user's attention on completing their task, not on trying to figure out how to complete their task or worse, on something different altogether. Errors, long delays, pop-ups, and other distractions break the user's workflow. The design goal is to allow people to work the application with the least amount of effort.
The old analogy is somebody who goes to see a theater performance: When they leave the theater, you want them to be discussing how great the play was and not how great the costumes were. (2)
One of the most challenging design problems comes from balancing the need to handle many different tasks with the user's concern for only their current task. This is where organization and navigation become very important. We can also rank some functionality by popularity and some functionality we'll open up to user personalization. Once the user has started on a task, it must take center stage over all else. Instructions and errors should only be shown when they apply. Focus is paramount.
Be Clear and Obvious
To keep the user focused on solving their problem, instead of solving the application, the design must strive to be self-explanatory and transparent. This means providing timely and sufficient feedback and being obvious. Spell out tasks, don't invent jargon, make sure a link looks like a link and a button looks like a button. Where am I? What do I do next? Those answers should be painfully obvious.
A perfect design would result in an application that requires no training to use. I think that's impossible in our case, given the range of problems we're tackling. That said, the majority of the application should still be usable by someone exploring the application with no training. For the user types with less functionality, such as the agent users, zero training isn't just a goal, it's a requirement.
The title of Krug's design book sums it up perfectly, "Don't Make Me Think". Every time the user's attention is moved from completing their task to "what is this thing", time and a coherent train of thought are lost. The workflow is interrupted. It may be minutes, it may be less than a second, but even the small delays add up and directly impact the user's perception of the software.
No matter how complex the task a product is trying to accomplish, the simple parts of the task should remain simple (1)
Being obvious means using simple, recognizable processes and business logic. It also means using clear language instead of "clever" or "marketing" terms and intelligent use of controls and layout. In fact, being obvious applies to every part of the application and the interface and must always be an important consideration when design decisions are made.
When simple things need pictures, labels, or instructions, the design has failed. (4)
Be nice
Under no circumstance should you punish your users for using your system - Aza Raskin
Act as expected
The design should always try to create a result that will behave the way the user expects it to. As with being obvious, creating an application that behaves as expected starts at the design of overall tasks, and applies all the way down to individual links. Only ever use conventions as they are intended to be used. This means, for example, never use a checkbox as a bullet.
The fundamental idea of meeting users expectations is closely tied with being obvious because there can be no doubt of what the expected result is. Example: A text box in front of a button labeled "Search" is obviously a search field. Users will expect that if they enter a word and click search a list of search results based on that word will appear so that is exactly the way it must be built.
There may be cases where different users would disagree on what they expect something to do. Maybe it is an indication that a better design choice could have been made in the first place. Some conventions are common sense, and others take usability testing to discover. Something that is obvious or expected to a developer or designer, may not be so to most actual users.
Be consistent
Being consistent in everything, from high level organization to low level details, is vital for two reasons. First, it helps the user to learn and use application. Second, it gives the application a look of unity and professionalism.
When things are consistent, the user will have an easier time with areas of the application that are new to them because those areas will similar to areas the user already knows. The consistency builds familiarity and obviousness and allows us to shape what the user expects to happen. Consistency must be maintained down to the smallest detail like capitalization and sorting and thus is one of the reasons for reference section of this guide. Other details that should be consistent include the order of the same items on different pages, or terms that are used.
In certain situations making something consistent may conflict with making it obvious, especially when trying to maintain consistency with existing features. In these situations it is up to the designer to make the choice that best supports the number one priority, the user's task. Usually obviousness should win, although even better is redesigning the situation so that both obviousness and consistency are maintained.
Be forgiving
A forgiving application allows the user to undo anything. This can take the form of the namesake undo control, or the clear presence of the opposite action to what was just performed. An example of the latter is a "Delete" control to undo an "Add". Being forgiving means anything that can be deleted can be restored and anything that can be moved can be moved back.
There are limits, and those coincide with real world actions that can't be undone like a payment or an email. In these cases it has to be clear what is happening. This includes allowing the user to examine any information before it is published and making sure there is no confusion when it comes to the final control that will cause the permanent action.
Related to always providing an undo is always providing a clear way out. This can be as simple as always providing a cancel button and a link to the home page. Combined with the reassurance of an undo, the user will feel safe exploring and working in the application.
Support Human behavior
Mental model
People will always form a mental model when they interact with something. Even if the user has no idea how something actually works they will still form some sort of model of it to help them use it. In an application this applies to both processes and navigation.
We base our models on whatever knowledge we have, real or imaginary, naïve or sophisticated. (4)
The interface should assist the user in creating useful models of processes. This is accomplished by breaking larger tasks into smaller, simpler tasks and making everything obvious, consistent, and self-explanatory. A useful mental model allows people to focus on their task instead of wondering what is happening and it frames their expectations.
Equally important is assisting the user in developing a useful mental map of the layout of the navigation. By giving the features and pages of the application a clear organization and making that organization obvious through the navigation controls, the application will allow easier workflow and prevent the user from feeling lost. This is important to help keep the user's attention on completing their task, not stumbling around looking for the required part of the application.
Scanning
Most users don't read, they scan (2)(5)(6)
As designers we like to think that the user will carefully examine every option then choose the correct one, but the reality is users scan then click on the first thing they think will help them and they also recognize as being clickable. Accepting this, we can support the user by keeping instructions and text minimal, keeping links and controls obvious both in use and result, and minimizing visual noise.
Most of the time we don’t choose the best option – we choose the first reasonable option, a strategy known as satisficing. (7)
The options must be visible or the user can’t scan them. Never use mystery meat navigation, a concept where the label of a link is hidden or obscured until the user passes the mouse over it. Menu style navigation can get into similar trouble when poorly designed, forcing users to hunt through many small lists of options one at a time.
Users don't have the manual, and if they did, they wouldn't read it. In fact, users can't read anything, and if they could, they wouldn't want to. (8)
It's clear an obvious and forgiving design will be more popular than a design that needs to be explained every step of the way. Reading instructions distracts from the task. Expecting the user to read a warning or follow instructions will likely eventually lead to mistakes. It's also a mistake to require the user to remember things. If there is something the application can do for a user, or remember for a user, than it should.
Habits
Another reason we design to be consistent and predictable, is to support positive habit formation. Habit formation is an inherent part of human behavior whether the designer wants it to be or not, so the design should be made to take advantage of it. This is as simple as being consistent, especially with location and order. If a certain link or control is always in the same position a user will get faster and faster at clicking it. Habits actually change the way the brain process information to the point that click will become a secondary action the user doesn't even think about. Once again we are supporting the original goal of keeping the user's attention on the task they are completing instead of mundane tasks like navigating.
Exploration
The common theme is allowing the user to confidently discover the application. User's should never be scared to click a link or try something. An application that is obvious, consistent, forgiving, and scannable requires less training and support, and provides a more rewarding user experience. It's a more powerful lesson if users can develop an accurate mental map on their own, than it is if they just read about it.
One important method of making systems easier to learn and to use is to make them explorable, to encourage the user to experiment and learn the possibilities through active exploration. (4)
Specifics
There's plenty more documentation on this site about the more specific application of these principles in RPM:
Rules
A few general rules to take from this page:
- Above all else everything must support the user completing their tasks.
- Everything should have an undo if possible and there must always be a clear way out.
- The interface must assist the user in creating a useful mental model
And a few specific rules:
- Links must be obviously links; everything else must be obviously not.
- Everything is visual noise until proven otherwise.
- The user must be able to use the back button as expected
Modularity
I'm proud that RPM has added a lot of functionality over the years, yet our home page has essentially the same level of content as it did in 2002.
- Part of being goal-driven is our hierarchical organization of the application functionality from general sections down to specific task pages.
- To accomplish that RPM is organized into broad sections. This allows us to isolate complexity and keep the interface focused to the task at hand.
Further reading
The number in brackets is used to identify quotes used throughout this page. The resources are listed in the order they are referenced. All the books listed we have in our office.
- (1) The Humane Interface - Raskin, 2000 - ISBN:1893115941
- The late Jeff Raskin (http://en.wikipedia.org/wiki/Jeff_Raskin) started the Macintosh project at Apple. His book focuses on the design of an ideal entire computer system.
- (2) Designing Web Usability - Nielsen, 2000 - ISBN:156205810X
- Business week called Jakob Nielson (http://www.useit.com/jakob/index.html) "one of the world's foremost experts in Web usability". He is one of the founders of the Nielsen Norman Group (http://nngroup.com/), advocates for user-centric design. This book focuses specifically on website usability.
- (3) The Inmates Are Running The Asylum - Cooper, 1999 - ISBN:0672326140
- This is my favorite book of the bunch. In it, Alan Cooper focuses on the problems with the design of high-tech devices and the fundamental development issues that need to be addressed to fix them.
- (4) The Design of Everyday Things - Norman, 1988 - ISBN:0465067107
- Don Norman (http://www.jnd.org/) is the other principal founder of the Nielsen Norman Group (http://nngroup.com/). This book looks at the design of things we encounter from door handles to telephones. It's easy to read, yet addresses the fundamental principles any designer needs to look at.
- (5) Don't Make Me Think - Krug, 2000 - ISBN:0789723107
- This excellent book neatly isolates common problems with website design.
- (6) How Users Read on the Web (http://www.useit.com/alertbox/9710a.html) - Nielson, 1997
- Quick answer: "They don't"
- (7) The MIT Press, 1998
- (8) User Interface Design for Programmers - Spolsky, 2001 - Available online (http://joelonsoftware.com/navLinks/fog0000000247.html)
- Joel Spolsky has a popular software development blog called Joel on Software (http://joelonsoftware.com/) and has posted his entire pragmatic book on interface design, including screenshots. This chapter title says it all: "Chapter 8: Designing for People Who Have Better Things To Do With Their Lives, Part Three"
- In addition to those resources I quoted, I recommend:
- About Face 2.0 - Cooper, Reimann, 2003 - ISBN:0764526413
- Envisioning Information - Tufte, 1990 - ISBN:0961392118
- Homepage Usability: 50 Websites Deconstructed - Nielsen, Tahir, 2001 (getting a little dated now)
- Picking the Right Degree of Control for User Interfaces (http://msdn.microsoft.com/windowsvista/reference/presentation/default.aspx?pull=/library/en-us/dnaero/html/usercontrol.asp), Windows Vista Developer Center
- Ten Usability Heuristics (http://www.useit.com/papers/heuristic/heuristic_list.html) - Nielsen, updated 2005
- Why software sucks (And what to do about it) (http://www.scottberkun.com/essays/essay46.htm) - Scott Berkun, September 19 2005
- Simplicity Is Highly Overrated (http://http://www.jnd.org/dn.mss/simplicity_is_highly.html) by Don Norman and the related post Simplicity (http://www.joelonsoftware.com/items/2006/12/09.html) by Joel Spolsky
Other UX guides
- Apple Human Interface Guidelines (http://developer.apple.com/documentation/UserExperience/index.html)
- Google User Experience (http://www.google.com/corporate/ux.html)
- Windows Vista User Experience Guidelines (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/uxguide/uxguide/home.asp)
- This page was last modified 04:44, 21 Aug 2008.
- This page has been accessed 592 times.