Mistakes When Presenting Designs | Pt. 1: Goals & Speaking Up

5 min readJan 23, 2019

2018 came to an end, and so has my first year and a half working as a product designer at Goodpatch, Tokyo. Of course, a goal upon joining was to improve the quality of my design output. However, the biggest reality I experienced in a client facing job was that design doesn’t speak for itself; how you present a design is just as important as how good the design is.

This is a reflection on fundamental lessons I’ve learned from weekly client meetings throughout my first year and a half here. These foundations helped our team make the most out our clients’ time and our own, and therefore respect our clients as important partners and ourselves as professionals.

Our work is primarily in a Japanese context, but I believe these basics apply to anyone who presents designs to clients, stakeholders, or teammates.

1. Don’t: Go into a meeting without an agenda

This is an obvious one, but the most important. It could be to make a certain decision, ask certain questions, or to propose a certain solution based on insights from research. Either way, stating the agenda or not can make the difference between a progress report with no direction, and an effective discussion with purpose.

Going into a meeting without stating its purpose can steer it off course into topics better discussed at a different time, or direct too much time to lower priority issues. It is often effective to state what topics of the design you’ll focus on now, and what topics are part of a future meeting. This redirects attention appropriately, and reassures the audience that their concerns are addressed.

Do: Know why you’re going to meet, and have an agenda.

2. Don’t: Rely on someone else to present your design

I’m far from confident in front of an audience, and feel much more at ease staying behind the scenes. However, I realized how important it is to step outside my comfort zone in my job, because the person who should present a design is the person who best understands it. And that person is the one who created it.

Presenting your own work also narrows the gap between you, the client, and engineers. It opens the door to discussion. It’s easier to come to an agreement for both sides to ask clarifying questions to each other than to ask through an intermediary (and waiting for responses). Speaking directly to one another also reduces the risk of information getting misinterpreted from hearing things secondhand.

Talking in front of an audience is can be a challenge, and worse if you are presenting in your non-native tongue. These are the largest hurdles I personally faced and am still working to overcome, but the only way is to keep practicing. One way to practice is to sell your design to the people around you. For example, I’ll often first write out my thoughts, then explain to my team, then to other coworkers. I get practice and also receive questions along the way that I can use to better support my design.

I recommend Tom Greever’s book, Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience, for tips on design-specific business communication, and a wealth of example sentences.

There is also a Japanese translation, for anyone interested.

Do: Take responsibility for your designs. Be the main person to present them, and be the first to respond to questions. Your team can back you up after.

3. Don’t: Talk about features

Features are solutions, and solutions make more sense in context. So save the feature talk for after you’ve established the context of your design.

Here are two examples of how we could introduce a design update to a client. (Design decisions include several factors and are complicated in real life, but this made up situation is an extremely simplified example.)

We added labels to the icons on the checkout page and made the text bigger in the confirmation message.

The goal was to design an effortless checkout process.
However, a problem we ran into in our tests was that most users failed to complete their orders. We discovered that users hesitated at this page because they didn’t know what these icons meant, and didn’t notice the confirmation message.
In order to achieve our goal of designing an effortless checkout process, we added labels to the icons, and increased the size and weight of the text of the confirmation message.
After these changes, we held another test in which the majority of users successfully completed their orders.

The first example only describes the solution without context, and thus invites subjective feedback such as “the labels kind of get in the way,” “the text looks kind of big,” or “I liked the previous design.”

The second example introduces the goal, problem, and reason before mentioning the solution, and then ties the solution back to the goal by supporting it with quantitative results.

The second is easier than the first for your audience to understand your thinking process. Providing context and reason before solutions invites your audience to ideally support your decision, or to provide helpful, objective feedback for alternative solutions.

Do: Start with the context (goal), then talk about solutions (features) that achieve the goal

4. Don’t: Forget the reason for each design decision

While it’s not necessary to dive deep into every single design element with a narrative like the above, clients will want to know why that special button is the way it is, and engineers will want to know why they should build it that way that too. It’s best practice as a designer to be intentional with each design decision, and being able to articulate the reason each one, no matter how minor, is a great tool to have when working with clients and engineers.

Sometimes stakeholders challenge decisions, but sometimes they are just genuinely curious about the thought process behind it. So communicating your intentions will help build trust and camaraderie with your team and client. Conveying the data and research behind your designs also improves your trustworthiness.