Why Teams Love This Virtual Design Review
One product designer shares a better way to collaborate
As a product designer, I find facilitating virtual design reviews can sometimes be overwhelming. This is especially true when you have a team of talented and passionate engineers ready to get in and solve problems. So I looked into how to minimize interruptions, meetings that run long, and sidebar conversations about solutions. This is especially helpful for teams that are simultaneously on video chat while using collaboration tools, such as FigJam, Google Slides or Jamboard, or MiroBoard.
I found a way for our weekly reviews to be more productive and less disruptive. It all hinges on a Rotating Roles Review. This is a new feedback process that assigns responsibility for different design aspects to individual team members.
When everyone has a unique lens to guide their review, we uncover key insights and bypass repetition or sensitivities. Each team member is valued for taking on an equal and useful lift. An illustrated example for how it works follows.
Prepare a Prototype
Getting a Rotating Roles Review off to a smooth start requires a working prototype. Each individual interacts with this during the review session and provides feedback based on their assigned role.
Having a prototype that’s either low-fidelity or high-fidelity helps you get the necessary feedback you seek and gives engineers an opportunity to ask more questions. For larger user flows, break them into smaller or shorter flows to allow reviewers to focus on the experience and help surface edge cases and other scenarios.
When it’s ready, set up a virtual design review. That’s when each participant adds their feedback to assigned columns with sticky notes (shown in the preceding illustration).
Assign Roles
At the virtual design review, assign the roles randomly. Bigger groups can share roles. Smaller groups can take on multiple roles. In my experience, the majority of my team prefers taking on all the roles, so they don’t have to constrain their feedback. But, it’s good practice to switch back to assigning roles.
Role 1: The Historian
The historian role asks: “What is the current state of our product today?” They can share technical information that might not be general knowledge. They can provide facts for both the frontend and backend of the product’s framework. It’s important for this role to look at the overall design to assess any overlapping functionalities with other teams in the ecosystem.
One helpful point of reference for the Historian is a RAID analysis chart, the waterfall project-management tool. As someone with historical knowledge, they’ll be able to identify risks, assumptions, issues, and dependencies within the bigger picture.
Role 2: The Critic
The critic role asks: “What can go wrong if we build this design solution?” and “How would this fit in our existing framework today?” They can provide feedback with concerns or challenges the team may face before, during, and after implementation. The RAID analysis chart can support this person’s work, too.
Wearing this hat gives someone not just the opportunity to point out design flaws — but the responsibility to. Finding what doesn’t work is just as important a job as seeing what does work.
Role 3: The Advocate
The advocate looks at what’s good in the design aesthetically and, more importantly, the usability of the proposed design. This role asks: “Is the user flow easy to navigate?”
While this role’s feedback can be subjective, it’s important for this person to keep in mind which user persona will be using the product. For example, will this persona be a business user or data analyst?
Role 4: The Optimizer
The optimizer goes beyond what’s good and considers how it could be great — more efficient, simpler, engaging. It looks at what to improve in the design and its usability. This role asks: “Can we leverage the same UI from an existing screen?” What new designs can we implement to make this better and what other designs can we re-use? It’s helpful for this role to be familiar with the design system library to provide examples and references.
Team Share
After everyone reviews for 10 to 15 minutes, each participant reads out a sticky note and takes a few minutes to discuss the contents of the note. This gives us time to address the comment and prevents us from going off-topic. We mark and prioritize each note for any resolutions, action items, or follow-ups.
To illustrate how the roles give feedback differently, we have a sample mark-up:
- The historian: “The checkbox used in the UI is turned off by default, which is unlike our other platforms.”
- The critic: “Implementing this design solution could cause high testing efforts.”
- The advocate: “This experience is very intuitive, the user flow is seamless.”
- The optimizer: “There could be more color contrast between the text and the background.”
The Result
This new feedback process has eased my previous sense of overwhelm. Now, I feel pride and joy when I read the role-based comments in real time as everyone interacts with the prototype. And it’s not just me. My team continues to share positive feedback.
“I really like this! It’s different when you’re playing with the prototype. It gives me time to think about questions so I can provide better feedback.”
- Irene Fung, Salesforce Senior Software Engineer
Overall, the Rotating Roles Review has significantly minimized interruptions, going over time, and sidebar solution conversations. It also increased participation from every single attendee. The quality of feedback and questions from everyone were worth more than the hour-long sessions we had in the past. And we all even have fun!
With the positive reaction from the team, I’ve now incorporated this feedback process for all of our design reviews.
It can even be used for brainstorming sessions, sprint planning, or any discussions requiring team feedback. I hope that the tips I shared help and inspire you to try using the Rotating Roles Review. I’m happy to get your thoughts on it.
If you try this with your team, I want to hear about it! How did it go? Did you do anything differently? What worked for you? Contact me at: mveneracion@salesforce.com.
LEARN MORE
How to Design a Collaborative Experience (Instead of a Virtual Workshop)
9 Tips for Collaborating Virtually
Why Do We Need to Design Conversations?
Acknowledgements: Thank you to my manager Edouard Picot for encouraging me to share my story. Thank you to Kate Hughes and Hsiao-Ching Chou for helping me put this article together. Special thanks to Emma Lower for helping me get through writing my draft.
Salesforce Design is dedicated to elevating design and advocating for its power to create trusted relationships with users, customers, partners, and the community. We share knowledge and best practices that build social and business value. We call this next evolution of design Relationship Design. Join our Design Trailblazers community, become a certified UX designer, or work with us!
