In October I had the opportunity to attend the Grace Hopper Celebration of Women in Computing and was able to learn from heavy hitters in the industry. While in a workshop centered around design critique, presenters Frances Haugen and Alexa Herasimchuk from Pinterest explained that incorporating all team members is crucial – different perspectives make for the best products. However, they really got me thinking about how to include cross-functional teams to get the most out of your critique.
Why Developers Resist
It’s always easy to get other designers to participate in design critiques – it’s our world as designers, and we know the feedback loop is crucial the success of the project. But by only including designers, you limit yourself, and by extension your product. While every designer will have a different opinion about your solution, chances are they are approaching it from the same general perspective – one that is trained in design and user experience. To get the best product, you need to leverage different viewpoints with a fresh set of eyes. That means including your cross functional teams – your business analysts (BAs) and your developers.
In my experience, I’ve found it’s not difficult to get buy-in from BAs to participate in design ceremonies, so here I’m going to focus on getting meaningful participation from developers. Typically, when I ask developers to participate in a design studio or critique, it’s met with great hesitation and lots of reasons why they shouldn’t be part of it. “I’m not trained in that, I just make it work” or “I don’t know what I’m doing” are the most popular rationalizations. Even if you do wrangle a developer or two into a design critique, their feedback is often strictly technical and centers around what is and is not possible from a coding perspective. While that is valuable feedback we need, design critiques are about so much more than what can be done – we’re asking the question should it be done? Is this the best solution? Here is where the developers usually go mute. And as long as they are uncomfortable, it’s unlikely you’ll get much feedback from them beyond technical feasibility concerns.
Here’s where my aha moment (courtesy of Frances and Alexa) comes into play. It’s all about framing the exercise in a meaningful way for developers. Developers participate in code reviews all the time – it’s a standard for their discipline. While there are many types of code reviews, they can be incredibly similar to design critiques. Both have the common goal examining a piece of work and determining what about it works, and where improvements can be made. Both utilize an open group format on a localized subject to get feedback. Both take that feedback and use it to make tweaks and enhancements to improve the product. A piece of code can work just fine, but it may not be optimized. Design is the same way – one solution can work, but is it the optimal solution for the user?
Securing “Buy-In”
Imagine there is a developer on your team who is hesitant to join a design critique. A few days before the critique, ask the developer to walk you through a typical code review. How it is structured, the point of the code review, and who is present should all be addressed. You’ll get a breakdown of the entire process, and as they are explaining, ask questions. They’ll likely touch on the importance of predetermining a set of code to review to ensure everyone stays focused. They’ll talk about how they establish goals they hope to accomplish in the code review. They’ll also mention how it is most valuable if all developers attend, regardless of seniority. Without any of these items, the code review would greatly suffer.
When they have finished their walkthrough, point out how everything they just explained parallels design critiques. Design critiques limit the scope of critique to keep everyone focused. Design critiques also have set goals, including ensuring at the conclusion the designer has received constructive feedback and has clear next steps. And just how it’s important for all developers to attend code review, it’s important for all members of the team who touch the project attend a design critique – the work a design team does impact the entire team.
A junior developer should still attend and participate in code review even though they are not as experienced as a senior developer. They have a different perspective and can bring fresh ideas on how to solve a problem – just as developers can in a design critique. Walking a developer through the similarities will help reframe the review, and clearly demonstrate the value they bring to the critique.
Make Them Feel Comfortable
If nothing else, developers use websites and applications, and they have opinions on what they like and don’t like. They may or may not be your target audience, but they are online consumers. You want to foster an environment where they feel comfortable giving feedback. I was once on a project where it took the developers over a month to tell the User Experience team they thought a part of our design was clunky – and they were right! Imagine the time and work we could have saved if they had spoken up earlier, or better yet, if we had brought them in earlier.
By relating the exercise format to something they are comfortable and familiar with, you’ll likely get buy in earlier, and more active participation during the critique. Remember, they have just as much stake in the project’s success as you do. Your team shares the common goal of creating the best product possible for your stakeholders and users. A great product starts with a great design, which is best achieved by active, positive collaboration across all cross functional teams.