Articulating Design Decisions

I’m reading the book Articulating Design Decisions by Tom Greever and taking notes.

Chapter 1

Job interviews are an opportunity to practice talking about your job.
Communicate in the language of your stakeholder, not pixels.
What’s good design? Answer like ‘simplicity’ or ‘use of space’ confuse looks with usability. Don’t redesign without business needs or without solving problems.
Remove subjectivity from decisions by grounding them in research. Biased or inconclusive research makes it harder.
Dialog is sufficient for fine art critique. However, in business you need to make decisions.
The way designers talk among themselves is different from how they would talk with a stakeholder.
It’s hard to explain decisions based on intuition.
Digital products impact people’s lives, that’s why everyone has an opinion.

Chapter 2

Include stakeholders in the design process.
We don’t see the code written by developers. However, we see UI created by designers.
When we collaborate and disagree, we get defensive and fail to focus on real issues.
Words are powerful: they can start wars, or change people’s minds.
Good communicators win (ex. more job opportunities).
By being articulate you can enact change when you convince someone.
It’s not the best idea that wins – it’s the most convincing one.
Designers who lack ability to explain their decisions may be forced making changes they disagree with.
Articulate designer is perceived as a confident export who can be trusted with a solution.

Successful design solves problem, is easy for users and is supported by everyone.

1. Solve the problem and measure success

How will we know we’ve done our job? Opinions and subjectivity make it difficult to move forward. Pick one or two most important factors for stakeholders and measure before and after.

Practice awareness of your own decisions. This will help to explain your intuitive choices later:

list solutions for a problem
consider how you’d describe design over the phone

2. Make it easy

When making decisions ask yourself how does this affect the user. Validate your assumptions with user sessions.

3. Get support

Without support, the same discussions will keep repeating. If the explanation is not clear or strong enough, people will forget it. Those who are not convinced will keep suggesting other ideas, which will slow down the design work.

Consider alternatives others might suggest and why is the proposed solution better. Create simple wireframes of alternatives to have them ready to show.

Make it happen

What problem does it solve?
How does it affect user?
Why is it better than alternative?

Understand your own decisions by answering these questions, then articulate them to someone else in a way that makes sense to them.

Chapter 3

Build relationships with stakeholders, understand and engage with them on personal level to make communication easier.

Create shared experiences to talk about with them – go for a lunch, drinks after work, ask for advice, or mention things you noticed about them.

Understand their perspective, feel their pain that will drive you to action out of solidarity – a true empathy!

Show the vision of a final product to executives to build trust and get approval for MVP.

Take time to know a little about their life outside of work:

What did you do this weekend?
How was your holiday?
Have you seen any good movies?
So, what’s new?

Ask them about their kids or pets.

Reveal information about yourself and ask them about it. For example: “I went camping last weekend, do you like camping?”

Understand influencers on your project: team, executives and external.

Just as we write user stories we can write a stakeholder stories. For example: “As a product owner, I want ___ so that ___ .”

Chapter 4

Reduce cognitive load of stakeholders to focus on primary task, the goal is to make meeting productive and successful.

Remove distractions

Placeholder content such as lorem ipsum or poorly chosen images may distract stakeholders from focus on the design itself.
Align layers even if it’s just a simple wireframe.
Avoid color if it would be a distractions such as legacy brand color.

When preparing designs weigh the extra time needed to cleanup with the benefit of removed distractions. Usually, it’s worth it because non-designers obsess over things that don’t matter.

Anticipate reactions

Guess how they’ll respond based on what you know about them. People often obsess over the same things. It takes a few meeting to learn what.
Tune presentation to cover what will people care about the most, based on their personal goals for this design, their wants and things they don’t know.
Figure out why people are invited and make it relevant to them. You can guess based on their role or ask them directly – what do they hope to get out of it, how they see themselves contributing.

Write down objections

What are the possible objections, questions or opinions stakeholders might have? Write them down along with your responses. Just write down what you think people will say.

Create alternatives

Add alternatives you considered, with changes they proposed, or think will be suggested
Have an answer why is your design better than alternatives
Bring alternatives as evidence you’ve tried them
This creates a place to discuss merits of each option

Prepare data

Analytics and usability reports that support your proposal
Be ready to show the data if needed (in case of disagreement or if people react to designs with skepticism)
Data is powerful, using it all the time leads to an environment where people don’t want to suggest anything different

Create a support network

Get other people to support your decisions in the room. Stakeholders will see there are other smart people who agree with you and have more relational capital.

The ringer

Ringer = Person with prearranged answers or reactions (common on TV)
In meetings, have people who will ask good questions, point out specific elements, and support your designs.
They can jump in if you forget to cover something important.
They can ask prearranged questions and you can provide well-articulated answer.
It’s okay to ask people to be your ringer, to build the case other people agree with you.
Ask them to help, to speak up if situation calls for it.

Identifying people

Build relationships and leverage them, you can’t pull it of right before the meeting.
Your team is already onboard, ask them you’ll need backup.
Ask them to help you write justification for decision.
Seek other people with stake in the project who have influence.
Meet 1-on-1 and prepare them so they are confident to support you.

People get it

Have a small group of people support you in a meeting.
Opportunity for people to speak on your behalf.
You don’t need to express things on your own, other do it for you.
It’s difficult for stakeholder to disagree if everyone else does.

Dress rehearsal

Practice for each meeting: more for a big meeting, less for a small one.

Make a list

Design discussions tend to wander, so have agenda in front of you to keep it on track, and shared agenda for everyone else.
Have a simple list of things to review with people even for small meetings like a daily standup so you don’t forget.

Practice out loud

Practice what you’ll say, find wording that works for you.
Pace the room, talk to people who aren’t there as if it were the actual meeting.
Practice answering questions you anticipate.
Practice is a critical point to be articulate – you brain won’t have to think about what to say next, and you’ll have more capacity to focus on being articulate.
You’ll identify your own motivations, as you try to explain things.
The more important the meeting, the more preparation and practice it deserves.
Test your meeting in the same environment, run through everything to make sure it works as expected.

Prep everyone

Sync up with your support before the call so that everyone is on the same page.