To ensure that, we do two things:
There are three tools that we use to do interaction design:
By describing the personas in detail, we avoid the pitfall of talking about a "naive user". Users generally aren't naive. They may be excellent writers. They may be experts on photography equipment. They may know all about their market and their customers. They may be wizards at whipping out complex diagrams from Excel spreadsheets. They may know details about Photoshop you've never even dreamt of. But they might not know our data models, our implementation details, or how to navigate a file system. And they shouldn't have to know. They should stay focused on achieving their own goals. Not in servicing the software.
The goals are often non-obvious, counter-intuitive, or even in direct opposition to the task. Take for example software for scheduling meetings. The task is to schedule a meeting at a point in time where everyone is available. But the goal of each individual user is generally to avoid having to attend the meeting at all. The best meeting is one that you don't attend at all. Normally, such software will send out an email with the agenda once a time slot that fits everybody has been found. If instead, the software sent out the agenda before scheduling a time, people could decide if they had to be there at all, or if they could more effectively make their contribution by email, thus avoiding the meeting entirely.
There are different kinds of goals: Personal, corporate, practical and false goals. Personal goals are basically about feeling good about yourself: To not feel stupid or humiliated, not feel too dependent on other people, feeling accomplishment, etc. Corporate goals are making money, not offending customers, etc. False goals are things like being easy to learn, or saving memory or CPU cycles.
Neither of these are the user's goals. Sure, if the company goes out of business because of our software, the user will be unhappy. But if the software makes the user's life miserable, the fact that the company is making tons of money is little consolation to her. And if you're designing software for the pilot of a fighter jet, ease of learning is a lot less important than being effective in combat for a properly trained pilot.
The last category is the practical goals. These are the goals that connect the corporate goals with the personal goals. They're things like handling the client's demands, authoring an article, or avoiding meetings. These are the ones that vary the most, depending on the situation.
Discovering the real goals is sometimes straight-forward, but often, finding the goals is an Aha! experience. Don't worry if you can't see what they are. We can always design for the tasks, and we'll do no worse than the majority of software on the market. But look out for the goals while designing and implementing, and discuss it with your colleagues. All of a sudden, you get lucky, and you just intuitively know that you've found an important goal.
There are a few different types of scenarios, and the interaction for each should be designed differently. There are the scenarios that the user do every day. Since the user will be doing the same thing every day, it's important that there are ways for the user to speed up and customize the interaction, as she gains confidence and familiarity with the interface. This could take the form of keyboard or other short-cuts, or configuring the placement of things on the page. On the other hand, ease of learning isn't critical, especially not if it comes at the expense of the experienced user.
Another type of scenario is about the things that the user can't avoid doing, but only does infrequently. Since the user will likely never get enough experience to feel completely confident in the interaction, more hand-holding is necessary, in order to convince the user that she's not making any mistakes, and to make sure she knows what's going on. So ease of learning is important here, but flexibility is not.
These are the only types of interactions that we care about when doing interaction design. In particular, we don't care about edge cases. These are the "what if"-scenarios: What if the user wanted to search this field? What if the user wanted to print this page? If something isn't performed frequently, and isnt' necessary for the successful achievement of the user's goals, they can live with having to invest a little extra effort, and suffering through a few frustrations. Besides, our users are likely to be so used to bad interaction design, that they can probably live through another few, as long as they're not too frequent.
Aren't scenarios just like use cases? Scenarios are similar to use cases, but they're not the same thing. Uses cases are a tool for expressing functional requirements of the software. Scenarios are a tool for expressing the usability requirements. Use cases list all the stakeholders, the preconditions, all the successful and failure end conditions. In interaction design, we only care about the users that are hands-on going to use the software. We assume that the software is already functionally correct, thanks to the use cases. The scenarios then help us ensure that we design the interaction with the real use situation in mind.
Problems cannot be solved in the abstract. If we want to solve the real problem, we need to understand what the real problem is. And to understand the real problem, we have to be specific. Why? Because problems often have little twists, that can turn the whole thing on its head. Real problems usually aren't what they appear to be, and definitely not what the people having the problems will tell you they are.
Everyone who's worked on a client project knows this intuitively. The client might say "We need to add personalization to our site". He thinks that the problem is a lack of personalization. But his real problem may be that the content or the functionality he provides simply isn't attractive enough. Or maybe it's too hard to use, so people give up. Or perhaps the fulfillment is too slow. You can never take a problem definition at face value. You'll have to look into the specifics if you want to understand what the real problem is.
Of course, we can't look into every possible user out there. So we need to pick a few that's representative. Why don't we just pick a few real users? Because real users generally have idiosyncracies that don't generalize. So we retain the freedom to design our own, the way we think generalize the best. We look into the details of made-up, peopl that we believe to be representative.
Usability testing simply means watching people use the software. You bring in outside people, and ask them to try to achieve some goal or perform some task, while you watch. Then you take notes of where they stumble. If you can, it's a good idea to videotape the session, both so that you can watch it again to make sure you understood things right the first time, and so you can show it to others when they suggest doing something you've already determined doesn't work. It's very valuable for people designing the user interface to be able to see for themselves the frustrations that users go through, but it's important that you don't interfere: Only tell them what to do, not how.
Usability testing doesn't have to wait for a finished product. It can be done using pen-and-paper mock-ups, which has the advantage that users will be more likly to suggest moving things around. And you can "implement" their suggestions immediately, by changing the drawing, and test it right away. And of course, the earlier the problems are discovered, the cheaper they are to fix. Likeways, usability testing can be done using a simple, non-functional HTML mock-up.
The best thing obviously is if we can get people just like the ones we're targeting, like our personas. But it's not that big a deal. Most usability problems can be caught by anyone not familiar with the interface or the implementation. In fact, you can learn valuable things by asking a colleague from your office if you can watch while he tries to use your interface. It needen't take more than 10 minutes, and you can fix the problems yourself, right away. Generally, it's more important to do usability testing early and often than to do it rigorously and right. So what are you waiting for? :-)
Rev # | Action Taken, Notes | When? | By Whom? |
---|---|---|---|
1 | Initial version | 5/6/2001 | Lars Pind |