This should be a great book, it’s a really difficult problem sometimes sharing design work and getting criticism or feedback and often people who are not designers want to contribute and say how the design should be without a good eye for design, especially when the work is half done or still in progress it’s hard to see the vision sometimes.
If you’ve ever had the experience of a stakeholder insisting on a change that you disagreed with, this book is for you. It’s a common situation for designers to feel as if their own expertise and judgment is overruled by stakeholders who know little about design.
Happens all the time.
The author suggests, the person who can most effectively articulate design decisions is the person who usually wins. The difference between a good and a great designer is the ability to articulate how their solution solves the problem in a compelling way and gets stakeholder support.
Well then obviously I’m only a good designer not a great one lol, or I have only had the pleasure of working with very stubborn stakeholders.
Design is difficult to talk about because it’s subjective… what could be nice to one person could be unappealing to another.
When we disagree, we tend to become defensive. When we become defensive, we fail to focus on the real issues. The meeting ends, not with collaboration, but with grumbling compromise and, often, a crippled user experience. […] The thing we came together to accomplish has been muddied by groupthink and mob mentality.
So common.
You might spend weeks or months building the best possible app. Your team has poured in all the best practices. You’ve done usability testing to prove it works. And yet, one executive can come in and blow up the whole thing. We want to avoid this.
So true, and it happens all the time. So what does the author suggest to create better outcomes? Solving or removing miscommunication. I think in some way this is what makes startups better, when you have a small dedicated team and each person has their own roles and responsibilities, and it’s easier to give feedback to your small team. In larger organisations, there would be more politics and people involved.
It might seem like the best ideas should always win, or that great design should speak for itself, but that’s not how these situations play out in real life. […] Your design might be revolutionary, but an aggressive and well-spoken salesperson is more likely to get support if they can convince your boss that they’re right.
It’s so refreshing to see other designers have these exact same problems.
The keys to a successful design are:
- It solves a problem.
- It’s easy for users.
- It’s supported by everyone.
If you have a clear problem you are trying to solve, metrics or KPIs that can be measured… then you can remove subjectivity from the process and show that the design is better by measuring it. Without a problem it is all just a matter of opinions. The rest of the book is about gaining support from everyone else. Support is the key word rather than approval because all you need is an agreement to move forward, not consensus.
Design Thinking also starts by understanding the problem first, and then clearly defining it and creating the design once everyone agrees on the problem.
The single best thing you can do is establish a rapport and earn trust with the stakeholders. Create shared experiences and find common ground, get to know their viewpoint.
When planning meetings, try to reduce cognitive load. The more clutter or roadblocks you put in front of the team, the more difficult it is to complete the task. It’s important to set the context in the meeting:
- State the goal: remind them what the previously agreed-upon goal for the project was
- Summarize the last meeting
- Show a timeline: show the progress
- Specify the feedback you need: what type of feedback will be helpful at this stage.
- State the goal, again.
You can often predict feedback, so prepare alternatives in case… but don’t show the alternatives unless it is necessary. If a director asks you for something in a previous meeting and you haven’t made the change, you need to be able to show the designs you tried that didn’t work, so you can justify the changes. The same goes for prepared data and research, it’s not necessary to show but you must have it available to support your decisions.
If you are doing a big important meeting, gather and prepare the team beforehand to align yourselves on the objectives and expectations of the meeting.
During the meetings, your job is to listen and listen carefully.
- You must give them a chance to make themselves clear.
- It gives them confidence that they were understood.
- It demonstrates that you value what they have to say.
You can also repeat and rephrase the outline of the talking points to confirm you listened and understood correctly. Also listen to what isn’t being said directly, you often need to uncover the real problem and read between the lines.
Keep notes and always document why something changed, and why the decision was made. This will help you manage future conversations.
Sidenote: another good strategy I have learned is to remind the stakeholder that you are not fighting against each other to decide what the design should look like. Rather you are working together to do what is best for the website, and from the perspective of the website (or app) what is best for it… rather than framing the conversation as what I think is best vs. what the stakeholder thinks is best.
The author says it’s best to understand your role at this point. You might think the design meetings are simply a point where you receive feedback and criticism, to defend yourself and the decisions you have made on the project. Rather, your goal is to facilitate and guide the conversation to a positive place and be a champion for great design. We are there to lead a discussion on solutions, listen to feedback and turn it into something more useful.
We need to try our best to aim for the best outcomes, but let go of control over the final outcome. If your stakeholders have their own managers and stakeholders to present your work to and get higher level feedback, you need to prepare them to be able to also understand the goals and communicate the reasoning behind the designs.
Our expertise in design suggests that we should be recommending the best solutions. We do want our stakeholders to trust that we know what we’re talking about. Our expertise and recommendations are to be taken seriously. At the same time, we can’t believe that our ideas are the only way. There’s a delicate balance between believing that we have the best ideas and recognizing that they aren’t the only ideas. The challenge is to make solid recommendations while also taking seriously the suggestions and ideas of other people. This is difficult to do.
We need to stop our ego from getting in the way and see the value in other people’s ideas or perspectives. When you are asked to do something you don’t agree with then lead with a “yes” first and then address the problems:
Yes, we can do “x” and that would be a great change, … we would need to postpone “y” or change “z”. Do you agree?
That kind of positive leading response invites more conversation, and suggests you want to work together to achieve the same goals but the issues need to be resolved first.
It is also a common problem for people to offer ideas without any responsibility. You can invite them to be part of the solution:
Yes, you’re right about “x” and we need to fix that. If you’re willing to help me oversee that part of the project and provide feedback, I think we can arrange our priorities to make it happen.
You are still being positive but showing that their changes impact other parts of work, or impact your team’s work. You can also lead with a “yes” without committing to anything:
- Yes, that’s a very good point.
- Yes, thank you for sharing your perspective.
- Yes, I agree we need to find a way to improve this.
- etc.
Just don’t say anything like “Yes, but…” that is just another way of saying no.
The author suggests that for responding to stakeholders you could use one of these five tactics:
- Show a comparison: show the changes side-by-side with the current version, to provide a visual reference that leaves no question about which approach is best
- Propose an alternative: listen to the stakeholder’s suggestions and add value to it
- Give them a choice: show what will be lost by following a particular path
- Ask others to weigh in: see if other stakeholders can support you
- Postpone the decision: wait and contemplate rather than make hasty bad decisions that affect users down the line
It is also helpful to connect your response to a business goal, and how it might achieve that goal. You can use data-driven insights to justify certain choices, or feedback from testing. You can also highlight the limitations with certain approaches, like not having enough resources, or being limited by technology.
One formula for responding to stakeholders is the IDEAL response:
- IDENTIFY the problem
- DESCRIBE the solution
- EMPATHIZE with the user
- APPEAL to the business
- LOCK in agreement
It is also important to be direct, and highlight the benefits or risks.
After the meeting, send a follow-up to the entire team, while it’s still fresh in everyone’s minds, and it creates a written record. This also shows the meeting was a priority to you. Following up after the meeting also demonstrates that you listened to everyone’s feedback, and are taking it seriously. It also gets everyone on the same page about what the outcome was so there is no confusion going forward, while giving everyone an option to reply if they disagree or have additional insights.
After meetings have concluded, that’s also a good time to interact with people you might not have contact with regularly, and have one-on-ones with them where they might be able to share more privately.
I want to be honest and say that sometimes no matter how much we try, we will still need to make changes to our designs that we disagree with. It could be that the people we work with are not willing to budge on their opinions despite our expert suggestions.
It happens quite often unfortunately.
Sidenote: If a manager’s job is to manage things, they will force changes even if they’re totally unnecessary, just because that is their job to do. There was a programmer who would add a “yellow duck” to his projects, which the managers would say needs to be removed. This would give the managers something to be proud of that they did their job and made things better, while also leaving the rest of the project alone because actually it was fine. Sometimes the stakeholders just need something to remove to please themselves. If there are no changes, then there was no point in having the meeting. So next time, think about adding a bright yellow duck to the design.
Nice, the author mentioned the duck later on in the chapter. Apparently the artists at Disney would also do this on their character animations, and despised the painstaking process of redrawing their animations when the managers wanted to make changes, so they would make the arms hairy on characters they didn’t want to draw, and the art directors would reject those new characters. The artists would get what they wanted by using a purposeful distraction.
Another thing to consider, is that stakeholders will give you feedback that is incorrect but it still highlights which parts of your design need to be improved or re-examined. As the stakeholder doesn’t understand the intricacies of design, their feedback might be in the correct area but not communicated correctly.
When you are wrong, there is a potential for trust to be broken. You can own up if you make a mistake, and build more trust by admitting you made a mistake. Transparency is better than a cover-up.
You will know you are wrong when:
- The problem still exists
- Users don’t get it
- You don’t have support
The next important thing to do is manage expectations, of you, of the project, of the outcomes.
The last chapter focuses on how executives could better communicate with designers.
It’s a great book and wonderful to realise that these problems are universal and something everyone in the field deals with, with some nice recommendations on how to handle these kind of situations.