How I run a design team in a regulated domain

Designers sit in product teams and belong to design. They take priorities from their team and craft standards from us. That split only works if the centre is genuinely useful, so the centre owns the things that are expensive to do once per team: the design system, research operations, the accessibility floor, and the patterns that carry safety properties.

I am a player-coach. I still design, which keeps me honest about whether our standards are achievable and means I feel the friction in our own tooling before someone has to report it to me.

Platform-wide remits — the design system, accessibility practice — are funded time, not goodwill. Unfunded stewardship is how you lose good people quietly.

Research is not something every designer runs alone. The standard, the recruitment and the studies where getting it wrong would be costly sit centrally; the rest is safe for designers to run themselves. In a domain with vulnerable participants, research operations is a safeguarding function, not admin.

The rituals that survived

• Weekly critique, work-in-progress only. Finished work is a presentation, not a critique. Bring the thing you are stuck on.
• Fortnightly 1:1s. Their agenda. I bring at most one item.
• Monthly craft session. One designer teaches the rest something specific. It builds the habit of articulating decisions, which is the skill that separates senior from mid.
• Quarterly written review of the discipline. What got better, what did not, what I am changing. Written, shared with the team, then sent up.

Consistency is a side effect. The reason to build a system in care software is that the properties that matter most — keyboard completeness, contrast, error prevention, the way clinical risk is expressed — should be solved once and inherited, rather than depending on who is in the review.

Three commitments follow from that:

1. Name for purpose, not appearance. RiskFlag, not RedBadge. Appearance-based names quietly become constraints.
2. A component cannot ship at "AA later". Accessibility criteria are part of the definition, checked in CI, plus a manual keyboard and assistive-tech pass on the flows that matter.
3. Make local work legitimate. Teams may build their own components with no process at all. If bespoke work feels like a transgression, people hide it, and the system stops learning what people need.

Tokens sit in three tiers — primitive, semantic, component — and product designers only ever touch the semantic tier. That single rule removes most colour drift.

I lead AI tooling adoption across design and in partnership with engineering — Figma MCP, Claude, AI-assisted workflows, AI design sprints. I am neither precious nor breathless about it. The rule is easy to remember and hard to argue with: it can draft anything a human will read and verify, and nothing a care worker will depend on unverified.

Where it earns its place

• Prototyping. Complex, advanced prototypes for care and clinical flows, used to test and de-risk decisions and to align engineering and clinical stakeholders before anyone builds. This is the highest-value use we have found.
• First-draft documentation from a component spec. A human edits; the blank page was the expensive part.
• Synthesis support on research — clustering, first-pass themes, contradictions across sessions. Never quotes we have not checked, never conclusions we have not reached ourselves.
• Migration work. Codemods for renamed props, spotting divergence between the Figma library and the package.
• Interrogating my own thinking. Steel-manning a strategy before I take it to the CPO.

Where we do not use it

• Generating production UI. Generated markup is plausible-looking with wrong semantics often enough that reviewing it costs more than writing it. In a domain where plausible-but-wrong is the dangerous failure, that trade is bad.
• Accessibility judgements. Automated checks catch a fraction of real issues and give false confidence about the rest.
• Anything touching real care records or participant data. Non-negotiable, and a governance answer rather than a design one.
• Deciding safety trade-offs. A named accountable human decides, with reasoning recorded.

How we avoid the debt

The failure mode is not bad output, it is unowned output. So anything AI-assisted that enters the codebase or the system has a named human owner who can explain every decision in it. If nobody can explain it, it does not ship. That one rule has done more than any policy document.

Portfolios in this domain are misleading. The best work often looks unremarkable — a form that stopped producing errors, a flow that removed a step. So I do not assess visual polish beyond a competence floor. I assess whether someone can explain why a decision was right given what they knew, and what they would do differently.

The interview

• A conversation about their work, where I push on constraints and trade-offs rather than process. I want to hear "we chose X and accepted Y".
• A short live exercise on a real, messy problem. No take-home. Take-homes select for free time.
• A collaboration session with an engineer and a PM, because the job is largely that.
• Every candidate meets a designer who is not me, and that designer's concerns can veto.

I ask everyone the same closing question: tell me about a time you were wrong about a user. People who cannot answer it have usually not been close enough to one.

Growing people

The ladder rewards two things and I say so plainly: the quality of decisions you make, and the quality of decisions you enable other people to make. Senior designers are not paid for output volume. Being explicit about this stopped the most common career conversation in the team, which used to be a good designer wondering why doing more work was not producing progression.

Everyone has one development focus at a time, not five. Progress on one thing is visible; progress on five is not, and invisible progress feels like none.

The gap between mid and senior is nearly always the same: the ability to hold the room while a decision is genuinely uncertain. That is coachable, mostly by handing over rooms.

Design leadership goes wrong when it becomes a quality gate. The gate makes you the last stop before shipping, which makes you a cost, which means you get routed around. I would rather be earlier and less powerful.

Getting design a strategic seat rather than a delivery service is mostly this, repeated:

• Design in the problem definition, not the solution review. A designer in the room when scope is set is worth three in review afterwards.
• Bring options with costs, not recommendations with rationale. "Here are three, here is what each buys and gives up, here is what I would pick" leaves the decision where it belongs — and gets my pick chosen more often than advocacy ever did.
• Never say "users would hate that" without evidence. It spends credibility for nothing and it is frequently untrue.
• Say what evidence would change my mind, every time. It is the fastest way to be trusted, and it keeps me honest when I am arguing from taste.
• Escalate the trade-off, not the disagreement. Leaders can decide between two costed options. They cannot adjudicate whose instinct is better.

The one thing I will not trade is the accessibility and clinical-safety floor. Because I do not spend credibility on smaller things, I rarely have to fight about it.