Karon MacLean
| |
These notes are intended to get you going on your Pass I prototype. They introduce you to the technique of paper prototyping, and also to some techniques for creating the design concept you'll be prototyping. "Prototyping Part II", coming later in the course when you're working on your Pass II prototype, will cover more techniques for taking your interface concept to a point where it can be empirically evaluated with test users. When a small team is initially developing a new concept, it's common to follow a sequence (often iterative) of
before settling down to earnest, higher-investment prototyping and evaluation activities. This process is low-cost and can be a lot of fun; it is a good way to sift through a set of ideas and quickly refine and recombine them into a concept that's worth further development. We'll cover each of these 3 steps briefly in the following.
Brainstorming is a process of deliberate creativity, where the point is to generate as wide a variety of idea-fragments or concepts as possible. They don't have to be good, feasible or complete ideas: the craziest and most nonsensical may have a germ that later leads to an important innovation (and will be more likely to do so than conservative ideas). Likewise, a brainstorm session is not the place to start developing the idea, no matter how great someone thinks it is, because that will shut down the flow. It's all about breadth, not depth. You can brainstorm individually or in a small group. Each has a different function, and some people prefer one mode over another. You might find you can be more creative on your own because you aren't restricted by the path the group chooses, especially for initial idea generation. On the other hand, a group of minds can often keep up the energy level better: if some start stalling, there's usually someone else to pick up the thread. You can build and riff off of one another's ideas, and the fact that you're often coming from different perspectives and experiences means you might come up with different approaches to a problem. For this project, we'll focus on group brainstorming, which is a good place to start if you haven't done it before. There are a few standard brainstorming rules that absolutely must be followed; but as your team gets comfortable working together, you may come up with personal embellishments that work for you. The group size is important: too small and there's not enough energy, but too large and everyone can't participate. 3-8 usually works well, depending on the personalities and experience involved. Find someplace private where you can feel uninhibited making a lot of noise; sometimes the session gets pretty excited. A lounge or conference room with a door that closes and a table you can all sit around is a good candidate. The most important key (and sometimes the hardest) to brainstorm success may be to start with a well-defined set of brainstorm topics. First, identify the larger problem you've resolved to address: for example, "Invent a better way of programming a VCR". As you can see, this is still pretty vague. Then, as the first step of your session or beforehand, come up with a list of parameters on which you'll be brainstorming. There are a lot of ways you could do this. Here's a few possibilities to get you started (do not be restricted to them):
Note that you can also brainstorm to decide what your project will be about, i.e. what system you'll invent a better interface for. Two people in a brainstorm session have to play special roles. It doesn't have to be the same person throughout a session; but there always needs to be two people doing the two jobs. When your group gets experienced, the facilitator's role may become automatic; but it still needs to happen.
In taking the notes, the key is to rapidly capture enough of the thought that the group can recognize it hours or weeks later. Quick little sketches are a good practice to develop. Okay, you're ready to start. Follow these rules religiously!
what was that about popcorn? You know how when you're popping popcorn, there's not much for a while, then there's a couple of pops, then suddenly those pops are coming like crazy? After a bit it starts slowing down, and pretty soon you're back down to a pop now and then. Brainstorming is sort of like popping popcorn: and if you wait til you're well past the peak pop-rate, you're dead in the water. It's the facilitator's job to notice when the idea-rate has slowed down, switch the topic and get onto the upswing of the next popcorn curve again. Never try to beat a topic to death. Everyone will get discouraged and bored. Instead, jump to a new topic while you're hot. See how things go, but short is usually better than long. Good brainstorming is exhausting. 30-60 minutes is as long as you should expect to be productive, and you may get the most done in just 15 once you learn to get into the right mindset quickly. When you've all run out of ideas or gotten tired, then collect your notes and (the same day or after sleeping on them) go through them again with your judgement turned back on. Decide what ideas still seem most worthwhile, and look for ideas that combine well. The group should meet again to choose their favorites, based on both promise and feasibility. For your Pass 1 design for this project, you can probably only afford to choose one design concept to further develop; but keep those notes around. You should plan to look at them again later in the project - some of them might seem more valuable then. If you have a concept you feel good about, you're now ready to proceed to the next stage. If not - try another brainstorm session with a different set of topics.
This is another technique for developing your design; not only in early stages, but throughout the entire process. The basic idea is start thinking early and very specifically about who you are solving this problem for, and the ways in which you expect those users to utilize the system.
A prospective-user based approach which I've found very useful is to imagine a set of individual users who span the possibilities of those you expect in terms of abilities, motivations, tasks, etc. Develop these people: give them names, personalities, jobs, families. Imagine as much about them as you can. If possible base them on people you have real experience with - e.g. family or friends, or, if you were doing this kind of thing a lot as a job, users you have gotten to know through interviews, focus groups and other methods of observation. The more intimate your knowledge of any aspect of these person's lives, the better this exercise will be. It's not bad for one of your cast to be someone kind of like you - as long as it's not the only, or the dominant, member! Then, imagine each member of your cast using your interface. Let's take Tom. We've given Tom an identity... now, what basic important problem is Tom having which this new kind of interface would solve? What exactly would he want it to do for him? What kinds of concerns might he have about it? How often would he use it? Where would he be when he's using it? What else would he be doing at the same time? How much would he (or his employer, or whoever would be buying it) be willing to pay for it? Then do the same thing for Sally, who has a completely different set of concerns. Let's use an example. A little while ago I worked with a startup company marketing a software system which would host a secure virtual network along with a version of ASP (Application Service Provider). A participating institution could allow its members to share all sorts of data and information remotely as if they were all inside the same firewall. Further, due to some great new compression algorithms, participants could work offline and very rapidly "synch" their local copies of the network. Finally, the system was modular enough that an "institution" could be as small as a single individual who wanted access to her data from anywhere without having to carry it around on her laptop or host a webserver at home; or a huge distributed corporation that wanted to facilitate telework or who's employees had to travel a lot. This system functionality (notice that there's no interface at all yet) invited a lot of variety in potential users which we needed to explore as we chose which aspects to focus on developing. Since we were a small company, we also had to choose which users we were going to design for (and market to) first: we couldn't do all of them. The Cast of Characters technique helped here: we generated a cast and for months afterwards, the development team referred to the individuals by name when talking about some type of feature, and everyone else knew what they were talking about. "Theresa would like that, but Barney wouldn't ever use it, and we've decided to go for Barney". Here's some of the people in the cast we used. Perhaps you can guess a little about them from their names:
If you're curious, the initial developments for these characters (along with some other requirements lists) can be seen here. You might guess (correctly) that Sally the Scientist was highly autobiographical and was of course my favorite character. The thing was, that as we later came up against issues like, "How - exactly! - are people going to pay for this? Who controls access? What kind of groups should we support?", then thinking about it in terms of Sally, Tony or Frank made many things immediately clear. This was true for both the underlying functionality, and for details of the interface. We settled on a couple of the characters as our initial proto-users (unfortunately Sally wasn't one of them or maybe this company would still exist!) and as we began to talk to real clients - real examples of these characters - we were able to flesh out our users, give more key detail, in some cases to reject details that turned out to be poor assumptions. In summary: this technique has value at several levels.
There is value in simply formulating the cast, and further value in applying the cast over a long term to your design problem. Finally, the cast becomes a communication device within your team, a shorthand of shared experience which you can all refer to. An alternate approach to developing imaginary (or not so make-believe) individuals is to start by brainstorming on all the different things for which this system might conceivably be used, and then use this list to test your concepts and designs as they develop. This approach can be a little more lightweight (since we don't have to invent whole lives for people), and especially appropriate when the technology involved is simple or peripheral or occasionally used, and we don't expect it to play a really central role in users' lives. Let's say we're redesigning a simple digital wristwatch. What are some activities for which we expect this device might be useful? Maybe they are activities for which the device is already used, but with problems and frustration. Here's a few (I'm sure you could think of more):
Once you have what you think is a pretty good list (and perhaps have listed your other constraints, such as "can't cost more than $30", and "attractive and compact enough for a woman to be willing to wear it all the time"), you can make some new lists:
You may well discover is that it is very hard to make the same interface support all these activities very well. In that case, you might need to prioritize the functions: focus on a particular set of activities that go logically together, and make them work well.
A paper prototype illustrates how the interface will (or might) work, without any computer implementation of functionality. Similar to the concept of movie "storyboards", it is a portfolio of sketches which briefly tell the story of what can happen when a user comes in contact with your interface. Your job here is to show rather than describe. For this class we'll do pencil-and-paper storyboards (literally on paper) for Pass 1. They are most useful at the earliest conceptual stages, because one doesn't get so bogged down in details of making a computer tool work. However, the same concept can be used for more sophisticated hyperlink tools. These become appropriate at later design stages. At any level, someone looking at your finished storyboard prototype should be able to easily ascertain each of the following:
Prototypes can serve a variety of functions and be intended for different audiences (e.g. your design team, evaluators, your boss, test users), and it's always important to be clear from the start on who will be using yours. You are designing your Pass 1 paper prototype for at least 3 audiences and functions:
For a branching computer interface, you'll likely do best to start by developing a flow chart, showing the choices a user has at each step in an interaction. Try to think of all the situations that might arise, and all the information the user might need or the actions they might want to, or inadvertently take. If your flowchart becomes too large or unmanageable, it may be an indication that you need to simplify the problem in some way (constrain the interaction or reduce scope of which part you will prototype). The flow chart will be most quickly developed with pencil and paper - and eraser. You can eventually either turn in a neat handdrawn version or draw it on the computer. Here you'll create a sequence of hand-drawn sketches which illustrate the choices a user has (and what they look like) as she moves through a number of usage scenarios.
As you develop your storyboard, keep in mind that you'll be handing it off to someone use to analyze without you standing there explaining it. Make sure it will communicate its message without you there. alternate storyboarding methods There are almost as many ways of storyboarding as there are people doing it, and it is a technique with variations among many fields. If you have other ideas for how you'd like to develop and present your paper prototype than that outlined here, ask the course staff and see whether they agree they are appropriate before proceeding.
As always, if you come across good links, send them to us and we'll add them to the list. http://www.cs.berkeley.edu/~landay/research/publications/CHI96/short_storyboard.html |
