Review: Articulating Design Decisions by Tom Greever

The book offers guidelines, strategies, and practical techniques for presenting designs to executives, developers, stakeholders— non-designers in order to gain their support for best user experience.

The Review Premise

Some say that the trick to describing the contents of a book in a decent review is to tell the reader just enough, but not too much.

In terms of this book I respectfully disagree.

Contents of Tom Greever’s “Articulating Design Decisions” isn’t anything extraordinary, nor magic, yet a compilation of well-know facts and truths. At the same time, it must be admitted that the author’s work, although it could be more clearly articulated on much less pages — pun intended — is practical and sufficiently insightful.

Having above in mind, I’ve decided that this review will be different.

The goal is to present all relevant conclusions and findings into tightly-packed design treats 🧁, quickly to consume 🥄 and easy to digest 😋.

I value your time, which is why, each chapter’s synopsis will be divided into two parts:

• 👨‍🍳️ Key thoughts I want to put forth
• 👨‍🍳 Short summary

At the end, for dessert 🍒 I’ll put together a:

• 👨‍🍳 A refined collection of insightful quotes from the book

Let the grand cookout begin.

An S saying ‘hi’ to a T. A perfect example on how articulation is affecting cooperation with stakeholders.

Chapter 1: Great Designers are Great Communicators

Key thoughts I want to put forth:

1. ⭐️ Level of designer’s presentation skills is directly proportional to chance of a buy-in and getting support.
2. ⭐️ A good design presentation is compelling and/or memorable.
3. ⭐️ The ability to persuade others is inseparable linked to the level of trust you have earned.
4. ⭐️ Understanding your actions, having faith in your expertise, and respecting your judgments, constitute a real trust.
5. ⭐️ ️️Ultimately, being able to concisely articulate any design is more important, than being able to consistently craft perfect designs.
6. ⭐️ ️️Design presentation, has to consider the audience — beautifully crafted words will fall on deaf ears if they are not considering one’s thoughts, ideas, objectives, position in the project.
7. ⭐️ All design is subjective — meaning that opinions can easily be attached to it.
8. ⭐️ Learn how to cope with executives, developers, stakeholders — non-designers, that eagerly admit, that they don’t know much about design, yet will boldly request changes of the UX and UI based on — while once again honestly admitting — that they are not sure, but they have a feeling it might work.
9. ⭐️ Only when collaboration is properly led and directed, will it result in highly valuable outcomes.
10. ⭐️ Being articulate means conducting a responsible messaging — forming a message, as well as predicting, influencing and finally yielding responses you wanted in return exactly how you planned in the beginning.
11. ⭐ Save alternatives to your design, even if you have only cognitively/mentally analyzed and discarded them; you never know when a discussion may start.
12. ⭐️ Successful design: (a) solves the problem, (b) is easy for users, (c) gets support from everyone. I’ll extend this list with two additional points: (d) handles foreseeable development issues, (e) has happily passed a reality check.

Short summary:

In it’s essence, this chapter is trying to capture what makes a good, great and turbo designer in terms of design articulation core abilities. It strips down most valuable characteristics and associates them with specific behaviours, actions, mindsets as well as do’s and don’t.

I’d argue, that it’s the most important chapter. If you don’t have time for the entire book, just read this section. I’m confident you’ll learn 50% of what the whole book has to teach you.

Chapter 2: Stakeholders are people too

Key thoughts I want to put forth:

1. ⭐️ Remember that stakeholders hold the keys to your success.
2. ⭐️ Learn to speak the language of the stakeholders — shared vocabulary gets people closer together, and may indicate unity of thought.
3. ⭐️ Your design game should consider stakeholders success, since your success is the byproduct of theirs.
4. ⭐ Brace yourself for the possibility, that stakeholder’s opinion on design might be caused by situational factors, that might truly unpredictable nor be ever visible to you.
5. ⭐️ When working with Executives outline both quick wins and big picture — they tend to have high-level, 360° overview of everything going on, and showing them just a tiny yet crucial detail, might not cater for their needs at all.
6. ⭐️ When working with Developers show value in everything you’ve done, so they won’t be concerned with ‘overdesigned’ parts that are not worth their time and effort — be their ally: (1) minimize possibility of rework on their part, (2) reuse patterns, (3) justify the need of their extra effort, (4) take care of edge cases, and think in code when designing.
7. ⭐️ When working with Product Owners focus on ways of reaching business needs and making the future products the best version of itself — basically become advocate for their roadmap and final outcome.
8. ⭐️ When working with Project Managers or Ops inform, report, keep the deadline and schedule — they will love you for that.

Short summary:

Second chapter seems to be unnecessary stretched, though it’s insightful in couple of paragraphs.

Puts a lot of emphasis on building relationships with stakeholders and describes ways of achieving that. Lastly, categorizes stakeholders and assigns to them certain behaviours, objectives and mindsets.

If you don’t have enough time for entire book, you can read the ‘Key Thoughts’ I’ve crafted above, and entirely omit this one.

Chapter 3: Design the Meeting

Key thoughts I want to put forth:

1. ⭐️ Approach refining ways of holding design meetings, like you’d refine your design.
2. ⭐️ Reduce cognitive load for the audience and for yourself — make presentation clear, digestible and divided into easy to consume chunks.
3. ⭐️ Remove distractions, especially adjusting presentation material to the audiences preference (like not using lorem ipsum or legacy UI or using hand-picked image rather the meaningless placeholders). Yet, balance out the extra time and effort vs. desired outcome.
4. ⭐️ Gather backers of your case — having a support network during a meeting creates an atmosphere of consensus.
5. ⭐️ Test your presentation by rehearsing — meaning saying things out load in order to check your articulation, as well as printing words into your mind, so may swiftly recall them when needed.
6. ⭐️ Verify your design articulation with your peers — what you might miss, the other set of eyes might catch on the first glimpse.
7. ⭐ ️When preparing a presentation try to include these parts: (1) Stating the goal, (2) Summarizing last meeting, (3) Showing timeline, (4) Specifying type and contents of the feedback you need, (5) Stating the goal at the end… again.

Short summary:

Third chapter is basically list of things you should do before and during a meeting, as well as list of techniques useful for preparing the presentation itself in order to be as articulate and impactful as possible.

Chapter can be summarized in one sentence: Understand you audience, remove unnecessary distractions, anticipate audience reactions, gather people, that will back up your solutions, rehearse, do a peers check, go for the win.

Chapter 4: Listen to understand

Key thoughts I want to put forth:

1. ⭐ Listen without interrupting, meaning not hearing the exact words, but tuning into the actual problem, then pausing before moving on.
2. ⭐ Try to tune into into stakeholders vocabulary and mimic it, while letting them talk freely. Correct them only if it actually brings value.
3. ⭐ If a stakeholder says “interesting” in regards to your design, it means he/she do not agree with the approach you took.
4. ⭐ Most people tend to see solutions first, rather than identify the problem —like here: “please move the button a bit to the top”. If you hear this kind of narrative, stir the conversation towards the identification of the problem — like this: “What kind of problem you are trying to solve by suggesting this?”
5. ⭐ Taking notes structures the meeting. Notes should be (a) accessible, (b) organized, (c) specific, (d) definitive, (e) actionable, (f) referenced, (g) forward-thinking. Include the thinking behind the whys in your notes, to be one step ahead.
6. ⭐ Good questions pull out words from stakeholders, that might not have said on their own, like:
   — - What problem are you trying to solve?
   — - What are the advantages of doing it this way?
   — - What do you suggest?
   — - How will this affect our goals?
   — - Where have you seen this before?
7. ⭐ While explaining anything, rephrase your and stakeholders’ thoughts on and on. This way you’ll minimize confusion or misunderstanding what kind of message you and they want to convey.

Short summary:

Forth Chapter is basically scratching the surface on how to employ effective listening in your work.

I think every time you talk to anyone about anything (with you family, friends and strangers on the street), you should do it the way described in this chapter. It seems just common sense to me.

Summarizing: (a) don’t interrupt, (b) try to match stakeholders’ vocabulary to reasonable extent, (c) help to identify the problem, (d) take meaningful notes, (e) ask questions aimed at understanding the rationale of stakeholders’ remarks, (f) rephrase your thoughts and repeat and rephrase stakeholders’ words in order to be on the same page.

Chapter 5: Get in the Right Mindset

Key thoughts I want to put forth:

1. ⭐ Understand your role in the conversation about design.
2. ⭐ You are not a salesman (so don’t push the sales), you are not at war (so don’t defend at all cost), it is not a competition (there are no winners or losers)
3. ⭐ You have to come to terms with the fact, that you do not have the ultimate control over the design’s final outcome.
4. ⭐ Stakeholder often represent you work once a meeting with a designer is over. Equip them in everything they need in order to confidently present your work to other people.
5. ⭐ Check your ego at the door. It is not you but the specs, that you need to fully embrace and even go beyond expectations, while making a path for something better than you alone could have mustered.
6. ⭐ Employ the “yes” tactic. People are more motivated, empowered and passionate, when their ideas are given permission to succeed, and they hear: “yes”.
   I partially disagree here, since almost always what you hear is: “yes, but”. Hence the key is to say: “yes, and”. Try it yourself and see the difference in peoples reactions.
7. ⭐ Be positive, but not euphoric; be confident, but not arrogant; be knowledgeable, but not know-it-all; be relaxed but not nonchalant; be authentic.
   Author also mentions a need to smile. But i have to disagree on this one, since this works in the West. A smile in different cultures means different things, and you should be aware of that. So rather smiling like a joker, act appropriately to the environment you are in.
8. ⭐ Employ “thank, repeat, prepare” tactic.
   I have to disagree once again, on this one. People are perfectly aware your politeness is superficial, and even if it won’t be, they’ll think that way anyways. When I read this part, I felt author plays down intelligence factor that is involved when working with professionals. People know what you are up to, and it makes more sense to be authentic and polite just to employ a tactic for a meeting.
   In other words, people are smarter then he thinks, and can easily see through this kind of actions, which can rather hinder the relationship with than be beneficial in any way. Nonetheless, you should always be nice to people, even they are rude to you.

Short summary:

Fifth chapter seems to drag on a little bit, especially at the end, repeating what was mentioned in previous chapters. Though in couple of paragraphs you will find stuff you might consider insightful.

Chapter focuses mostly on putting yourself, as a designer, in the right place within the conversation and the ‘pecking order’, and keeping open-minded, authentic attitude towards stakeholders and their feedback.

If you don’t have enough time for entire book, you can read the ‘Key Thoughts’ I’ve crafted above, and omit this one, especially last 6 pages of this chapter.

Chapter 6: Form a Response

Key thoughts I want to put forth:

1. ⭐ While responding to feedback you should try to employ following tactics: (a) appealing to a nobler motive — attaching design decision to a goal , data or metric; (b) backlogging ideas that are about to derail a meeting — laser-focusing on the problem, and keeping the additional topic for future discussions; (c) represent the user — focusing on how design will affect the user; (d) demonstrate effectiveness —articulating or demonstrating why this design is better than the alternative.
2. ⭐ Actions to take while drafting a response to a stakeholder: (a) showing comparison — putting alternating designs side by side; (b) proposing an alternative design; (c) giving stakeholders a choice — an attempt to make stakeholders aware of the implications, tradeoffs and/or costs of their choices; (d) asking others to weigh in —including an ally into conversation, so more than one person backs up your solution with their perspective; (e) postponing the decision — not making hasty decisions, giving yourself time to look at the design from different angle.

Short summary:

Sixth chapter is packed with tactics and actions around facing the stakeholders questions and feedback. All written in clear and concise manner.

Brief in form but comprehensive in scope, definitely worth reading in its entirety.

Chapter 7: Choose a Message

Key thoughts I want to put forth:

1. ⭐ Types of messages conveying the value of a design solution: (a) contribution to business goals, (b) contribution to usability and good user experience, (c) branding consistency.
2. ⭐ Types of rationalia behind design decisions: (a) exploiting a common design pattern or a standard in the industry, (b) drawing user’s attention, (c) pointing out logic of the user’s flow, (d) validating design through relevant data and testing results, (e) supported by research results and conclusions, (f) constrained by technology itself or teams tech stack.

Short summary:

Seventh chapter is somehow repetitive in itself, and way to general to appeal to anyone else but complete rookies to design. I’d expect more from this chapter, such as more insight into inner-workings of people’s (stakeholders’) minds and common behaviours to take advantage of, or less common patterns, less obvious tactics you could employ while working with stakeholders.

Chapter 8: Lock in Agreement

Key thoughts I want to put forth:

1. ⭐ It’s important to seek agreements with or confirmations from stakeholders regarding all important parts of design. This should solidify and speed up the design process.

Short summary:

Eighth chapter is basically a closing summary of chapters 6 and 7. And to be honest, not bringing much to the table. It does however contain an extensive table of example messages used in very specific situations. Yet, I’d argue that without additional context and/or background behind each case, this ‘dataset’ is somehow unusable in building/ polishing your design articulation arsenal.

My hunch is that, chapters 6, 7 and 8, were one chapter that got divided and elaborated on a bit more, so each could ‘stand’ on its own. I’d argue that this editorial decision was unfortunate or being more honest, upright bad.

Part of the content is repetitive or drags on with not much substance you can consider valuable. The number of key thoughts listed above should speak for itself.

Chapter 9: Follow up Afterward

Key thoughts I want to put forth:

1. ⭐ In order to reinforce your presentation stick after the meeting and talk to people to debrief and gain insight that didn’t had a chance to be shared during the meeting.
2. ⭐ Follow up with meeting participants and other relevant people right after the meeting while it’s still fresh on everyone’s mind, including yours. It shows you are up for task, and you’re driven to finalize it to your best abilities, as well as all people involved and their insight/feedback is valued. It should be cordial, summing up all arguments, actionable for you and others (including people who do not report to you).
3. ⭐ Before sending the follow up email/memo, go through it once again and declutter it from all irrelevant or unimportant information that will only add noise to the true message you wanted to share. Remember you are the navigator of this process, and if in your opinion some ideas were through into the discussion without any intention to carry them out. World is full of unrealistic ideas virtually impossible to pull of and irresponsible feedback that doesn’t bring anything to the table ut noise. Omit them completely, it’s your judgement call.
4. ⭐ A common situation is that after a meeting nothing seems to be the right course of action. In such circumstances, sometimes best is to do anything even when it’s wrong.
   There is theory proposed by Jon Bell — where people standing around trying to decide where to go to eat, often will become overtaken by their politeness and not wanting to impose their will over others won’t have any suggestions or will stand there in complete silence. This is the moment you should propose McDonalds. When people hear a bad idea, they will have an opinion stronger then you might think. So say ‘Micky D’ and it will open magical doors of Narnia full of best places to eat out.
   If met with indecision or ambiguity, take the lead and make the decision on your own.

Short summary:

Ninth chapter emphasise the fact that, the time immediately after a meeting is nearly as important as the meeting itself. It’s a guide on how to follow-up, filter out irrelevant stuff, take one-on-ones with influential people right after the meeting, and make a judgment calls on what to do, if there is no perfect course of action deriving from the meeting.

Totally worth reading. I’d love if all the chapters were equally digestible and rich in useful insight.

Chapter 10: Dealing with Changes

Key thoughts I want to put forth:

1. ⭐ It’s important to understand that asking for feedback often results in urgency in feedback providers to give it at all cost. What is the objective of the ‘Design Review’ meeting other than proposing changes to the design, right?
2. ⭐ To cope with this phenomenon you can try to employ few tactics: (a) Bikeshedding or Law of Triviality — argument that people within an organization commonly give disproportionate weight to trivial issues, like choosing material for bike shed placed within the premises of the nuclear plant construction; (b) Atwood’s Duck — a cunning ploy to let busybody micromanagers feel like they did something. Give them something obvious (an obnoxious duck) to criticize and remove from your work.
3. ⭐ The fact that a stakeholder won’t budge and despite all arguments will push for his/her idea that is upright bad, it doesn’t necessarily mean you should implement an awful idea ‘word-for-word’. Your role is to squeeze as much from bad ideas as from good ones. Once you let yourself approach it that way you might actually muster a better design you have initially envisioned. You just never know, what will be the spark for great design solution, so don’t lose any opportunity, no matter how gruesome it might look at first.
4. ⭐ Choose battle you want to fight, meaning not to over-invest in discussions that won’t be fruitful, no matter what you’ll do, or looking for an argument for a person that won’t budge no matter what. Your sanity and integrity are important, so choose your battle wisely.
5. ⭐ Do anything in you power to make stakeholders to shift from a position of assuming that your choices are questionable, to assuming they have purpose. Own up to your decisions and admit you were wrong. This will build trust and rapport not hindering the shift I mentioned above.
6. ⭐ Your ability to properly set, adjust and effectively communicate expectations, is often more important then you ability to create the perfect design.

Short summary:

Tenth chapter is the most insightful chapter from all of them. Bikeshedding and Atwood’s Duck are few of many examples of great writing and giving valuable observations and knowledge. Is also packed with truths that are not that obvious, and knowing them is beneficial in designer’s daily work, such as coping with people who won’t budge, choosing your battles and setting and handling expectations.

Definitely worth reading and exploiting in the future design endeavours.

Chapter 11: How executives can help designers

Short summary:

Eleventh and last chapter is directed to stakeholders. It weighs in on four universal truths related to designers — stakeholders should:

(a) Realise that designers are skilled and knowledgeable individuals that know what they are doing;
(b) Cater for designers’ needs, so they can amaze you with the outcomes of their work;
(c) Empower the team to streamline design solutions;
(d) Remember that designer are people, too.

Then there is (1) a list of tips for working with designers, (2) design project checklist, that might be useful.

Summary

“Articulating Design Decisions” by Tom Greever is a good read. Greever’s writing is clean and lean. The meat of this book is mainly focused on fundaments revolving around communication and design review meetings, sometimes missing chances where it could have gone deeper on the subject. It’s a must-read for a rookie designer who just start his design endeavours. For seasoned designer its narrative may seem a bit obvious, and not at all filled with stimulating insight.

Nonetheless shear amount of great quotes listed below, as well as, first-class chapters 9 and 10, should make you want to read the whole book on your own. If have 10 years of experience and you know it all, it’s still good idea to refresh your memory, maybe you’ll fish out something from the book that will work for you.

If you want to dive deeper…

Here is an article on design feedback, that is directly connected to the topics covered by the book. It’s a 10-minute coast-to-coast manual for giving and receiving feedback from stakeholders. Go check it out here:

Design Feedback: How to give great design feedback, and how to receive it

Insightful Quote Collection

About teamwork:

The image is of a handful of respectful intellectuals, passionately debating the right solutions, ultimately leading to a collaborative discussion and an ideal design that no one could have thought of on their own.

About responsible messaging:

The key to being articulate is to understand both the message you want to communicate as well as the response you want in return.

About building trust:

You need to create an environment where everyone understands what you are doing, believes in your expertise, and supports your choice, so you can move on to the next thing.

About articulation ability:

Your ability (…) [to] articulate any solution is more important than ability to design perfect solution every time.

About understanding stakeholder’s perception:

(…) see the world through the eyes of the people who have influence over our project.

About success:

(…) learn how to make stakeholders successful, because if we can help them be successful, that will help us be successful as a byproduct.

About designers:

[Designers] are more then just pixel pushers.

About stakeholder decision-making (this come directly from me, but I felt it will fit perfectly here):

Behind every decision, there is always an Excel spreadsheet.

About stakeholders attachment to meaningless matters:

To often, people obsess over things that don’t really matter.

About presentation rehearsal:

Practicing for a meeting is the usability test of being articulate

About listening:

(…) important part of listening is hearing what isn’t being said.

About listening:

People naturally think in terms of solutions rather then first identifying the problem.

About vocabulary:

(…) strike the word “like” from your vocabulary (…).

About designer’s ego:

(…) check your ego at the door.

About positive approach:

Innovation happens in places where “no” is seldom heard (…).
D., J. Ferguson, Eric Bramlett, The Big Idea, 2007, p. 180.

About follow-up:

The time immediately after a meeting is nearly as important as the meeting itself (…).

About bad ideas:

One’s persons suggestion is a gold mine of other ideas waiting to be excavated.