Why is “In Progress” a Dirty Word for Stakeholders?

Picture this: you’ve hired a design team. You come to a meeting, ready to see the latest designs. But when the team presents, you notice typos… things you asked to be changed after the last review… small problems, but problems nonetheless. You’re frustrated and lose confidence in the designer.

Now picture this: you’re a designer who wants to make your stakeholders a part of the design process. You invite them to see your progress on the current work. Now, you want to show them things are moving forward since their last review. But they won’t focus on the work you’ve done. They nitpick things you already know and have already discussed. You’re frustrated and wonder if you should go back to “the big reveal” style of designing.

Sound familiar?

To share or not to share

Anyone who watched Mad Men is familiar with The Big Reveal: the moment the client, after disappearing from the room for weeks, returns to see something brilliant, inspiring, and beautiful.

Yet – even in Mad Men – The Big Reveal fails as often as it succeeds. When client expected something different, or they weren’t clear in their requirements, or they just don’t like it, it goes poorly. Maybe their wives (or husbands – it’s not the 1950s anymore) suggested something else. It’s too different – no, not different enough.

So in UX we urge designers to include stakeholders to join us in the design process. These stakeholders are our clients, whether in-house or at an agency. It makes them more likely to like the final design, it helps designers understand constraints, and it builds trust. But it’s not a magic bullet. It adds new complications, as stakeholders will get distracted by typos or header changes. They won’t just focus on layout if they see colors they weren’t expecting.

How do you involve your stakeholders without causing more problems?

Add time for faux reviews

If you want to share your work, and don’t want a distracted stakeholder, make sure there is nothing to distract them! Yes, it’s time consuming and tedious, but one option is to have internal reviews. There, you can double check copy and design before showing anything to the client. In this way, the stakeholder gets to see “the process” but everything they see has already been proofed.

Pros: Stakeholders are impressed
Cons: Extra time and effort required

Don’t show stakeholders everything

Many designers confuse these “in progress” meetings with reviews. Since the goal is to show what you’ve done, it can be beneficial to only share completed screens with the stakeholder. For example, avoid showing screens with only unimportant updates. Think about it like an agile project, where the development team builds and completes small chunks of work in each sprint. Share small chunks with the stakeholder, and avoid the pieces that aren’t in a good place yet.

Pros: It doesn’t slow down the design process
Cons: Stakeholders are likely to ask “where’s the rest”

Lay down the ground rules

If you are going to show your stakeholders exactly where you are, that’s fine. But make sure you’re guiding them. Or, if you’re showing them something with typos and placeholder logos, warn them. Remind them that as part of the process you’ll be doing rounds of QA. Then reassure them that this is not a review, and they are not expected to catch those errors for you. Most importantly, make sure they understand why you’re showing them in-progress work. And if you do want feedback, be specific about why and where.

Pros: Allows you to pause at any place to share work
Cons: Some stakeholders won’t understand, and will still focus on “mistakes”

Identify your goal

For all of these, the key is to remember what your goal is. Most work sharing comes either at the bequest of the stakeholder (“can we be more involved?”) or because the designer does want feedback. Just like any other phase in the project, setting these expectations early will ensure success.