A simple recipe for using collaborative sketching with Agile and Lean UX teams
In a design studio, everyone sketches and shares ideas. By everyone I really mean everyone: UI designers, developers, testers, product managers, business stakeholders, end users, customer service people, and anyone else interested. Everyone feels involved and engaged. Everyone quickly learns that the best ideas aren’t any one person’s but a mashup of everyone’s. And, on top of all this, it’s fun. And, you deserve a little fun.
This article contains the Design Studio Recipe from my book User Story Mapping. That, and a bit more background, and link to a quick reference guide that might come in handy.
A brief one-sided history of Design Studio
At one of the first IXDA conferences, maybe the first (I forget), I heard Bill Buxton speak. He’s the author of Sketching the User Experience, and he’s great. I like listening to him speak. But, he delivered a dig to Agile Software Development saying that “Agile’s problem is that they iterate, but they don’t ideate.” I spent a lot of time complaining about common Agile practice myself, but, it’s one of those things where I as the insider feel like I can complain, but I started to get a bit ruffled hearing an outsider complain about my community. I was grumpy for a few minutes until I realized he was right.
Ironically, at that same conference, I saw Jeff White and Jim Unger deliver a talk on a practice they called Design Studio, a fast way to do collaborative iteration in an Agile environment.
Meanwhile, on the other coast of the United States, Brandon Schauer and Leah Buley at Adaptive Path were describing a collaborative ideation approach they called Sketchboarding.
I was lucky enough to chair the first UX track in the Agile 2009 conference, and I begged Jeff and Jim, and the folks at Adaptive Path to come and present. It’s there that I learned there were too many similarities between the two practices to call them different. And, in fact, I’ve seen the practice of collaborative design sketching evolve to combine the best of their two approaches. And I’ve seen it iteratively improve over time as it’s been adopted and used by a variety of organizations.
For a good contemporary description of Design Studio style workshops, take a look at Will Evans’ article. And watch my friend Todd Zaki Warfel describe the practice. Multiple round of his 6-8-5 approach is super fast, and super high-energy.
Ideation is Harder than Iteration
We are good at iteration. Not just Agile people, but all of us. To iteratively improve something, we create it, take a look at it, and then decide how it could be better. That’s natural enough. My wife hates it when I do this with something she’s cooked.
But ideation is different.
To ideate means to come up with a variety of different possible solutions. What that means is you might start with a perfectly good first idea, then set it aside and come up with another. But don’t stop there. Come up with ten more, twenty more. You might ask yourself “Why would I do this when my first idea was perfectly good?” In fact, you might have fallen in love with it moments after you thought it up. But, you push yourself to come up with all those other ideas because, in truth, your first idea is rarely your best. In fact, if you’re building a product, your first ideas are likely similar to everyone else’s first ideas. You don’t end up with innovative products by coming up with the same solutions everyone else does.
Ideation is hard. It feels unnatural. Human beings are pragmatic satisfiers. That’s a fancy way of saying that when things get hard, we’re quick to say “Yeah, I think that’s good enough.” And while the first couple ideas are easiest, it’s the 5th, 10th, or 20th that are really hard. It’s not hard because it takes a long time. It just feels hard. But, you’ll have to believe me when I tell you that it’s well worth the little bit of extra mental energy.
Here’s the Design Studio Recipe
A Design Studio is a quick, collaborative approach to ideation. There are lots of ways to do this right, but here’s my simple recipe.
Invite a group of people whose opinions and ideas you’d like, and whose buy-in and understanding you’ll need to build the product. 8-12 people is a good number.
Describe the problem you’re solving. Review the work you did to frame the opportunity. Review personas and any “now” maps that describe how people work today. Review any solution maps you may have started, but be wary of saying too much. If they anchor their ideas on yours, you may be missing on some of their great ideas.
Optionally share examples and inspiration. Discuss and show other similar products that are good examples. Discuss and show products that may not be the same, but that have good ideas in them that could be leveraged.
Everyone sketch! Give everyone paper, pens, maybe some sketching templates, and a fixed amount of time. I see as little as 5 minutes, and as much as 60. I like using 15 minutes.
In small groups, share ideas. I like doing this in groups of 4, so if you had 12 people, break that into 3 groups of 4. Person-by-person, share your best idea. Team members give feedback. Coach participants to give feedback on how well the solutions address the problem, not on how much they like them. Coach them to build on other’s ideas. Continue person-by-person for a fixed time-box—30 minutes usually works for me.
Optionally repeat. Ask each group to share their best ideas with other groups. You could do this science fair style by walking around. Then do another round of sketching and sharing. Encourage everyone to steal, combine, and improve on each other’s ideas.
Ask each group to consolidate their best ideas into a single sketched solution. This is the hardest part. Take 15-30 minutes for this.
Ask each group to share their best, consolidated ideas with the whole group. Discuss these.
Thank everyone, and gather up the sketches and ideas. You, your UX designer, or your core discovery team will need to leverage them to create a final best consolidated UI sketch. In the words of my friend Leisa Reichelt, “Design by community is not design by committee.” You’ll have lots of good competing ideas here, and someone’s got to make the tough call.
I’ve been teaching Design Studio as part of Product Ownership and Product Discovery training for a long time now. Here’s the one-page Design Studio Quick Ref that everyone gets in the class for the practice.
I’d Love Your Feedback
If you’ve got comments or suggestions for improvement, leave a comment. If you’ve found a link for another good writeup on the practice, let me and everyone know.