David Cole

On a recent mentoring call I talked about presenting design work to your team. This is far too dense a topic to cover in one post, so consider this the first of a series.

The first point I want to stress is one you hear about any type of meeting: you have to go into it knowing how you’re going to get out of it.

There’s no one type of design feedback session. When I was starting out I would just toss my work up on a screen and say, “What do you think?” But if your team doesn’t know what kind of feedback you’re asking for (which is to say, why they’re even at this meeting), they’ll just start giving their opinion about anything visible. It’s not uncommon for people to point out concerns with aspects that have already been approved, or are months old and not even part of the current project. One common pitfall is getting mountains of feedback on copy, even though you’re not the one who writes copy.

So what kind of feedback should you be asking for? Here are the most typical goals of design feedback meetings:

• You’re in the ideation phase of a new product or feature and you want to share where you are and garner new ideas.
• You have some concept work that suggests different directions, and you want to get a temperature reading.
• You have low fidelity deliverables (moodboards, sketched wireframes) and you want to know if you’ve neglected any major considerations.
• You have a near-final design and you’re looking for the go-ahead to move to code (or to push your code, depending on how you get to near-final).

There are others, but the common thread is this:

How do I move past the deliverable I’m currently showing you so that I can get closer to shipping this project?

In my own head, I call this concept feedback fidelity. Ask only for feedback that gets you to the next jump in fidelity. Certainly consider any and all feedback that comes in, but don’t get bogged down in debates about a problem you won’t be solving until you’re in the next phase of fidelity: there are too many moving parts and if you haven’t been working at the fidelity of the problem, you probably aren’t working with a complete picture.

You should also feel comfortable pushing back on feedback that’s lower fidelity than the phase you’re in. The time for your team to submit those thoughts has passed, and only severe red-flag problems should be considered. It happens far too often that stakeholders don’t take any design feedback meetings seriously except the last one, catching critical issues with decisions that were approved weeks or months ago. But by focusing on fidelity, you also focus their attention, and limit the scope of what they need to be considering. That means there are no excuses for getting feedback in too late.

In practice you’ll probably find that politics can hinder a focused process like this, but if you’re running the meetings (which you ought to be, if you’re presenting) then you have the power to focus everyone’s attention on those aspects that get you closer to shipping.

I welcome questions & feedback: you can use the Ask page, or send me an email. Next I’ll discuss what to show, how to show it, what they’ll say, and what you’ll say back.

✳ process