|
|
|
| Print version | |
Related Links |
|
| My Design Tools – Part I | |
| My Design Tools – Part II | |
Background Links |
|
| Using Prototypes | |
| Review of Paper Prototyping (Carolyn Snyder) | |
By Lee Barnard, Knowledge Design & Engineering, SAP AG – December 1, 2000
We all know that it makes sense to build and test a prototype before you build the real thing. Whether you're building a rocket, a building, a toaster or a software application, you can avoid a lot of problems later by investing time and effort during the design phase. But what is the best sort of prototype to build: electronic or paper? Read the story of Mary and John, who work as developers for a software company, and make up your own mind.
John: "How's it going Mary, I heard your group is working on a
new application, too?"
Mary: "Yes, John. We completed some site visits to collect the customer
requirements from the end users. I'd like to start with the programming now,
but our boss said he wants to see a working prototype to make sure we're on
the right tracks."
John: "Well, that makes sense. Imagine putting in all that work
without knowing if anyone will be able to use your application!"
Mary: "I agree. I've been learning how to use this new simulation
program for creating electronic prototypes. It can do such a lot: graphics,
layout, and it can even simulate some of the user interaction. It only took
me a week to master it. Now I can start building the prototype of the application
all by myself."
John: "Sounds good. Our team have decided to do our prototyping
on paper."
Mary: "Paper! That's kids' stuff isn't it?"
John: "I know. I'm a bit skeptical, but our user interface designer
is really enthusiastic."
Mary: "Well good luck. Let me know how you get on."
Two weeks later, after work...
John: "Hi, Mary! How's the project coming along?"
Mary: "Quite well, thanks. I've almost finished building the prototype.
The other developers had lots of different opinions about the colors and the
layout."
John: "Oh yes, I remember those sort of discussions at my last company.
It's amazing how many different opinions there are about icons and other little
things."
Mary: "You're right! And the program I'm using to build the prototype
can't do it exactly how I want it. In the end, I have to decide myself what
I think would be best. That's the good thing about owning the files - I get
to design it how I want."
John: "What about the interaction side? Have you tested any user
scenarios yet?"
Mary: "Well, not yet. I've been concentrating on the look and feel
and I haven't really had a chance to do any testing. What are all those marks
on your hands, John?"
John: "Oh, that's ink. We had our paper prototype session this morning
and it was rather messy - pens and bits of paper everywhere, you know."
Mary: "Now I remember. Your team is building a paper prototype.
Tell me about it."
John: "Well, there are five of us on the team: me, the technical
writer, our colleague from marketing, the guy from our help-desk, and our user
interface designer. We looked at all the information from our user and task
analyses and from our site visits again and listed the main things the customers
want the application to do. We already had a rough plan of the application structure,
so we were soon all drawing, redrawing and literally cutting and pasting. After
about three hours we had a reasonable working prototype. It was really exhausting,
but good fun. Real teamwork, too!"
Mary: "And you just used paper and pens?"
John: "No, we also used sticky tape, scissors, glue and so on. All
the stuff you have in the office. Oh yes, and sticky notes in different sizes
- they're great: if you decide you want to move buttons or change the position
of fields, you just stick them where you want them. Anyone can do it. We already
did some internal testing this afternoon, too."
Mary: "Ha! How can you test something that's just on paper?"
John: "Easy. You write down some of the user tasks and find someone
to try to complete them using the application."
Mary: "But you don't have an application, do you, just bits of paper."
John: "Yes, we do. The screen is a large sheet of paper and the
things you see, like fields and buttons, are on separate pieces of paper so
that you can move them around if you need to do a quick redesign."
Mary: "But how can the tester behave like a user without a mouse
and a keyboard?"
John: "The tester has to point at screen elements and say what she
or he is trying to do. And if they want to make an entry, they just write it
on the user interface in pencil."
Mary: "Okay, but you can't simulate the software, can you."
John: "Yes you can. You just add bits of paper when new buttons
appear, or replace the page when the screen changes. You can even highlight
things using transparencies with shading or lines drawn on them."
Mary: "Hmm. And who did the testing?"
John: "We asked a couple of consultants who were here today. It
was lucky we did. They spotted some interaction problems we hadn't seen, and
they had some ideas on how to improve the terminology, but it was easy to change
that. We also found out that nobody needs one of the extra functions, so we'll
make things simple and leave it out."
Mary: "Wait a minute. You mean to say that in one day, your team
designed and built a prototype, tested it, got feedback and did a redesign?"
John: "Er, yes!"
Mary: "And what about the user day tomorrow? You can't take a load
of paper to the customer site. It won't look very professional will it?"
John: "Oh, I hadn't thought of that. I wish we had a smart electronic
prototype like yours."
Mary: "Never mind, John. Any prototype is better than nothing. "
After the user day...
John: " How did your use day go?"
Mary: "Great! The customer was really impressed when we presented
the user interface. They didn't even notice it was a prototype!"
John: "That's good. So now you can implement it without changes."
Mary: "Yes. And how did your customer react at the user day?"
John: "Well, they tested our paper prototype with us simulating
it. We explained that we were still at the design stage and they didn't seem
to mind. In fact, some of their end users helped us to do a minor redesign while
we were there. They liked that the paper medium, because they found it easier
to provide input by actually showing us what they meant."
Two months later...
Mary: "Hi, John! I heard you're already working on your next project."
John: "Yes, we implemented the last application and the customer
is really pleased. But you look stressed, Mary."
Mary: "I am. Remember that customer who liked our electronic prototype?
We implemented it and shipped the application and now they say can't use it.
"
John: "Are there bugs?"
Mary: "No. It works and meets most of their business requirements
but the end users aren't happy about the usability. My boss says we'll have
to do a major redesign."
John: "Why didn't the customer say anything when you presented the
prototype?"
Mary: "They said they thought it was finished and didn't like to
tell us. I wish I'd tried paper prototyping and involved the end users more."