Spend just one week to get the information you need to build your product right first time. Use these techniques to plan your sprints or even to work out what product to bring to market.
Design Thinking
Design Thinking, or User Centered Design, is all about putting users at the center of the design process. You can get user data and turn it into a prototype design all in one week. That makes it easy to fit this work into a sprint planning cycle.
- Watch some users completing their tasks
- Interpret what they tell you without bias
- Create actionable product ideas
- Turn your ideas into designs
- User test your designs to make sure you solved the right issues
…all before you even start coding!
Why do this?
You want to get closer to your users so that you can build something that they’ll love. There are several other benefits though, both in the shorter and longer term.
- Stops arguments
- You end up with real data about how your users behave. It helps you with your initial design work, but you’ll come back to it time and time again.
- You can use the results from this exercise to stop feature arguments before they even happen.
- Great team bonding experience
- Everyone on the team works together during the Design Thinking week; developers, testers, product managers, marketers, sales – everyone has input and everyone learns from the results
- Cheap
- The biggest outlay is a week of your time. You already have all the other materials you need
- Easy to interpret results
- You just have to react to big issues – no need for statistics
- Long-lasting value
- You’ll come back to the observations you made time and time again
- You can create personas from this data to bring your users to life
- You can measure every new feature decision against what you know your users will want
- Quick way to improve the product
- One week from research to a tested prototype
- Gives you the stories you need for backlog planning
- Helps you contain risk
- Gives you the tools to track progress against user-centered goals
Who does this?
The whole team is involved. Initially they’re going to be skeptical because they want to start coding rather than doing something they’ve never experienced before. However, once you get the team out and actually watching real users suffering through their existing tasks, you will turn everyone into user advocates.
OK, enough sales pitch already, how do I do this?
Follow the steps in the blog posts on this site.
In advance:
- Recruit some representative users. Do this about two weeks in advance, and schedule the visits for the Monday afternoon of your Design Thinking week.
- Recruit five ok-if-they-aren’t-very-representative users to be participants for the paper prototyping, and schedule them for Thursday morning and early afternoon.
Monday:
- Morning – overview of the week for the team, and train them in observation techniques.
- Afternoon – pair team members up (or threes if necessary) to do site visits. Try and get each group to see two different users if possible
Tuesday:
- Morning: Create an experience map
- Afternoon: Pull personas and scenarios from the experience map
Wednesday:
- Morning: Design Charrette to come up with design ideas for implementing the scenarios
- Afternoon: Create paper prototypes
Thursday:
- Morning: Final touches to paper prototypes, then user testing of prototypes
- Afternoon: Fix issues found in user testing, finalize paper prototypes
Friday:
- Extract stories from paper prototypes, create backlog as a story map
- Plan sprints using backlog items (links to Jeff Patton’s work)
- Assess risk and create user-centered tests to contain risk
- Party
If you’re contemplating undertaking this with your team, please get in touch with me – I’ll be happy to answer any questions you have after you’ve read the information on this site.
Update August 2012: Why not watch the video case study of this process at work?
Update 2019: Yes, this process is still relevant. The term “design thinking” has taken off now, but user centered design techniques have been around for ages. We just keep adapting them to be relevant to new dev processes.