With the recent release of Tag Builder 3.0, the User Experience initiative has been made visible.  In the previous article*, I introduced the new Tag Builder with a brief overview.  In this article, I will walkthrough the user centered design approach that grounded the new design, Paper Prototyping.

There is a good chance that if you hang around me for more than an hour or so, you’ll hear me sneak Paper Prototyping into the conversation. If it were a religion, I would be one of its most devout members.  For those of you that aren’t familiar with this usability design methodology, it is defined by Carolyn Snyder in her 2003 book on the subject as ,”Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn’t explain how the interface is intended to work.”  This might not seem so revolutionary on the surface, just one of many usability exercise/methodology options that a designer has in their toolbox.  However, when you break down the fundamentals of Paper Prototyping into its core tenets, the power of its simplicity becomes more apparent.

Paper Prototyping hardware

1. Define the Problem
As Einstein once said, ““If I had an hour to save the world I would spend 59 minutes defining the problem and one minute finding solutions.”  With Paper Prototyping, you begin by creating scenarios.  These scenarios are tasks from a user perspective that need to be completed.  An example scenario from TagBuilder was, “Ryan does a lot of testing with his site and uses the subdomains testing.acmetoys.com and staging.acmetoys.com. He wants to make sure that these subdomains do not contaminate the data for the main www.acmetoys.com website.”  We started with about 50 of these scenarios and ended up with about 20 grouped by four different user types.  What is great about this exercise is that you can include others outside your development team to help define these tasks.  This includes support, services, and even customers themselves.  Again, this isn’t defining features, this is defining the tasks that a certain type of user is trying to accomplish.

List of tasks (or scenarios)

2. Collaborate
Designing and developing software is not a naturally collaborative process.  Each contributor usually has their own computer designed for one individual.  Sure there are technologies like chat, wikis, and shared source control, but these tools help add collaboration to an individual environment.  With Paper Prototyping, you gather the same team that is tasked to build the application into a room to create the prototype.  This includes the project manager, the developer, the designer, the tester, the writer, etc.  The goal is to go through the tasks and design the solutions on paper.  No computers.  Just paper.  Additional tools are scissors, sticky notes, markers, removable tape, and removable glue sticks.  This is the original cut and paste.  As you design the paper version of the application as a team (all should be working with marker and paper in hand), each team member must bring their constraints with them.  That way, if the designer slaps a button down on a certain screen, and the developer realizes the implication of that button being there implies that they must do a massive restructure of the backend to allow the functionality that that button implies, the developer can speak up and offer an alternative to solve the task another way.  By bringing these constraints forward, the team avoids most situations where one team rejects a design late in the process due to a time and resource issue.  With Tag Builder, we completed the new design in one week with a six member cross departmental team.

The Paper Prototype

3. User Testing
When the design is ready by solving all of the tasks in the scenario list, it is good practice to user testing with each other by taking turns playing the user.  You’ll find by putting on the mindset of the user, you’ll find quirks and issues with the design you just couldn’t see when you were in design mode.  When the team is confident they have a good prototype, it is time to bring in outside users for testing.  You can also take the prototypes with you and take the tests to where the users are.  I once tested a website designed for professional truckers and conducted the testing for that project at a truck stop.  The nice thing about paper prototyping is that users seem to have a good time during the tests.  One reason is that it is paper.  Instead of sitting a user down in front of a computer where it can feel like you are testing their computer skills, you sit them down in front of a paper sketch of an interface.  Immediately this puts the users at ease and they are quite relaxed.  Their finger becomes the mouse and scraps and a pen becomes their keyboard.  Paper Prototyping also works best when you test with two users at a time. You ask them to work as one user and to agree on any action before taking it.  This allows you and the team facilitating the test to hear the dialogue between the users as they try to accomplish the task.  This avoids the problem of interrupting the user and breaking their natural flow to constantly ask them why they did this or that after the fact.  When the first test is done, the team regroups and tries to solve any problems the users ran into during the test before the next test starts.  This allows you to iterate between tests.  I usually try to allow for an hour to an hour and a half.  With Tag Builder, we tested with five groups of two people.  By the last test, the users had no challenges with the interface on any of the tasks.

Screen grab from a Paper Prototyping session

By starting off our process with Paper Prototyping, it allowed the Tag Builder team to start with a shared, collaborative design experience and to iterate the design of the application many times before we sat down in front of our computers.  The process doesn’t catch everything and a few concerns or issues have been brought up with the new design since it launched.  We are aware of these and will adjust the design/flow to correct them in upcoming releases.  However, the new design is a reflection of not only our own design sensibilities but also a direct response to the usability issues that surfaced during our design process with actual users.  We also ran a series of Paper Prototyping sessions at the Engage conference April 7th and 8th on a different and much more ambitious product. We appreciate all who participated and their feedback is influencing our design in a profound way.

If you are interested in learning more about Paper Prototyping,
the book is a great place to start or you could attend the workshop that I am conducting at WebVisions May 20th in Portland, Oregon.

Paper Prototyping Workshop at WebVisions May 20th

In the next article, I will walk through the specific design changes with the new Tag Builder and what they mean for the future of Webtrends user experience.

* Between the first article and this article, my wife and I had a new baby boy and so the frequency of updates to this series was thrown for a loop. The rest of the series should be published much more frequently.

Tags: Paper Prototyping

This entry was posted on Wednesday, April 22nd, 2009 at 6:00 am and is filed under Industry Perspectives, User Experience. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.