There’s a baker in San Francisco named Josey. He owns a popular bakery and coffee shop called The Mill. Josey’s bread is really good, but it’s also not cheap. Loaves sell for $7 and up. And they sell toast — with toppings like almond butter, cream cheese or house-made jam—for $4 a slice. This is a lot of money for toast, but it’s so good that people line up down the block to buy it. It is that good. 

Josey also wrote a cookbook teaching people new to breadmaking about how to make bread. He writes in an approachable, un-intimidating style. Joseys’ basic message:making bread is easy.  

In the same way Josey sells bread, and teaches people how to make bread—we do the same thing at the design consultancy where I work, Cooper. We sell our design services to clients. And as part of those projects, we also teach clients about design and our design process.

That sounds crazy.  

Why teach people how to design (or bake bread)? If you teach everyone how to design (or bake bread), then no one will buy your design services (or your bread). Well, the opposite actually is true.


Josey’s right. Baking bread is easy. I’ve made bread from the recipes in his book. And it really started to illustrate for me the difference between decent bread and good bread. I know what a good loaf looks like. I know what a good loaf tastes like. I also know that compared to Josey, I don’t make good bread. Really good bread is really hard to bake. There is a lot of care, patience, and craft that goes into a good loaf. So if I want to have fun getting flour on my hands and making something, I’ll bake myself. If I want a close-your-eyes-and-sigh-happily loaf of bread—I’ll just buy Josey’s.

 Same thing with design. When non-designers learn a little about design, it helps them more easily recognize the difference between decent design and great design. And it helps them appreciate that great design requires a lot of care, patience, and craft. It can’t be rushed. Just like a good loaf of bread. 

When we design, we design for impact. Design works as a multiplier. And when reality hits, we can have three levels of impact: 

Design Multiplier Zero: We create a design, sometimes a brilliant one. But once it comes time to collaborate with product management and engineering, it doesn’t get built—for any of a number of reasons. In this case, design has zero impact. The return on that design investment is nothing. 

Design Multiplier Good: We create a design. And the product management and engineering team to create the product. This is great. In the design consulting world, this means that the company got their money’s worth—we did what we told them we could do. Often this means they’re coming back for more. And by “more” I mean “more design work to solve other problems.” 

Design Multiplier Great: We create a design. And not only does that design help the product that we were told to work on, but it also helps inform other areas of the company. The design has an impact beyond its original intent. It inspires them and gives them purpose. Often this means they’re coming back for more. But “more” in this case means “more design education to push the company’s culture even further.”

So how do we accomplish this? 

Well, more and more, we’re including an element of design education in our projects. We gather in the larger product team — design, product management, engineering, and sometimes sales and marketing—and bring them along in our process. We teach them how we do design. Starting with research fundamentals that lead to an understanding of users, and going all the way through sketching and building out a framework.

“Instructing signifies the most elemental form of collaboration.” 

–Chad Robertson, Tartine Bakery

For most of the design teams, this isn’t really groundbreaking stuff. We do have a few tips-and-tricks that they pick up along the way. Mainly our target is actually the engineering and product management teams. Giving them an understanding of the design process gives us a common language, and makes it easier to have conversations with them about why we’re recommending certain things and where the tradeoffs lie. It increases our chances of having a higher multiplier effect.

 

No, really. Exactly how does it work?

For a client we recently worked with, we went through a Compressed & Controlled Studio—using their actual design problem to teach the product team about Cooper design thinking and methodologies, then having them learn by doing mini exercises that mirrored key milestones in our own design process. The key here was to be explicit with the team about what we were doing, why we were doing it, and what it was leading to next. At every step.

Workshop 1: Preparing for research. 

We start workshops where we start any design process: by working to gain an understanding of users. We teach the team about the basics of user research—asking open-ended questions, avoiding leading questions, and starting broadly before working towards interface-level issues. We have individuals come up with a short interview guide—then put people in teams of three with one interviewee, one interviewer, and one observer/note-taker. 

Through this process, the team learns that while they do know a lot, they also have some inherent biases. This worked especially well with a recent client where the team had been brought together for the purpose of salvaging a sinking product—they all came from different parts of the company, so all had different thoughts on what was frustrating.   

Having a separate observer/note-taker is a tactic we use at Cooper, so we model that in the workshop. Having that role gives the interviewer the ability to focus on making a connection with the interviewee instead of multi-tasking. It’s also helpful if the interviewer gets brain-freeze in the middle of the conversation, since the observer/note-taker can jump in with questions to keep things moving and allow the interviewer to gather themselves.

Explicit Meta Conversation: Check your biasses. 

We point out—although the team usually realizes it—that it’s easy to inject bias into the conversation with users. And that deep product knowledge is no substitute for talking to actual users.

Workshop 2: Looking for patterns. 

Between the first and second workshop, we go out and do the actual user research. We’ve found that it often helps to have a client, especially a non-designer shadowing us on research—this adds credibility to the observations we’re presenting to the larger group. Then, before the second workshop, we assign some homework. We provide the team with a selection of raw interview notes and ask them to look for patterns or interesting observations. 

Then when we come together, we take all those ideas and put them into key clusers—usually using the tried-and-true Post-It note method. This is the part of the process where we’re starting to build team-wide empathy for our users. Patterns will emerge that are expected, but there will also be some significant unexpected patterns that arise.

Explicit Meta Conversation: You are not the user. 

Engineers are weird. Product Managers are weird. Designers are weird. Unless you’re building a tool for one of these roles: We are not our users. 

Usually, this is a particularly exciting reminder for engineers. A developer’s thinking is inherently corrupted by trying to do the best thing for the codebase. So even with the best of intentions, they’re not going to be defaulting to a user-centric point of view. But this serves as a great reminder and an opportunity to step back and empathize with the users.

Workshop 3: Turning patterns into personas. 

Usually, we have the third workshop right on the heels of the second. Here we take the patterns we’ve identified and turn them into a powerful design tool: personas. We tend to do two exercises: 

  • Creating a series of attribute axis, then explicitly mapping individual users to these axis. This creates clusters that we can then use to create personas — ensuring that we covered all major clusters across our personas. 
  • Creating provisional personas based on our initial evaluation. This is especially useful when our research has been light—we can use provisional personas as a hypothesis to test in further  

Both exercises are intended to illustrate how we construct personas, and how they get used. We focus heavily on writing good goals—not just tasks—for our personas.

Explicit Meta Conversation: It's Art and Science.

Some organizations have personas fatigue. They’ve tried using them before and they haven’t worked. Many non-designers view personas as made-up characters with no basis in reality. 

By tying persona creation explicitly to research, the team realizes that these personas are NOT just plucked out of thin air. And they’re easier to work with — because the context is baked in—than just a long list of requirements. 

Brand X wound up fully embracing personas. They started referencing their personas by name after this — not just the design team but the whole organization. The product and engineering team switched to writing their sprint stories as “Tina wants X to achieve [goal].”

Workshop 4: Exploration

The fun stuff. In our fourth workshop, we take those personas and their goals and use those to write a few quick scenarios while taking care to stay just abstracted enough that we’re not yet delving into an explicit solution. Because we then take those scenarios and identify key plot points—then sketch, explore, and brainstorm using those plot points as a jumping off point. 

In the workshop, we generally do timed individual drawing—one idea per note card—then share out to the larger team and spend the next timed drawing session iterating on the best ideas.

Explicit Meta Conversation: Context matters. 

There’s usually a realization sometime during the day that there was a lot of thinking and grappling with user needs that drove some of the more innovative solutions that come up during the workshop. The brainstorming can be much more directed, productive and inspiring with the right context—and personas and scenarios provide that context in an easy-to-grasp shorthand. But that context only comes with a lot of hard work that finally led to putting pen to paper.

Waterfall for instruction. Not for every day. 

Obviously, teams are not always going to be designing in this waterfall-like fashion. But for teaching purposes, it pays to be more deliberate. After that, the team can go off and apply these principles to their particular company, product and situation. 

That said, it does help to illustrate that the design part of the work is important. When engineering and product understand the process, they understand that their internal design team needs space to work. 

But the workshops also have the added advantage of giving agile teams some much-needed space to zoom out and think deeply. It got them out of the pressure and cadence of two-week sprints and got them thinking more deeply about fundamental problems.  

So don’t be afraid to teach non-bakers about baking. Or non-designers about design. We can all appreciate a good loaf of bread (or a well-designed product). 

This article is based on a talk I gave at interaction16 in Helsinki, Finland. Slides for that talk are here.