Before you start the design process, consider your overall approach. Think about how you might design its overall interaction style—its personality, if you will.
When you carry on a conversation with someone about a given subject, you adjust what you say according to your understanding of the other person. You might consider how much he cares about the subject, how much he already knows about it, how receptive he is to learning from you, and whether he's even interested in the conversation in the first place. If you get any of that wrong, then bad things happen—he might feel patronized, uninterested, impatient, or utterly baffled.
This analogy leads to some obvious design advice. The subject-specific vocabulary you use in your interface, for instance, should match your users' level of knowledge; if some users won't know that vocabulary, give them a way to learn the unfamiliar terms. If they don't know computers very well, don't make them use sophisticated widgetry or uncommon interface-design conventions. If their level of interest might be low, respect that, and don't ask for too much effort for too little reward.
Some of these concerns permeate the whole interface design in subtle ways. For example, do your users expect a short, tightly focused exchange about something very specific, or do they look for a conversation that's more of a free-ranging exploration? In other words, how much openness is there in the interface? Too little, and your users feel trapped and unsatisfied; too much, and they stand there paralyzed, not knowing what to do next, unprepared for that level of interaction.
Therefore, you need to choose how much freedom your users have to act arbitrarily. At one end of the scale might be a software installation wizard: the user is carried through it with no opportunity to use anything other than Next, Previous, or Cancel. It's tightly focused and specific, but quite efficient—and satisfying, to the extent that it works and is quick. At the other end might be an application like Excel, an "open floor plan" interface that exposes a huge number of features in one place. At any given time, the user has about 872 things that she can do next, but that's considered good because self-directed, skilled users can do a lot with that interface. Again, it's satisfying, but for entirely different reasons.
Here's an even more fundamental question: how much effort are your users willing to spend to learn your interface?
It's easy to overestimate. Maybe they use it every day on the job—clearly they'd be motivated to learn it well in that case, but that's rare. Maybe they use it sometimes, and learn it only well enough to get by. Maybe they'll only see it once, for 30 seconds. Be honest: can you expect most users to become intermediate-to-expert users, or will most users remain perpetual beginners?
Software designed for intermediate-to-expert users include:
Photoshop
Dreamweaver
Emacs
Code development environments
System-administration tools for web servers
In contrast, here are some things designed for occasional users:
The differences between the two groups are dramatic. Assumptions about users' tool knowledge permeate these interfaces, showing up in their screen-space usage, labeling, widget sophistication, and the places where help is (or isn't) offered.
The applications in the first group have lots of complex functionality, but they don't generally walk the user through tasks step-by-step. They assume users already know what to do, and they optimize for efficient operation, not learnability; they tend to be document-centered or list-driven (with a few being command-line applications). They often have entire books and courses written about them. Their learning curves are steep.
The applications in the second group are the opposite: restrained in functionality but helpful about explaining it along the way. They present simplified interfaces, assuming no prior knowledge of document- or list-centered application styles (e.g., menu bars, multiple selection, etc.). Wizards frequently show up, removing attention-focusing responsibility from the user. The key is that users aren't motivated to work hard at learning these interfaces—it's usually just not worth it!
Now that you've seen the extremes, look at the applications in the middle of the continuum:
The truth is, most applications fall into this middle ground. They need to serve people on both ends adequately—to help new users learn the tool (and satisfy their need for instant gratification), while enabling frequent-user intermediates to get their work done smoothly. Their designers probably knew that people wouldn't take a three-day course to learn an email client. Yet the interfaces hold up under repeated usage. People quickly learn the basics, reach a proficiency level that satisfies them, and don't bother learning more until they are motivated to do so for specific purposes.
Alan Cooper coined the terms "sovereign posture" and "transient posture" to discuss these approaches. Sovereign-posture applications work with users as partners; users spend time in them, give them their full attention, learn them well, and expand them to full-screen size. Transient-posture programs are brought up briefly, used, and dismissed. These roughly correspond to the two extremes I posited, but not entirely. See the book About Face 2.0: The Essentials of Interaction Design for a more nuanced explanation of postures.
Someday you will find yourself in tension between the two ends of this spectrum. Naturally you want people to be able to use your application "out of the box," but you also might want to support frequent or expert users as much as possible. Find a balance that works for your situation. Organizational patterns in Chapter 2 such as Multi-Level Help, Intriguing Branches, and Extras on Demand can help you serve both constituencies.
Get Designing Interfaces now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
