Rules of (stakeholder) engagement for designers
During my work, one skill that I think any designers could benefit from, is stakeholder management. Alternatively, as my colleague Guy suggested, stakeholder engagement is a more appropriate term, this is a term that I will use in this article.
Why engagement, rather than management? To me, engagement puts the power into the designer’s hands, allowing us to proactively turn the design into a well-informed, collaborative process that enable better outcomes; while management feels a bit like something we have to do to avoid our work being derailed, not to mention our senior stakeholders probably prefer to be “engaged” rather than “managed”.
Fundamentally, effective stakeholder engagement isn’t far away from the design work we do day to day — know who they are, understanding their needs and what success means to them, a.k.a what makes them look good.
By engaging your stakeholders and establish shared understanding of both your needs and what’s important, you, as a designer, shows up as someone who cares about all it takes to deliver the work. It can also help you to be adequately placed to influence your group or make strategic design decisions, as you have more visibility on what success looks like from different angles.
I’d like to share my learnings that has helped me in my work. While there’s no bullet-proof way to ensure that our design is a success, by applying these, it has helped me build better working relationships with my colleagues, and to achieve more amicable outcomes.
Get to know them
In one of my roles, during my first week my manager gave me a task. To this day, this is a task I still do for the first week — my first week in a new role, a new team, it’s also something I’d suggest to new starters in my team and my mentees to do in their first week.
For this task, my manager gave me a list of colleagues to reach out to and learn about their work.
I dutifully emailed them and set up 1 on 1s with them. During these sessions we got to know each other, I found out more about what they do, and they shared helpful information with me as I’m new.
The knowledge and the relationship I’ve built helped me in several ways
- I learnt more about the moving parts within my wider team as well as the organisation, so that
- I know who I can reach out to when I have a question, or that person will know someone who can help.
- As I moved between projects, sometimes the colleagues I work with in a new project would be people I have already established rapport with. Consequently making building a working relationship sooner.
If it happens to be your first week, once you found out the coffee recommendations, don’t be shy to ask your manager and colleagues about who you should reach out to, and try out these recommendations with them.
Bring them along the way
There was one project that I worked on, over time we pivoted, downscoped and eventually put on hold indefinitely.
In another, we proposed a design uplift that the product team had not considered. It was eventually accepted and the project went live in the end.
What was the difference between the two projects?
In the first one, on reflection, I learned that one possible cause was the senior executives were not aware of the progress. By the time we addressed that by setting up a working group to improve communication and accelerate collaboration, unfortunately it was all too late.
In the second one, as soon as we established the work to be done and how Design can add value to the deliverables. We identified a list of stakeholders we need to keep informed. Through many meetings we discussed scope of change, research to validate the designs, what degree of flexibility we have for design change given development would have to commence in parallel. Our stakeholders had been kept informed all through the research — from planning, research scope, periodic updates to final walkthrough of the results.
The important lesson I learnt was that, when we have an idea, it’s important to bring our team along the way. Particularly with our senior stakeholders, we need to make our intentions clear, make their expectations clear, and make our progress clear. Through constant conversation and feedback loop, Design and Product have shared understanding on what we want to achieve, why we want to do this, and how do we demonstrate value as we progress.
Amongst all your stakeholders, there will be some which would be critical that you bring them along the way, we’ll go through more in the next section.
Not all stakeholders are the same
One of tools that I learnt from stakeholder management training is stakeholder mapping. Often, we have many stakeholders to collaborate with, and that not all stakeholders are the same. But which ones really have the power to impact our project if we don’t engage them early and engage well? For these stakeholders, we need to keep them in close watch and make sure they’re well informed and most of all, satisfied with how the project is going.
A Mendelow’s Matrix (or Power-interest matrix) gives you an overview of your stakeholder and helps you manage your communication and focus on each of them.
According to the Oxford College of Marketing, the four quadrants in the matrix can be defined as below.
High power, highly interested people (Manage Closely): aim to fully engage these people, making the greatest efforts to satisfy them.
High power, less interested people (Keep Satisfied): put enough work in with these people to keep them satisfied, but not so much that they become bored with your message.
Low power, highly interested people (Keep Informed): adequately inform these people, and talk to them to ensure that no major issues are arising. These audiences can also help point out any areas that could be improved or have been overlooked.
Low power, less interested people (Monitor): don’t bore these stakeholder groups with excessive communication, keep an eye to check if their levels of interest or power change.
There are many variations of the matrix available online. You can set one up in tools such as Miro and share with your internal team to work out your communication plan, such as who to invite to showcases, whose approval is required, to whom a regular email update would suffice.
Don’t be afraid to (over)communicate
It’s always better to over-communicate than under-communicate.
It’ll never hurt to send them an email/a 15min call for quick updates — no trees were harmed in that process.
It’s up to you to explore the level of detail your communication is needed for your stakeholders. Do they need an in-depth walkthrough? A bi-weekly status update? Or they need to be invited to the sprint showcase? Generally, the ones that are closer to the work or from whom I sense there’s less confidence, I’d go with the in-depth walkthrough to address any concerns and get feedback early where possible. Other times, regular status update will suffice. Those who should stay informed but not close to the decision making, inviting them to showcase should do the trick.
Going through a slow patch? If it’s been a few weeks since anything happened. Send them an update anyway to let them know not much has happened, that way they know that the work hasn’t fallen off the radar, and both parties can sync up and address any questions and/or concerns.
Small agreements can lead to big agreement
Is there something you need agreement from a large group of people, or simply a big idea that you’ll need acceptance? What I found useful is to start with a number of conversations in smaller groups.
During these smaller sessions, not only you can communicate and get initial feedback, and work the feedback into something that could gain more agreement. Same goes with the big ideas, having small pre-conversations as a heads-up and getting feedback can prevent unwanted surprises and hard push-backs when presenting to the larger group, it may even open you up to stakeholders that you should consult that you may have previously missed.
Help! My stakeholders can’t agree!
Sometimes, as much as we’re on top of our communications and engagement. Disagreements can still happen. When the decision making comes to a gridlock, here are some ways I’ve used to facilitate an agreement.
Engage both parties — It’s important to understand the intent from both parties. What’s at stake for them if the design go in one direction, or the other? To them, what are the impacts depending on the design direction? Can we analyse and establish these potential implications early on?
At this stage you will also have been in collaboration with these teams, so that you’re clear that no key decisions was made in silos, and pinpoint where a miscommunication may have occurred.
Anchor the design direction — Is there something that all teams would want to achieve out of this, e.g. minimum customer impact, less tech debt, meeting certain deadlines. If there is something among the group, create shared clarity on it. With that we can work towards a common goal, or when opinions diverge, we have the key principles/direction to fall back on.
Define and agree on ownership — some examples
- What platforms and/or services does a particular experience spans across, and which team owns each of them?
- Which teams own certain groups of experiences, i.e. App, web, etc?
- Who owns the UI? Do we use a design system owned by the global design team.
Set intent based on that ownership — Once we agree on the ownership, it works a bit like delegating — each team agrees to lead certain parts, while accepting input from others. In a perfect world, each team that would have principles on what they want to achieve in the areas that they lead and are experts in.
Help facilitate information gathering for decision making — Not everything can be settled in the previous steps. Sometimes groups could feel strongly about something in different ways and we can’t settle. When that happens, we can help provide clarity by presenting information and data to drive decision making. Some ways to do that are
- Research — can we get some rough idea on what works by running user testing?
- Analytics — if time and resources allow, can we A/B test this? What data we can capture from the real world to help us make these decisions?
- Impact assessment — what can we learn from our experts, so that we can share with the group the impact based on decision made — if we do A, this will happen; or if we do B, that will happen. What are the impacts of these decision, and the risk implications?
Closing thoughts
With all this in place, I’m immensely grateful that many people I have worked with have been wonderful people, and together we solved many problems in agreement during my experience. I hope this could help you solve some of your stakeholder dilemmas. Please feel free to connect with me on Linkedin or Twitter.
