Design your way to better design feedback
In late 2015, my colleague Zach and I went out to get coffee and overhaul Optimizely’s cross-functional feedback sessions. Our Web Personalization product team started holding these weekly “design crits” earlier in the year. They worked well while the team was small and scrappy, but became less effective as the team grew.
The primary problem was that the meetings were unstructured. Designers showed whatever they had on hand, they often presented multiple versions of complex flows, and occasionally failed to give enough context or ask for the feedback they needed. While there were engineers and product managers in attendance, the feedback focused on pixel-level concerns rather than meaty questions of user needs, business goals, and technical feasibility.
Luckily, getting better feedback is a problem designers have been working and thinking about for decades, so Zach and I had both personal experience and resources to fall back on. We came up with some basic rules to structure the meeting, as well as to explain the meeting goals, remind presenters of the rules of soliciting feedback, and encourage the audience to give feedback centered around their area of expertise. To reinforce the change in format, we also changed the name of the meeting to “Design Review.”
The success of Design Review rests on its audience, so we catered the meeting to people who have lots of competing priorities. We meet on Wednesdays because people have settled into their work by mid-week, and we meet at 4pm because by then, most people are winding down for the day or just need a break. Each Wednesday morning, I ask the designers what work they have to show and compile and distribute the agenda. Providing attendees an agenda reminds them that Design Review is happening and allows them to prioritize their participation to the features that they care the most about.
Each meeting starts by thanking the audience for being there. They’re busy people, after all, and we appreciate them taking the time to improve our work. Next, we review the meeting guidelines. While we have a core group of attendees, we often have new people or those who attend only occasionally. Reviewing the guidelines helps the audience remember why we’re here and reminds the presenters that they have a responsibility to guide the conversation and get what they need. Whichever designer isn’t presenting will take notes, and the notes are made available in a central location for anyone to reference and comment on after the meeting.
We meet for only as long as there is work to show or conversation to hold. Conversations that get too deep, involve only a few people, or last beyond the meeting time will be spun off into standalone meetings. Design Review is canceled when we don’t have substantive work to show.
Beyond a more efficient meeting and better feedback, one of the best things to come out of Design Review has been that we’ve managed to entice people from around the company to join us. In addition to engineers and product managers, who were already mainstays, the Customer Education team started joining us so they can plan documentation of new features. The Customer Success team drops in and keep us honest about the needs of our users. Design Review isn’t the only avenue by which these things happen, of course, but it provides valuable context and the opportunity for everyone to ask hard questions while there’s still time to change course.
What Attendees Say About Design Review
We’ve been running Design Reviews for about a year, so I recently asked the team for feedback on what was working and what needed to change. Overall, their responses were quite positive:
I was interviewing an engineering manager who asked how engineers and PMs work together. I spent five minutes talking about how well we collaborate; design review is big part of that. It helps people get bought into the solution, helps us iterate faster, and the overall quality of the solution ends up being better.
I really like [design review] in its current incarnation. As I progress in my career, it is something I will try to bring with me wherever I go.
Attendees generally found the meetings to be well run, they valued the opportunity to share their ideas, and felt that we’d created a safe and respectful space where they felt comfortable asking questions and providing feedback.
When asked what worked and what we could improve, the responses often contradicted themselves. For example, one person said the level of discussion worked for them:
The discussions are focused well on the topic at hand and I feel like the extended back & forth exchanges always produce valuable progress at the end.
While another said the opposite:
…sometimes we spend too long on one design because of lots of discussion happening, if the discussion isn’t relevant to me (like its a granular piece of settings that I didn’t know about before and don’t have any opinions on for example), it can get a little boring.
Anyone who’s ever sat in a meeting will recognize these problems. We want a variety of people from different functional roles to get the broadest range of feedback, but that diversity of roles also introduces a diversity in needs, goals and expectations.
Right now, we’re trying to split the difference and the feedback shows it’s not working as well as it could be:
We need to do a better job of making our work understandable, i.e. what are the use cases, why are we working on this, what customer problem does this solve, and so on. I recognize this isn’t easy, especially with a product as technical and complex as ours, but I believe we can improve here.
Onwards and upwards
In 2017, we’ll be experimenting with ways to maintain attendance from across the organization and improve our ability to communicate across functional roles.
We’ve already started holding the occasional Design Review Roadshow, which means we have the meeting on a different floor to encourage people on that floor to attend (it’s amazing what a difference a floor makes). We’re also designing an intro slide to show at the beginning of each designer’s presentation. It’ll ensure that we never forgot to review relevant contextual information and we always show it in consistent format so it’s fast and easy to understand. To balance the overhead of the new slide, we’ve booked extra time just before design review so that we designers have dedicated prep time before we present.
Based on the feedback, design review is valuable to people across our organization, but we also have opportunities to improve. By viewing our feedback meetings as just another design challenge, we can ideate, test and iterate our way to better cross-functional collaboration. In other words, we design our way to better feedback.
