maintained by Lars Pind.
(updated June 5, 2001)This part of the process will help determine the right feature set to implement, and it'll tell us which user interfaces to build.
How do we know? We ask real users, and make the rest up. If it turns out that you have to make everything up, at least try to make things up from the user's point of view, rather than from the implementation side.
We don't design for real users. Real users have idiosyncrasies that don't generalize. Instead we construct some made-up users, called personas. These are the users we design for. We have a standard set of personas that we use. If you find that they don't match your user population, make an appropriate one up, or let me know through the bboards, and we'll figure something out.
We'll have to create a separate user interface for each persona using the software. Each persona should have a coherent user experience, appropriate for that persona. A bboard application may, for example, have three: The visitor/participant interface, the moderator interface, and the web master interface.
However, when a particular functionality is to be used by more than one persona, we'll often find that if we design the interface for one of them, some or all of the others will be reasonably happy with that interface. In that case, the persona we design for is called the primary persona, and the ones we don't design this particular interface for, are called the seconday personas.
But this isn't the case by default. You'll have to argue why an interface designed for one persona will be usable for another. If their demands or their goals are too different, we might need to implement separate user interfaces for each persona, for the same functionality. This is in contrast to how we've designed user interfaces in the past.
Focus on the important scenarios. There are those scenarios that our persona do every day (the daily use scenarios). The interaction for these need to be effective, and there must be ways for the user to customize and speed up her work as she gains confidence. Then there are the things that the user do infrequently, but that are necessary to do every once in a while (the necessary use scenarios). These need to offer more hand-holding but can be less flexible. And the rest, we don't care too much about: If they're not done frequently, and they're not necessary, our time is better spent elsewhere.
For cross-checking purposes, list for each scenario all the tasks involved. Then list all the tasks involved in all the interfaces for the software component as a whole. Then check this against the feature list (the numbered requirements) to see if you have covered all the functionality listed in the requirements, and that you have covered all the tasks.
This should be presented as a matrix with scenarios along the top, and tasks down the side. The matrix might be very large, and hard to keep in sync, if requirements aren't stabilized, but it serves as a useful cross-check that we haven't forgotten any tasks, and that we haven't included any requirements that aren't necessary.
Iterate as necessary. Sometimes, coming up with personas that you're decidedly not designing for can be helpful. Sometimes listing the scenarios make it easier to understand the personas and goals.
- What personas are going to use this software component?
- What are the goals of these personas when using this software?
- For each primary persona, write all relevant scenarios, each telling the story of the persona achieving a goal.
- For each scenario, determine the individual tasks involved.
- Do the matrix of tasks and scenarios.
The goals are often counter-intuitive, and may even contradict the tasks. For scheduling software, the goal may actually be to not have to attend the meeting in the first place. For collaboration software, the goal may be to be more independent of each other, to not have to collaborate directly. For a television news program scheduling software, the goal is to always have a complete program ready to air, in the light of last-minute, or even during-the-show changes, not to gradually build up a show that isn't done until the show airs, as you might otherwise think.
Lateral thinking is also important when we get to user interface design. For more on this, see my May presentation, as well as the books The Inmates are Running the Asylum, Are Your Lights On?, and the Lateral Thinking book mentioned above.