ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #2 December 2004
- Better Living Through RPM, Part 2
- How Red Hat Got Its Name
- Red Hat Summit: Bringing the Heat to the Big Easy
- Imagine Choice
- Improving Usability: Principles and Steps for Better Software
- Geek Giving Guide
- From Source to Binary: The Inner Workings of GCC
- Configuring Devices with udev
- Tux Paint: Mousing Your Way to a Masterpiece
- Unlimited Anytime Minutes: GnomeMeeting, the Softphone
From the Inside
In each Issue
- Editor's Blog
- Red Hat Speaks
- Ask Shadowman
- Tips & Tricks
- Fedora Status Report
- Magazine Archive
Improving Usability: Principles and Steps for Better Software
by Seth Nickell
When many people think of usability, they think of “interface guidelines.” Guidelines are a key element to any solid approach to software usability. However, I find that they are dwarfed in importance compared to open and intelligent engagement in design. There is simply no list of rules that can, by itself, make software usable. In the end, it comes down to smart people paying attention to the right things. On the other hand, it is not always clear what these important things are. Even roughly following a good design process can avoid common mishaps. In the first section, I discuss several principles of good design. In the second, I suggest a practical design process.
Principles through History
People build things. We've been doing it for thousands of years, and yet only in the past century have “design” and “usability” been major concerns. Embedded in the history of how these became pressing issues are clues for how to address them.
It used to be that people built things for themselves, their families, or maybe their friends. Over time designs were polished as people made small improvements and changes to standard ideas for their own needs. The artisan class evolved as a group of people who specialized in building things. You could go to your local blacksmith and commission a sword, or perhaps buy from a small set of swords he and a few employees has created. Artisans typically had direct contact with the people to whom they sold: finding out what they wanted, seeing firsthand how people used the things they built, how those things broke, etc.
That changed with the advent of mass production. Because engineers and inventors no longer had direct interactions with users, they based their designs partly on inference from their own needs and largely on guesswork. Sometimes this worked, and often it didn't. Over the decades, designers and builders have become increasingly isolated from users. For example, “I design a software product that will be sold by somebody else to yet another person who will in turn pass it on to the actual end user.” And that's in the best case.
This problem was one of the primary issues recognized in the mid-1900s by a new job role: the industrial designer. Influential designers such as Henry Dreyfuss (designer of the iconic Bell telephone, the modern refrigerator, many aspects of typical automobile interior, basics of airplane cabin layouts, etc.) stressed the absence of real user understanding as the primary problem in modern design. Despite class sensitivities of the period, Dreyfus worked as a telephone repairman's assistant, pumped gas, drove buses, and sold pantyhose; all to learn about the needs of the people for which he designed. He would spend many hundreds of hours talking to people and more importantly watching them work, before designing a product.
- User Knowledge Principle:
- Figure out who your user is, what they do, and what they need.
A wave of industrial and product designers worked their way through many difficult to use, unpleasant, and complex technologies that were cropping up in the home and workplace. The results were simple and useful devices from the vacuum cleaner to the stapler. These designs changed little in the intervening half century. And so, for a time, the rash of unusable devices was under control. A home stereo from 1981 was about as easy to use as a home stereo from 1961. The stereo from 1981 sounded better, was black instead of silver with faux-wood, and it didn't blow up if you forgot to connect the speakers. But, otherwise, it was about the same.
A home stereo from 2001 is a horse of a different color. It has more features, sounds a little better, and doesn't blow up if you plug it into a 220 volt power source. Unfortunately, it is also much harder to use.
What happened? Product designers didn't go away. If anything, they've increased in number. Physical mechanisms did get a little more complex, but they also grew more reliable (thanks in part to methods like Total Quality Control, practiced initially by the Japanese industry). The change was not in the people or the physical mechanisms. What changed was the microchip and the accompanying boom of software.
Unlike physical features, which incur both a development and manufacturing cost, software incurs primarily a development cost. Thus, with microchips, a stereo with one hundred features can cost a manufacturer only marginally more than a stereo with ten features. People like me love this. For example, my 2003 home stereo has a one-third octave equalizer implemented in software. That means I can adjust the amplitude at almost thirty different frequencies, “tuning away” imperfections in my physical room's frequency response.
For most people, though, the stereo with a hundred features does ninety things they don't care enough about to figure out. And unfortunately, the ninety extra features make the ten basic features substantially harder to use. The interface is overwhelming: its not clear where to start, and you have to figure out what to ignore and what to care about. Sometimes a change to the wrong setting will make the stereo act “funny”, a problem that must be rectified before basic operation can resume. In accommodating my fellow pseudo-audiophiles, stereo manufacturers have tended to create products that are substantially less helpful and useful to the general stereo-buying market.
Of course, there's nothing wrong with having a product that's targeted at a smaller niche market. Just be aware that a product designed for one set of users will probably be sub-optimal for another. The natural tendency is to design for exceptional users, particularly those who care strongly about what you are doing, at the expense of a larger body of users. Notice, I did not say “power users.” Most power users are exceptional, but the class is much larger. Exceptional users can lie at the other end of the spectrum too. For example, accommodating home-business users in a software product targeted primarily at professional accountants is going to degrade the product for accountants.
- Feature Bloat Principle:
- Recognize the cost of each feature you add and each exceptional use case you accommodate.
Mass production has had another curious effect. Individually made products could be customized to particular needs. But with mass produced items, larger production runs result in lower per-unit cost. There are many reasons for this: R&D costs are amortized over a larger number of products, increasing investments in production automation are justified, and it is cheaper to provide support. Thus, there is cost pressure to maximize the number of people to whom the product is relevant.
As a consequence, designers and engineers are encouraged to target as many classes of user as possible. The problem is that design goals between user classes frequently conflict (such as the before mentioned stereo example). The design process becomes an exercise in compromise, and the resulting product is mediocre for all target user classes. Fortunately for companies, this effect is prevalent throughout modern industry so it does not typically result in a competitive disadvantage. On the other hand, this can create an opportunity for upstart products to grab market share. By focusing on a large class of users and providing a product that addresses their needs better than the unfocused competition.
Counter-intuitively, products designed with a tight focus often prove better outside their focus than unfocused products. I don't think anybody really knows why this happens, though I have suspicions. A focused product tends to be more coherent; it is more clearly thought out. A major aspect of effective design is judicious editing. But it is very hard to edit cleanly when you are trying to fulfill too many demands. The result of editing for ten different kinds of user is much the same as not editing at all. Consider books or movies. A work with a narrow focus is typically better, even outside that focus, than a work that tries to appeal to the largest audience possible.
- Focus Principle:
- Good design requires editing. Focus the design on one principle class of users.
It is easy to attribute the increase in complexity since the 1980s to the ability of software to increase the number of features. But the story doesn't end there. Software doesn't just allow more features, it allows a very different kind of feature. Software allows for abstraction in a way that is traditionally very hard to achieve.
For example, it is actually mechanically difficult to build a device where a single control has multiple effects depending on the device's internal state. It can be done, but there is a natural tendency against it in the engineering of physical devices. Prior to the advent of microchips, virtually all appliances had a direct mapping between physical buttons and features. A knob or button controlled one thing, and almost always in the same way. In modern appliances it is very common to have a single button that performs ten different tasks depending on the mode. Put another way: before software it was cheaper to have ten buttons that directly mapped to a function, but with software it is now cheaper to have one “action” button and one mode switch (or even a mode switching button!).
This property of software is good insomuch as it allows for more features without the expense of extra hardware. It also provides the possibility for far more complex functionality without an equivalently complex interface. But there's a dark side. In his book The Inmates are Running the Asylum, Alan Cooper defines cognitive friction as “the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem permutes.” People have a much harder time learning how to use interfaces where the same action means different things in different contexts.
Cognitive friction (often resulting from abstraction) makes devices hard to learn and harder to remember how to use. Users are forced to develop a conceptual model that guides their understanding of how a device operates before they are able to work with it predictably. A conceptual model is just a user's best guess as to what's going on inside the black box. Sometimes a device has such high cognitive friction that users do not successfully develop a conceptual model. Desktop computers are like this for many people. In this case, most users simply memorize predictable sequences of commands for performing desired tasks.
Programmers are users too, so why are they often unable to predict when software will be hard to use? In my opinion the most distinctive trait of programmers as a class, compared to the general population, is their ability to handle large amounts of abstraction and cognitive friction. Most programmers enjoy working with abstraction: it is considered powerful and elegant. This is the largest general disconnect I have observed between programmers and most other users. Just be aware of it when you are designing software for non-programmers.
- Abstraction Principle:
- Keep track of the “conceptual model” your software requires, and work at making it simpler. Reduce cognitive friction.
To combat this propensity of software, many computer software designers
focus on providing direct manipulation, This just means that, to the user,
the interface provides the illusion of acting directly on objects. A good
example of a direct manipulation interface is the file manager. With a
command line move, you are in essence “ordering” the computer to move a
file between two locations represented by abstract keys (
/a/key/representing/where). In contrast, a file manager presents
the user with a conceptual model where the user picks up a file and drags
it between two physical locations on the screen. This difference in
presentation may seem like splitting hairs, but it can dramatically reduce
- Direct Manipulation Principle:
- Enable the illusion of direct manipulation when there is a reasonable physical metaphor.
A Design Process
Thus far I've discussed several principles of good design. Now let's look at how these can be fulfilled in a design process. A common pattern for successful design processes involves five activities: focusing, researching, brainstorming, editing, and testing. These activities are loosely ordered by their occurrence in the process. Still, it is common at any given point in the design process to be performing a mixture of these activities.
It may be helpful to view the design process as a repeated series of contractions and expansions on the scope of ideas. Focusing on a particular class of user contracts the scope of ideas. Research typically serves to both contract and expand the scope of ideas, though it is more relevant as an information gathering step, and thus typically expands more than it contracts. Brainstorming expands the scope of ideas. Editing serves to contract the scope of ideas. Testing contracts the scope of ideas, as ideas are compared against reality and often culled as a result.
In many ways this is the most complex activity in the design process. Choosing the type of user to focus on involves consideration of diverse areas from market (what is the state of the competition — open source or otherwise, what can be sold, what will people be open to) to development (what can be reasonably implemented). Often initial exploratory user research will help identify classes of users who are not well supported by existing tools. These are ideal candidates for focusing on. In any case, try to document in a concrete way “what class of user performing which activities” you will be designing for.
Major design improvements usually stem from insights about people. These insights can concern many aspects of user's lives. For example, you might consider how people think about a key problem, how a particular group of people interact, the nature of a person's job, long term goals, or irritating distractions people would like to be free of. But to develop insight, you have to understand the people you are designing for. An excellent way to do this is to use ethnographic techniques extended from anthropology.
There are two major sources of information about people: what people say and what you can observe. Don't trust either source exclusively. Even if you talk to far more people than you observe, its still important to observe a few people in your target user class. Observing and talking produce very different cross-sections of information which will illuminate one another.
From these two major sources, try to develop an awareness of: the person's goals (long and short term), what they pay attention to, who they interact with and how, what they think of those people, their physical environment, major sources of irritation, what they want to work on, what they think they should work on, what actually dominates their time, and how existing products shape their work.
There are a few techniques I find particularly useful:
- Interviewing people on the phone is relatively easy. Because you can talk to so many people, its good for building a broader understanding of your user class.
- Contextual interviews involve talking to people in the physical space your design will be used. Many times, this will be the person's office or cubicle. Ask them about relevant objects, tools, people, processes, and even files on the computer that you see around. A contextual interview provides a link between pure observation and pure talking. You can use observations to trigger discussion and vice versa.
- The hardest technique to avail of is shadowing. Shadowing involves following people around and observing them while they go about their business. As you might imagine, it is hard to get permission to shadow people. However, if you can shadow one or two people, you are almost guaranteed to learn useful things that would have otherwise eluded you.
- You can help shape Red Hat's desktop:
- We are looking for companies/individuals to participate in our own ethnographic research. Information we gather will, of course, be anonymous. We want to learn more about corporate system administrators of medium to large desktop installation, knowledge/office workers, and managers. It doesn't matter what operating system you use or administer. If you (or somebody you know) would be open to a phone interview or to being shadowed for a day or two, , please email email@example.com. Several people can participate in contextual interviews at your workplace (especially if you are in the Massachusetts area). Thanks!
A good way to encapsulate this information is as a “persona.” A persona is a fictitious character that embodies the stereotypical attributes (based on research!) of the user class you will be designing for. A persona can be described in a single paragraph or several pages, depending on the need. As you progress through design and development, specific decisions are made relative to the persona, as if they were a real person and the sole user of the target product. Because the persona aggregates the most relevant information about your target user class, a design for the persona will satisfy (most of) the target users. Persona-driven design allows artisan-like focused individual design to target a wider audience.
Another major avenue of research, of course, is existing products (competitive products, complementary products, and earlier versions of your own product). Don't just look at what these products do, but try to infer why particular design decisions were made. Also, be sure to see how people use these products, what features they ignore, etc. Try to figure out why. Just don't let existing products constrain your thinking when brainstorming. It is an easy trap to fall into the more time we spend as users of existing products.
If you are very lucky, inspiration will strike at all the right moments and brainstorming will not be necessary. Most of us need a little nudge in the right direction. Brainstorming is the most “fruity” activity in the process. Perhaps because of this, it is also the least practiced. Nonetheless, brainstorming is critical to designing a product that's more than just a refinement of existing products.
The goal of brainstorming is to provide ample leaping points to new ideas in an unfettered environment. If research is acquiring new information, brainstorming is building new associations using that information. Brainstorming is one of the best ways to transform information into insight.
The basic process is simple. A small group of people start from some simple seeds and build off them with any ideas that come to their mind. The ideas are jotted down as people come up with them on a shared space, usually a white board or flip book. It is critical that the natural tendency to “edit” is temporarily restrained. If you think of an idea, even if it seems somewhat disconnected, say it. It is easy to erase it later when you move to editing. Humorous, or patently impossible ideas often serve as the best spurs toward a radical solution. Free association is a fickle beast!
If a particular problem needs to be solved, brainstorming can be initially seeded around the topic of the problem. If you're just trying to work out ideas, curious observations from research can be a good starting point. Either way, put the seed idea up on the shared space and grow from there. While brainstorming interface ideas is of course important, it is also worth brainstorming about user problems (to get ideas as to what major hurdles that could be solved) and implementation possibilities (but don't tie interface brainstorming to implementation too much).
The first step of editing is to cull the least interesting ideas. Just go through the brainstorming “record” (either captured from a white board, or a flip book) and pick out any ideas that seem interesting. Sometimes it can be helpful to do this in a group, and sometimes it works well to have a single person do this. Often at the end of a brainstorming session it will be clear what the most interesting ideas are. Note that these do not have to necessarily be the most practical ideas. Sometimes it is worth saving a few extreme ideas to feed into future brainstorming sessions.
Secondly, after culling, evaluate each idea's relevance and impact on your target user class (or relative to a persona). Which ideas seem like they would have the biggest impact? Sometimes in editing a new class of user will be suggested. Don't be afraid to switch who you are designing for if an opportunity for a good design presents itself.
Finally, see which ideas are compatible with one another. You want to find a mutually compatible set of ideas that's reasonable to implement. Start constructing hypothetical mixes of ideas, and see which make sense. Often you will find unifying concepts that can give rise to even more ideas. Once you have several good mixes of ideas, try throwing together some simple mock ups, prototypes, or design overviews. These don't have to be specific, but try to translate the idea into a new medium. Once you have several “holistic” meshes of ideas, go back to brainstorming again starting with these as premises.
A design process may involve several or more iterations of brainstorming and editing.
This part is simple: test what you've written on people in your target user class. Ask for their comments, but focus more on observing what they have trouble with. Testing later in the software development process will help “finish” the product, removing little mistakes, bad wording, and other minor usability bugs that can significantly hamper usability. It can also give good starting ideas for major changes for version 2. But even more important is to test early prototypes, perhaps even before code is written using mock ups and thought experiments. This sort of testing serves as a reality-check on the basic ideas you are using for the interface.
Tests don't need to be grand affairs. A few participants will suffice for basic testing; though more is of course better. Give the participants some tasks to do, ask them to think aloud, and jot down what happens. If you have problems getting users to talk aloud, a simple variation is to have two participants work together on performing tasks. They will naturally discuss issues and problems with each other. If you are testing a mock up, have one tester “run” the mock up, and have another take notes when the participant has trouble. Recording the test with a video camera will allow you to run a detailed analysis later, but it is no substitute for a live human observer.
When all is said and done, the most important thing is to decide who your users are, figure out what they need, and pursue them mercilessly (and intelligently!). Of course, following a set of interface guidelines is also helpful and will result in a more consistent user experience. The GNOME HIG (Human Interface Guidelines) contains an extensive set of guidelines covering everything from integration into the desktop menus to proper wording in alert dialogs.
To learn more about design in general, two classics of design still present what is in my opinion the most useful information. If you read one book on design, it should be The Design of Everyday Things by Donald Norman (previously published as The Psychology of Everyday Things). It presents an exploration of “everyday things” and probes what makes them easy or hard to use. It also develops many of the capstone concepts of modern software design. Designing for People by Henry Dreyfuss is the best book I know for getting at the heart of how to think about design. Although first published in 1955, it is still highly relevant and has recently been reprinted.
A more formal, process oriented book is Designing from Both Sides of the Screen by Ellen Isaacs and Alan Walendowski. The two books I previously mentioned are more interesting to read and in my opinion do a better job at teaching design thinking. Designing from Both Sides of the Screen is, in contrast, a detailed technical book. If you're looking for this sort of information I would recommend this book in addition to, not instead of, one of the previous two.