A highly-functioning software team has parallel development and design cycles. Developers and PMs work on building the software, while PMs and designers work together to ensure that the software will meet the user needs. But as a designer, how do you make sure that the team understands the reasoning behind your designs?
Never fear, the design review is the hot spot for designer, product manager and developer to get on the same page.
“Break the habit of focusing on story level – step back and envision the workflow just like your users.”
Simply put, a design review is a regular meeting where designers present their latest round of workflows, and the team reviews and gives feedback. You want to break the habit of only looking at the story level – step back and envision the workflow just like your users. When the team is only looking at stories focused on small features, they can lose sight of the larger picture. But your users won’t.
Designers and PMs (should) always work side-by-side to review hypotheses, build prototypes to address solutions, and ultimately bring beautiful design to the developers. The design review is a checkpoint to help reduce any design churn and put a stake in the ground.
The best part? As a product manager or a designer, it will challenge you to think about your design. Embrace that tension as the team squints at your ideas, and think “will this really help our users?”, “What does this button do?”, “How do I get back?”
Note: I’m a product manager, in no way a designer. Please leave feedback and let me know your thoughts! (or if you want to request a splendid stick-man drawing….)
INPUTS:
Designers and PMs work together to create a design backlog: a list of user needs or features that need to be fleshed out. There are daily conversation and ad-hoc meetings to work out the nuances, and designers continue to iterate. Except……
YOU HAVE A PROBLEM, YOU JUST DONT KNOW IT
Every design looks beautiful at high fidelity. Yet designers think, “If only I had a little more time, I could make this even better”. PMs think, “If only I had a little more time, I could work out some of these edge cases”.
And now you’re in a churn cycle. The goal of the design review is to break this cycle, and say “this is it”. Talk aloud as a group, incorporate that feedback, and then lock those stories down. It won’t be perfect, but it will be shippable.
Here’s how to run a successful design review that encourages effective feedback and provide a path to move forward
Who:
The designer, product manager, and hopefully a developer. Having a developer review upcoming concepts is helpful for their insights on how little tweaks could save a lot of time.
The designer runs the review.
When:
This is a weekly meeting, held the day before the pre-IPM. Since this is *the* meeting for the team to exclaim “this is it”, you’ll want some time for tweaks before the PM turns them into stories.
How:
For each workflow or concept you want to review, write the following on a whiteboard:
– Scenarios/problems you are addressing
– Goals of this meeting: Provide feedback, decide on happy path, choose brand colors, etc
Then paste/tape your workflows right next to each scenario. Start early and have this ready before the meeting begins.
For example: Needs: - Rosie has a song stuck in her head and wants to hear it - Rosie wants to keep hearing more songs after her first song - Rosie wants to hear music play quickly or she'll leave
Your workflow would show step-by-step mocks of how we’ll solve all of Rosies’ problems. She would sign in, see a search box, and enter her catchy tune. After the song ends, we’ll automatically play songs related to her interests.
Start of review:
Before the team even looks at your designs, walk through the goals of todays review, pointing out what you’ve written on the whiteboard. Now start with the first workflow/concept, give a little background about the user needs, and then talk through each screen.
Stand strong, stay on the happy path:
People will always have questions, and that’s great. But it’s common that people focus on the “what ifs?” when you’ll likely answer their thought in the next screen. Be patient, but ask that all questions wait until you’ve walked through the workflow.
IMPORTANT: If you skipped writing out the user needs that you are addressing, your review will go sideways quickly. There are *always* edge cases that the team will bring up, and if you aren’t able to refer back to the user needs then you’ll be building too much at once. Agile design is about learning and iterating, not all-up-front.
FEEDBACK:
Step back, and let the team come up and to the whiteboard and review designs. Hand out post-its so everyone can write their thoughts on each mock. Politely answer questions; remember that you’ve been staring at these screens for hours, for others this may be the first time.
DISCUSS:
Read each Post-It aloud and have each team member explain their thoughts. Just like a retro, listen to the discussion and write down any action items.
Example: There is a Post-It labelled “Why does Rosie need to sign-in?” Since one of her needs was to “hear music play quickly”, the team deliberates and decides that sign-in isn’t needed. An action item is noted to remove the sign-in step.
THE MOST IMPORTANT STEP:
By now, everyone is feeling warm and fuzzy – you just solved all the worlds problems by making Rosie happy! But you’re not done. You need to review the upcoming action items with the PM. Don’t let the PM leave the room without mutual approval.
Pull up your shared design back-log (Trello, Tracker, Asana) and walkthrough the upcoming user needs and features. Are these priorities still valid? Do we need to validate some of these workflows with user testing? Are we still aligned with the roadmap?
A design review might seem like a lot to undertake. But having a regular cadence for feedback helps you talk through your ideas, and provides a timely sense-of-urgency that brings out the creative in all of us. Challenge yourself to get the ideas out of your mind and into the minds of your team.
About the Author
