Design reviews: How to please everyone!
Ushering projects off into the sunset by better planning reviews with PMs, Customers, Developers and Executives
A few months into my first full-time job as a UX designer, a couple of thoughts kept creeping into my mind:
If my job is to design for end-users, why am I spending so much time reviewing my work with other co-workers?
In my grad school program, everyone—professors, classmates and project partners—pushed me to design in a single direction, to create a preferred future state for the user. No matter how varied, conflicting, or brutal the critique, I naturally believed I was always moving forward in the right direction. My path to meeting user’s needs felt as short as this:
At a large company like VMware, there is a definitively longer path to the end-user, and for good reason:
However, the problem that presents itself in a larger organization isn’t necessarily the sheer number of eyes on your design, it is that each pair of eyes is interpreting it in their own, unique way.
How can I design to meet end-user needs if every stakeholder wants something different?
From the outset, it should’ve been obvious to me that each stakeholder I worked with would have a different opinion. Through grad school I was prepared to balance stakeholder concerns and find the sweet spot with a cool Venn diagram. But, it’s one thing to role-play as a PM, developer, or client, and another thing to do it as your singular function at a big company. I was taken aback by some of the questions that came my way, especially when I was confident that my design fulfilled user’s needs. I needed to adapt to this environment, and regain that feeling of moving forward.
Navigating stakeholder reviews for better results
I decided that if I wanted to be better prepared for stakeholder reviews, I needed to develop a loose framework to help me succeed. Through plenty of introspection and advice from fellow designers, I drafted some simple principles to guide me throughout the design process:
- Be aware of what each stakeholder needs from you to move forward
- Decide what you need from this stakeholder to move forward
- Always stay in control
Then, I applied these principles across each of the different types of stakeholders I work with every day.
Product Managers
If you’ve done your job thoroughly, you’ve already previously agreed on a set of user stories. A PM’s fundamental interest is in making sure the design satisfies this, with no gaps. To that end, don’t just pull up artboards from Sketch. Clearly show a sequence of mockups that fulfill each user story. Another point of interest for PMs is how the design varies across the lifecycle of a product—from the first-time user experience and users who’ve been upgraded from a previous version to users with partial access to the product.
Don’t just pull up artboards from Sketch. Clearly show a sequence of mockups that fulfill each user story.
If a PM acknowledges that your design is the best way to accomplish those user stories, you’ve just earned tremendous leverage, particularly in moments of disagreement with the development team.
Customer Reps
They are especially interested in how your design can improve the lives of employees at their companies. In which case, I would only present the scenarios that pertain to these employees. It is tempting to show every user story, especially the ones you’re proud of. But, in my experience, this may cause more harm than good. As customer reps look at each new mockup, they subconsciously think through deployment of these features, and transitioning from existing systems. Avoiding any additional worries could help you steer conversation towards the design, and ensure you remain in control.
Ultimately, our design also needs to make the company money, and customer buy-in is a step towards achieving that.
Developers
While these interactions may seem tedious at the outset, they are incredibly valuable. Your design is being vetted by someone highly specialized in thinking through different contexts, form factors, and stages in the product lifecycle. Having previously been a developer myself, I can confirm that it is one of life’s great joys (ok, maybe I’m going overboard) to know that a designer has thought through the “non-happy” path for end-users.
It is one of life’s great joys to know that a designer has thought through the “non-happy” path for end-users.
Developers complete the aforementioned path to the end-user. Articulate as many details as possible about the design, and make sure the developers have imbibed them, or your vision will not be realized.
Executives/Managers
If you’re going to show anyone your ‘moments of delight,’ this is the audience to do so. Executives do not have the time to actively listen through a complete presentation. They are concerned with how your design takes forward the product/company vision. Beyond that, they are always on the lookout for snippets they can share with other executives, or customers. So, it is probably worth thinking about an elevator pitch for the feature, in the off chance it makes its way into someone’s presentation :-)
During the design review, make sure you’re checking items off a pre-agreed agenda, so executives don’t momentarily forget which meeting they’re at!
The path to end-users is long, and stakeholders can at times seem like obstacles. However, keeping stakeholders’ viewpoints in mind during the design process has made me a better designer. Most of the approaches I’ve mentioned in this article—focusing on user stories, articulating details, preparing elevator pitches, thinking through edge cases—are useful tools to improve your design, regardless of your interaction with stakeholders. Thanks for reading, and please share your experiences as you navigate your way in partnering with stakeholders. I would love to hear!
