`

Turning Meetings into Design Sessions

In their heart of hearts, most meetings want to be productive work sessions. Here are tools to make that change happen.

Sajid Reshamwala

--

Much of product design involves working through a repeatable process while being flexible enough to arrive at novel solutions. Like when sketching something new yet familiar, I’ve realized its useful to have back-pocket frameworks to get the underlying structure of the process out of the way so that I can focus on the interesting details.

Here is a selection of five such frameworks. Some simple, some more complex, all indispensably useful

1) How Might We’s and Sticky Voting

Useful For: Defining a problem when Jimmy from product gets stuck in debates with that guy from marketing that always shows up (how does he keep finding these meeting invites anyways?)

votes. and stickies. votes. votes. and stickies.

Hmm, you say. This sounds like two techniques, not one. Why yes, yes they are. And two techniques shamelessly stolen from Ideo’s Human Centered Design Process at that. But alas, this devilish pair is deserving of their exception. These two techniques are like two lumberjacks; somewhat mighty on their bristly own but pair them together and they can fell the mightiest of redwoods (i.e. loquacious meetings).

If not properly answered, the ‘what problem are we solving’ question will keep coming back to haunt your team all the way to your projects end. A great way to start answering this question at the beginning of a project is with a brain dump of all of your team’s relevant user research, analytics, and product strategy for your team to meditate on together. Simple enough, eh? The twist to make this meeting productive is, during this brain dump, don’t allow for any conversation. Instead, have everyone in the room capture their thoughts on post-its in the form of ‘How Might We’ questions. These should be the questions that team members feel are important to have answered by the end of the project. After the brain dump, have your team stick their questions up on the board for everyone to silently vote on using stickers (i.e. sticker voting). Afterwards, you’ll find yourself with a heat map of the most important problems to handle as articulated by your team members.

Sound tedious? I promise, it’ll be much faster then leaving the ‘what problem are we solving’ question unanswered throughout the life of your project.

Pro Tip: In the real world, some voices are worth more than others. If there are stakeholders that will be the final decision makers, give them super votes that are worth 10x of a regular vote.

“The goal of inclusive design is not to be democratic but rather to be open and effective.”

Further Reading: The Secret Phrase Top Innovators Use

2) The Proto Persona

Useful for: making sure everyone is trying to solve the same problem for the same type of person. Even when it feels like you should have done that already.

the proto persona: a persona to be properly desposed of after use

A familiar scene: You’re white-boarding out UI with your team and trying to get aligned, but you keep getting stuck in a cross fire of varying opinions tucked behind crossed arms. Then it hits you. The reason everybody is at odds is that everybody is thinking about the problem in terms of different use cases. So what do you do?

Enter the proto-persona.

Proto-personas, or quick, good-enough personas, are like full sized, data backed personas but without the deep research and contentious detail. Proto-personas are NOT personas and don’t serve the same purpose. While personas are about creating a vehicle to capture the use cases that your users are experiencing, proto-personas are just about make sure your team is thinking about the same use cases. I’ve realized that a big part of product design is making sure the answers to the ‘why’ and ‘what’ questions are clearly articulated even when you’re building out the ‘how’. Creating quick proto-personas is a fast, easy way to assure that you and your team have the same answers to these questions.

“A big part of product design is making sure the answers to the ‘why’ and ‘what’ questions are clearly articulated even when you’re building out the ‘how’.”

Pro Tip: While the proto-persona can be created during a meeting using everyones’ input, you’ll be more successful if you show up with some of the persona’s attributes in your back pocket. Your goal at this point is to align, not reinvent.

Further Reading: How To Make A Proto-Persona And Get Everyone On The Same Page

3) 5-E model

Useful For: Getting your team to think about experiences when your product is turning into a pile of feature requests.

so simple and oh so powerful

This framework. This framework is my big fat beautiful baby. If you’re trying to explain to someone what user experience is, this is the framework to kick off that conversation. The 5-E Model is a chronological framework that pushes you to take whatever you’re working on and break it into a 5 step experience from the user’s point of view: enticement, entrance, engagement, exit, and extension. Seem super simple? It is and thats what makes it so powerful. One of the foundations of UX is to move beyond the meat of your product’s core use case to its outer edges. The 5-E framework forces you and your team to do that. Feel like you’re stuck talking about a feature and not a product? Sketch out how the user would use the feature in question with the 5-E’s and your team will be thinking holistically again. Do you have the nagging feeling that no one is really sure how your users arrive or leave the part of the user experience that you’re talking about? You’re probably right. This framework will make sure that you do.

Pro-Tip: The 5-E framework can also be used during research to understand the current experience and what’s broken about it. Use pictures. Include peoples’ faces in said pictures.

Super Pro-Tip: If it helps, you can think about entice as the ‘cue’ from Charles Duhigg’s “The Power of Habit” and extend as the ‘reward’ that you’re providing users by coming back or sharing their experience with others.

Further Reading: I Heart Frameworks

4) UI shorthand

Useful For: Collaborating on ui flows with your dev and product team.

big ups to the mighty Ryan Singer

I ran into Ryan Singer’s work a couple years ago and I was put off by its simplicity. How can something so nuanced and ephemural as the craft of a user experience be expressed with words and arrows? I then I got over myself. Without getting tied up in form and shape, Ryan’s UI shorthand is a simple tool for white boarding a user experience when you’re still figuring out what that experience is. Because its so low fi, it becomes incredibly inclusive. A great exercise is to write each one of his ‘user sees, user does’ pairs onto a sticky note while you and your team talk out the flow. If you’re still working out the ux flow you’re still early in the process so feel comfortable moving these stickies around and crumpling up the bad ones.

Pro Tip: The danger of low fi work like this is that its easy for everyone to have different ideas of what the final product looks like. You can get everyone on the same page by following this session up with wireframes or a hi fi mock that you can share out with the team.

Further Reading: A Shorthand for Designing UI Flows

5) Process Flow Diagram

Useful for: Working out the logic of when your product does what.

I’ve got a homemade brownie for anyone that can come up with a better shape for ‘decisions’ than a freakin diamond.

Part of moving beyond ux and into product design is having the legs to move about in a world that requires a designer to understand how something is implemented. One simple tool to help you make this transition is the process flow diagram. The process flow diagram is basically visualized boolean logic. Being able to whiteboard a process flow diagram during a meeting can mean the difference between hand waving to ‘some problem that dev will figure out’ to getting in there and figuring the problem out with them. Warning: going through the process flow diagram with your team is going to force you to ask dumb questions. That’s the point. Being willing to ask dumb questions is a designer super power that needs to be developed. Get comfortable feeling a little stupid now and your team will thank you later. Eventually, you’ll even thank yourself.

Pro-tip: Your team members will steal this framework and use it in their own meetings. And that’s cool. Let go of the black turtleneck. Embrace the embracement of design.

Further Reading: Ultimate Flowchart Guide

“Your team members will steal these framework and use them in their own meetings. And that’s a good thing.”

And those are my five go to frameworks for turning often unproductive meetings into product work sessions. Give them a try and tell me what you think.

Better yet, go make something cool and make me jealous so that I go make something cooler.

--

--