How do you redesign something

Over at HackerNews “prateekdayal” asks:

I run an online music community with decent traffic and usage. When we started out, I had no background in web (and usability) and have learnt a lot in the last two years. I can now tell whats lacking in the current design (aesthetics/usability/interaction wise) but still don’t know if I can design from scratch. I do have a designer (to help with graphics) but he is good only with skinning so I have to do the usability and interaction design work.

What is the best way out of this situation given that I can’t hire external help (for financial reasons of-course). I have been thinking of reading some good books on web design patterns and following standard practices. Does that work well?

The biggest thing to manage in a redesign is risk. Risk you alienate your user base or do something that negatively impacts revenue, or whatever you’re most afraid of.

The easiest way to manage it is to shorten your feedback cycle (not user feedback, any type of feedback) to the smallest possible interval. When talking about design, this means you need to spend the least amount of time on the design you can before you put it in front of someone that exemplifies your average user (persona).

CC Kyle Steed http://www.flickr.com/photos/kylesteeddesign/

CC Kyle Steed http://www.flickr.com/photos/kylesteeddesign/

This is usually done through some sort of lo-fi mock up or wireframe first. To do an effective job at that, you probably first want to evaluate your information architecture. However, this whole process shouldn’t take more than a day or two of work. That means you may only “waste” a day of work if your direction ends up not working out. You haven’t involved a designer, you haven’t pushed a single pixel, and you definitely haven’t written any code, but you’re already getting into a feedback loop.

To test a wireframe in front of a user, you want to do something called “wizard of oz” testing. This is a process where you take paper versions of your wireframes, and put them in front of a user. You can cut up hte prototypes to make the pieces easier to change out as you let the user “use” your wireframes. Don’t worry about how rough your wireframes are as you’ll find that people are pretty forgiving when involved in woz testing.

Another great thing about wireframes is that it’s extremely fast to iterate on a them. You can sometimes make small changes while you have the user right there doing the test. Larger changes will probably only take a few hours. Again, this is a feedback loop on changes of 10 minutes to 4 hours.

This whole process might take you 3 or 4 days of work, but the feedback loop it creates may save you 3-4 months of work down the road. It’s probably also going to save you money when it comes time to actually do a design (which you want to again test with the users) and implement your changes (which you can test through bucket testing).

Each time you can create a feedback loop throughout the process, you’re decreasing the risk of the redesign. It’s not dissimilar to writing unit tests to make technical refactorings more manageable. Unit tests are the ultimate in development feedback loops and decrease the risk that changes you make to your code base are going to break unexpected other parts of the code base. The same things can be said for user testing feedback loops for visual and UX designers.

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

©Jeff Patton - 2009

©2009 - Jeff Patton

Jeff’s process starts out by identifying who your customers are. This is user-centered design. At AboutUs, we have identified 14-15 different types of customer who use our site, each for a different set of reasons. We have fleshed these types out into profiles that we call “personas.”

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,” to using new features we are still developing or 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.

marked_up_story_map

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.