A technique for getting team alignment

A weeknote starting 7 April 2025.

We had a couple of bad stakeholder meetings this week. It started to feel like we were losing their trust and they definitely weren't supportive of the direction our designs were taking.

I know stakeholders desires may not always be user-centred. But, without their support and sponsorship, projects can become completely derailed. Money and effort can be wasted, leading to missed opportunities to improve services for users.

I felt the need to try a different approach, before things descended into a battle over "user-centred design (UCD) purism" versus "protecting the ways things have always been done".

Around the same time, an old teammate got in touch. They were looking for a document we'd used previously to review requirements and gather input from the whole team on a previous project.

I remember it worked well as a way to understand the problem space and gather consensus, before jumping into the designing mock-ups and prototyping phase.

Giving the whole team a chance to input on and review the plan upfront, can give design teams some breathing space later, so it's worth putting in some early effort.

So I decided to try something similar with my current team.

(Technique is a strong word, it's basically: make a list and share it around for feedback. Maybe there are more well documented versions of this approach?)

The technique

• Make a list of problems to solve, scenarios to test, or user stories
• Add each as a row to a table or spreadsheet
• Create columns for the blockers you are having, e.g. technical constraints, service owner feedback or affected components
• Talk people through each row and capture their feedback
• Repeat until there is consensus

I've found that using Microsoft Word or Confluence works well for this. Probably best to avoid using design tools that can feel unfamiliar to non-UCD colleagues.

Example 1

This following format worked well because it gave us a chance to talk about the pros and cons of solving each user story. It enabled everyone to input things they considered to be risks and opportunities.

In my experience UCD people (myself included) bring too much work into scope. It comes from a good place, we want to solve as many problems for users as possible. But I think we also under estimate the effort needed to solve these problems. Bringing in input from other disciplines can help us to be more pragmatic.

The good news is, if anything is ruled out of scope, that later becomes a problem for users that we need to fix, we have some useful notes that will help us to get started quickly.

Example 2

This following example worked well, because as a UCD team we didn't understand the as-is service enough to make changes or introduce new components or patterns.

It is also helping to capture and balance competing requests from different parts of the organisiton.

Conclusion

I think this technique works well because it can uncover hidden problems, constraints and complexities earlier. Often as UCD people, business requirements can land in our lap that seem simple to begin with. Taking some time to interrogate them as a team can often uncover multiple user needs and problems hidden inside.

I suppose it's like a mini-discovery that can be done in the middle of any project phase.

If you jump straight into design mode, and then these problems appear, it can make user-centred design processes look flawed.

Bringing others into the process can demystify the design approach, and ensure everyone feels like they have a chance to input into the direction the designs are taking.

---

Bookmarks

Some unrelated bookmarks that I've been saving this week.

• Do politics belong at web events? By Remy Sharp
• WCAG 2: Guidelines and Guardrails by Eric Eggert
• The dimensions of fidelity in prototyping by Caitlin Roach