Stakeholder management strategies for UX projects: Research breaks ties
As design leaders, we’ve all been in situations where a high-level company leader or major stakeholder requests a change in a design without much evidence or research insight to back up the decision. The first time this happened in my career, my team and I developed a solid working method to get over this speed bump with success and manage the relationship smoothly.
Early in my career, I worked at a consulting company in a department that built and maintained products that supported our consulting work. Much like the environment at Think Company, I worked with insanely smart people and we all got along. We didn’t mind taking risks with the work we were doing. We followed a methodology akin to agile, years before the Agile Manifesto was written.
On one high-profile product, we were making great progress. We were trying to change the way our products worked, and an early market test achieved great results. The data and feedback we received helped us refine the product to better meet the needs of our clients.
The team was feeling good about going into our alpha version, until we received some unsolicited feedback from one of the company leaders that can be summarised as:
“I don’t like the color. Make it blue.”
Since this moment, I’ve learned some lessons about how to effectively manage situations like this. Here are the approaches that helped us move forward in this instance and beyond—and has set our team up to move forward rather than stay stuck in a debate of wills.
First, point to research, customer feedback, and other forms of evidence
The specific leader in my story was not using a euphemism. His main issue was not the content, delivery, positioning, or any of the other innovations we were introducing. He just didn’t like the color palette we had chosen for the product—the UI, printed materials, marketing, everything—and he wanted us to make it blue. It wasn’t his product line, but he had the influence to make a stink, so he did.
Designers know that making a change to a complex palette is not as easy as it sounds. Making global palette changes was even more difficult back then. The changes would wreck the timeline and budget for the alpha release.
Our immediate reaction, which we thought was quite fair, was to emphasize research as a major component of our work to date. We said, “thanks for the feedback. We’ll keep an eye out for any user feedback on the color palette during our next set of field tests.” We had a client advisory panel on the project to help steer our direction, and we had run a few field tests in the form of design validation exercises. At every stage we collected feedback and nobody expressed concern about the color palette. He was not satisfied.
This issue tumbled us into days of tense meetings and emails. Our position was that we had a plan for collecting feedback and none of it supported his concern. His rationale was, “I know our customer base, I work with them every day. They won’t like it. The product will tank if it’s not blue.”
Work together
Those meetings were difficult. We were relatively low-level individual contributors while he was a leader in the organization with a lot of political influence. His opinion was based on years of experience and observation that we did not have.
This was years before Malcom Gladwell published Blink, but we were a consultancy, so claims of experience were commonly used by people to get their way. It took a lot of effort for us to present our rationale without reacting defensively, saying things like, “we don’t trust your gut” and “stay in your lane” to a leader with a lot of tenure.
The truth was, we didn’t trust his gut. We had a well-articulated process for identifying design issues—aesthetic or otherwise— and we wanted to trust it. But we knew we needed to approach this in a way that would help us move forward.
In order to make progress in this politically-fraught debate, we developed the mantra, “research breaks ties.”
The benefit of this approach is that it doesn’t immediately negate anyone’s position, and is very difficult to challenge. In fact, it acknowledged that his concern may have merit, and if it did, we’d discover it during our field tests. Leaders with more clout chose to trust our process. We were eventually approved to move forward with minor revisions to our discussion guides that ensured we were investigating his concerns. We proceeded into the beta without touching the palette.
In the end, our clients loved the product and color was not an issue. In fact, the product exceeded all of our metrics for success and set a new standard for product development.
Turn “make it blue” requests into relationship-building opportunities
As we developed more products, our team adopted the term “make it blue” to describe feedback that was based on opinion rather than fact. Rather than fight our stakeholders, we developed methods to involve them in the design process. Conversations started to go like this:
How did the stakeholder session with Patricia go?
Patricia asked us to make it blue, so we worked out some interview questions to use in our next client advisory panel to see what they think.
In many cases, make it blue requests were validated with research, and stakeholders accepted the resulting direction—all while feeling connected to the project and its success. It was much easier as a design team to accept those circumstances because we hadn’t forcefully objected. Instead, we could say, “That’s an interesting hypothesis. Let’s test it by doing X.”
Being in a leadership position is both powerful and challenging. Leaders are most successful when they wield trust over power and delegate that trust to others. But trust is a two-way street. Design teams need to ensure leaders that they’ve been heard and that their concerns are being investigated. True collaboration with high-up leaders is all about how you position that relationship.
I stopped saying “make it blue” years ago, but I often think about it. The difference is that these days, there’s often a little voice in my head asking, “am I just telling them to make it blue?” I’m lucky enough to work with folks who know how to test my hypotheses.
Remember that good consulting skills lead to stronger teams
Today, our teams proactively collect hypotheses from stakeholders and investigate them using research methods such as in-depth interviews, analytics reviews, comparative analysis, heuristic reviews, design validation, and more. Starting a conversation with a powerful stakeholder with questions like, “what types of hypotheses do you have about the product?” and “where do you think is the best place we can test that hypothesis?” is a consultative approach that gathers those opinions in a productive manner, taps into leaders’ vast expertise, and develops allies for your work.
