How to articulate your design decisions

Recently I attended a workshop hosted by Tom Greever on articulating design decisions.

As a recent newcomer to field of product design, I’ve been feeling an absence of confidence amongst my peers. It’s been well told that a key skill of any designer is the ability to communicate.

At the surface this sounds easy — anyone can talk, but talking isn’t the challenge. The challenge is in communicating well.

How can you communicate in a way that convinces your stakeholder(s) that this is the problem to focus on? The meaning behind a particular decision? The goal you’re trying to achieve?

Tom opened the workshop with some food for thought:

Knowing the goal is critical, but keep in mind that the goal can change.

As I read this I thought back to all the times I’d been stubborn as I persisted towards a goal that was no longer relevant. Being flexible and adaptive to change wasn’t something I considered a necessary skill, yet alone a skill itself. However, this of course makes sense.

As we progress through the design process, new insights arise which can influence the goal or direction of the project.

It’s our responsibilities as designers to recognise these insights and encourage forward trajectory — not get hung up on a particular idea or goal that’s since been abandoned.

Defining designs’ purpose

We often hear that fundamentally, design has to solve a problem. But this isn’t the end. Tom pointed out that design has more work to do than just solve a problem. Design has to:

1. Solve a problem

What problem does this particular design solve? Always refer to the problem, goals and big picture. Be open towards taking on feedback and suggestions, but challenge others by asking them “What problem are you trying to solve by suggesting this?”

2. Be easy for users

How does this particular design affect the user? What barriers are we creating or minimising? What behaviour do we expect to see from our users and does our design encourage that?

3. Be supported by everyone

There will always be someone who will challenge your decision. Be prepared to explain why it’s better than the alternative and the other directions you explored. Why did you choose this direction?

This caused me to reflect on my own approach to design. I realised that I tend to swing between number one and two, occasionally touching briefly on number three. Rarely however do I consider all three of these simultaneously when making a design decision or mapping out a potential solution.

I took a mental note and scribbled these down in my notebook with the intention of embracing these more into my process.

Getting buy in

A big part of any designers job is to get buy-in, convincing others of our design can be key to success. Tom shared some techniques and strategies to encourage buy-in from stakeholders or peers on the team.

One suggestion in particular that I found interesting was the suggestion of writing user stories for your internal team. I’m familiar with writing user stories for our customers, but never have I thought to write them for my internal team.

If we want buy-in from someone, we need to consider their needs and values. This can be helpful in pinpointing what to focus on. For example:

As an engineer I value technical constraints and want to know the technicality required to make this project successful, so I should focus on how to address these.

As a product owner I value business goals and want to know how this is solving the business problem, so I should ensure that I outline how this solution will achieve that.

Equally important as understanding their needs and values is listening. Tom reminded us that listening is more than just letting someone else talk, it’s processing what they’re communicating and really hearing what they’re saying (and what they’re not saying).

Listening helps to uncover the real problem and let others be heard. Tom suggested we practice the art of pause — introducing a moment of silence in our speech to open up the floor for others to chime in or share their suggestions, then listen with intent.

Documenting

As an obsessive note-taker, I wasn’t expecting to take away much from this section of the workshop. I’ve always been good at taking notes and my team mates often rely on me to take notes or collect feedback from a session.

Yet as Tom pointed out note-taking isn’t documentation, it’s just a collection of unorganised thoughts or ideas. Notes live scattered on random bits of paper, floating in documents or emails.

Tom defined documentation as a single source of truth — a place where all notes about a project (including design reviews and action items) reside. If someone missed a meeting, you can direct them to the single source of truth to catch up.

How many times has someone come into a project half way through and asked questions that have already been answered, derailing the meeting and forcing you to ‘catch them up’ on the last three months of conversation in a one hour session? Too many times, right?

Tom’s benefits of documenting:

• Avoids repeat conversations
• Focuses on being articulate
• Builds trust with stakeholders
• Keeps the meeting on track

Responding

The last section we touched on in the workshop was responding. This section was what I came for. I sat up in my seat, eager to hear what Tom was going to share.

Responding is something I’m still learning in my role. How do you respond to a suggestion you don’t agree with, or a question you don’t know how to answer? How can we respond in a way that acknowledges what was said and dig deeper?

Tom suggested to always consider what your stakeholders value. When you can, point to a goal or metric that they care about. Here’s some other techniques he shared:

Repeat and Rephrase

Convert ‘likes’ into ‘works’ to get them to dig deeper and reveal the root problem. For example “What I hear you saying is…” or “I understand that you prefer… why doesn’t it work?”

Come back to the big 3

Remember the role of design. How does this persons suggestion assist in solving the problem? Does it create a good experience for the users? How is it better than the alternatives already explored?

Lead with a Yes

This is a technique that lets others know you’ve heard what they’re saying. For example “Yes I understand what you’re saying”, “Yes there are definitely ways we could improve this” or “Yes I agree we need to solve this problem”.

~

As the workshop came to a close I looked down at the pages and pages of notes I’d taken. I realised I had a lot of work to do (and still do). Introducing this into my workflow and design process hasn’t happened overnight.

However I do find myself more mindful when I attend meetings or discuss my solutions with an engineer. My eyes and ears are wide open, scouting for opportunities to improve the process or communicate better with my team. I’m getting there.

Footnotes:

Did you enjoy this post? I write a lot about digital product design, productivity and content. Subscribe to my mailing list to receive new thoughts straight to your inbox.

Originally published at https://www.femke.co.nz on March 15, 2018.