The importance of sketching in product design

There are a lot of hurdles to creating an effective product team. Perhaps the biggest hurdle of all is managing the relationships among the product team members and how those relationships affect the process they use to envision, design, and build the product they’re working on.

The relationship between designers and product managers is a particularly interesting one because both parties often want to do a little bit of what the other is responsible for. Many PMs want to do some of the product design and many designers want to guide where the product is going. It’s a fuzzy line, to be sure.

At HubSpot we have seven product teams, each with a designer who works closely with a PM. Every relationship is unique because of differences in personality, skills, and experience. Over the last two years I’ve seen a lot of different scenarios play out, some leading to good outcomes and some leading to bad ones.

However, there is one consistent trend I’m noticing more lately. When a designer and PM are out of sync, it’s because one of them has gotten ahead of the other in some way. For example, when either party goes off and starts dreaming up a new design by themselves, friction happens when they come back and say “Look at what I did!”. The other party is usually dismayed for some reason, either this wasn’t what they were thinking or it was something they feel they should be responsible for.

The way to fix this is deceptively simple: product people should sketch together. By this I mean they should get in a room with a whiteboard and draw out the screens they intend to design and build. Nothing complicated, just the simple act of sketching together at the same time.

I know this sounds trite, but there are many benefits to product folks sketching together. Here are several ways that sketching together gets people working together better.

• Agreed upon creation time. When a designer or PM goes off and does initial creation without involving the other person, they get out of sync. By sketching together, you create a time in which both people can get into sync at the start of a project, even if they’ve been thinking about the problem beforehand on their own (and perhaps sketching on their own). By having a time set explicitly for sketching together, all of those initial ideas get out at the same time and as part of a conversation, so neither party feels behind. Since the purpose of sketching is to produce a set of agreed-upon sketches, there is no pressure to have something fully-formed before then.
• Agreement on what you’re building. You also get agreement on what exactly it is that you’re building. Is it a single screen?, a set of screens?, an email flow?, a iPhone app with notifications?, an addition to an existing screen?, or something else? By sketching out the screens you implicitly answer this important question that keeps everyone on the same page.
• Agreement on screens to be designed. In addition to making clear what’s being built, sketching outlines the specific pieces that need to be designed. This happens almost organically from the sketching session…as you draw screens and what each one has on it you’re effectively determining what type of interactions users will have with the product. Even in sketches you can make choices like “Should this be a popup?” or “What type of information should this form have?”. You won’t get much more detailed than that, but you won’t need to at this stage because the big things are what you’re focusing on.
• Agreement on flow. Sketching also naturally shows the flow between screens. A smooth and logical flow is crucial to the effectiveness of software, yet so many processes treat features as independently-existing screens. When you sketch several screens and show a flow between them, team members can quickly determine whether the new screens make sense together or amongst the old. In practice I’ve found this to be especially valuable…flows are so important but aren’t always talked about normally.
• Captured thoughts. When you sketch, you should always be capturing. That way, you have captured your conversation and don’t need to have it again. Think about how many times you feel like you say the same thing over and over to your team members…when you capture and share you don’t have to repeat yourself so much. This is a huge time saver.
• Builds trust. Finally, I think sketching together builds trust among anybody who is present. They see that each person is passionate about building great software, each wants to participate and help envision where the product is going to go. When people go off and do things on their own, without this step of coming together, then trust is eroded because each party is wondering if they will be heard.

Sketching outlines the big idea of the product, and once that is in place each party has pretty clear responsibilities for building and implementing going forward. Once you’ve got the agreement that sketching gets you, everyone leaves the meeting room satisfied that their particular viewpoint has been covered and there will be many fewer surprises when the designer returns with the high fidelity mockups or a prototype. And the developer (if they are present for sketching as well) also now clearly knows the direction of the interface, so can respond or raise concerns as well. Sketching, when done together and agreed upon, sets clear expectations for the future that the entire team can rely on.

I’ve noticed that after getting out of one of our sketching sessions, the product teams are noticeably more confident about where they’re headed and why they’re going in that particular direction. From the designer’s view, the next step of creating a high fidelity mockup or prototype is straight-forward. From the product manager’s view, the big product questions have been answered and the direction is clear. All from the simple act of sketching together.