Agile User Centered Design

Recently, a group of folks (including myself) from AboutUs.org attended a workshop called “Agile Product Design with Jeff Patton“. Jeff is a really smart guy who has been doing some great work to bring Agile software development techniques to the product design and user-centered design fields.

Let’s****step back and look at how most software and websites are developed. Companies often start a new software development cycle by having their business people identify a market opportunity. The business analysts and marketing people sit around and come up with either a new product or a feature that they can sell to their customers. Then they get the designers in, who make a “sweet” interface for it. Finally, a big specification file, describing the new feature and how it’s supposed to work, gets handed off to the developers. They’re supposed to make it all work.

This is what software people call the waterfall, because each step pours into the next. There are many problems with this process, but the biggest is that****if any of the assumptions made at any one step are wrong, you don’t know until you get to the end of the entire development cycle. You’ve wasted a lot of time and resources.

Another frequent consequence of the waterfall method is that the final product can vary significantly from what the business analysts thought they getting. That’s because there was no opportunity to check back with the business case during the development cycle.

Here at AboutUs, we’ve always used the Agile method of software development. Now, with Jeff’s help, we****feel like we’ve got a very cool improvement to Agile that helps us define what we’re going to build, how it’s going to work, and how it’s going to deliver value.

The Product Shaped Hole

Next we started to identify which tasks each customer type wanted to perform on our site. These tasks range from “logging in to edit,” to “reviewing recent edits for abuse,” tousing new features we are still developingor would like to develop.**
**

We can take these tasks, turn them into “stories,” and build a “story map” that describes the personas and their activities. Our business goals govern the entire process. They tell us which personas matter, and therefore, which tasks matter. That in turns informs every development choice we make.

So what’s really cool about this story map is that it’s a physical object that everyone can see. It reminds us continually of our business goals and the people who use our site. It governs everything we do, right down to each small, actionable chunk of software, and each of these becomes its own particular story.

Some of these stories have been delivered — our site does lots of stuff already — and we still have plenty of stories we want to complete this week, next month and within the next year.

The coolest thing about this story map is that it’s still alive. You can see what’s done, what we still want to do, and, if you’re the type to read between the lines, what we haven’t thought about. And it’s those unfinished and unthought-of stories that are the “product shaped hole.”

This isn’t a complete description of Agile user-centered design. I haven’t covered paper-prototyping, sketchboarding, walking skeletons or other cool techniques. But story maps have really changed how I think about software and Agile, and it’s going to change how we build things at AboutUs.