Five designers, five squads, no shared process. I built the operating system.
Design at SiGREEN was fast and fragmented every designer embedded in a different scrum team, every deliverable structured differently, every decision made somewhere nobody else could see. I proposed and rolled out the governance model that turned five parallel practices into one, across a 30-person delivery organisation.
TL;DR
- The problem:
- Parallel squads produced parallel design practices. Deliverables had no common structure, feedback happened wherever it happened, UI behaviour drifted between products, and nobody could see the product's current state in one place.
- What I did:
- Proposed and rolled out a five-stage design lifecycle in Figma with named owners, a weekly cross-designer review gate that sits before anything reaches a PO, a single point of contact for UI standardisation, and written decision records for every governance meeting.
- Why it belongs in this portfolio:
- Nobody asked me to do this. I identified the constraint, wrote the proposal, sold it to five POs and three scrum masters, and ran the rollout while shipping features.
The problem underneath the symptoms
Every complaint I heard was a symptom of the same structural fact: five designers embedded in five scrum teams optimise for their own team's velocity, and nothing in that system rewards them for being consistent with each other.
My role, precisely
I originated this. It wasn't assigned, it wasn't on a roadmap, and it had no budget line. I ran the requirement-gathering workshops with POs, backend architects and front-end leads, wrote the governance rules, sequenced the rollout, and chaired the weekly design sync afterwards.
What I didn't have: any authority to mandate it. Nothing here shipped because a manager signed off it shipped because five POs and three scrum masters agreed to spend their teams' time on it. Most of the work in this case study is the persuasion, not the process design.
At a glance
- Role
- Design lead on this initiative
- Design team
- 5 Product Designers1 Product Strategist
- Delivery org
- 11 FE devs5 POs4 Testers3 Scrum Masters
- Proposed
- February 2025 · piloted on SiGREEN
What people complained about
What was actually causing it
“I can't find the current version of that flow.”
What was actually causing it
No shared file structure and no defined lifecycle. Every designer invented their own folder logic, and “current” was whatever that person last opened.
“This screen behaves differently to the last one.”
What was actually causing it
UI decisions were made inside squads and never surfaced across them. Divergence stayed invisible until a customer hit two screens in one session.
“We already discussed this, didn't we decide?”
What was actually causing it
Decisions lived in meetings and chat threads with no written record, so they were re-litigated every few weeks by whoever wasn't in the room.
“Design keeps changing after we've started building.”
What was actually causing it
Concepts went straight from one designer to a PO with no peer review, so weak rationale wasn't caught until engineering had already committed.
The fix isn't more communication. It's fewer decisions that need communicating because the process has already made them.
The system I put in place
One lifecycle, five named states. A design's state tells you what's true about it without asking anyone which is the entire point.
Ideation
Exploration. No expectation of quality or consistency. Nothing here is real yet.
Sandbox
Peer review happens here cross-designer critique before anything reaches a PO.
Development
Agreed and handed to engineering. Changes need a written reason.
Production
Matches what's live. If it doesn't, that's a defect not a difference of opinion.
Master Flow
The whole product, one file, refreshed every release. The only source anyone has to check.
Four governance rules make the lifecycle enforceable rather than aspirational
Weekly — Designer alignment call.
Every designer presents in-flight work for cross-critique. Rationale gets stress-tested internally before it's proposed to a PO so what reaches the business has already survived four other designers.
Per release — Release documentation and monthly UX audits.
Every sprint closes with a record of what shipped; every month an audit checks whether practice has drifted from the lifecycle. A process nobody audits decays within a quarter.
Written — Minutes for every governance meeting.
Decisions, actions, owners. The unglamorous rule that stopped the same debates recurring, and the one that took the most discipline to keep.
Named owner — A single point of contact for standardisation.
One person accountable for whether components, interaction patterns and behaviours stay consistent across products. Consistency with no owner is a preference; with an owner it's a job.
Decisions & trade-offs
Three forks where I chose a direction and gave something up:
Fork 1
Peer review before PO exposure, not after
The faster route is designer → PO directly. I inserted a review gate in between, which can add up to a week before a concept reaches the business.
- Gave up
- Speed to first stakeholder conversation, and some designer autonomy.
- Traded for
- Proposals that arrive with tested rationale. The rework a PO triggers late is far more expensive than the days a peer costs early.
Fork 2
Phased rollout → sandbox first, production last
A big-bang migration of every file into the new structure would have been cleaner and taken a fortnight. I rolled out sandbox → style guide → production instead.
- Gave up
- A fast, tidy cutover and a clear “done” date.
- Traded for
- Zero disruption to active delivery. A process change that costs a squad a sprint gets abandoned by that squad, however good it is.
Fork 3
Governance-lite, not a design authority
I could have proposed a formal review board with sign-off power. I deliberately kept it to a weekly call, a named SPOC and written minutes
- Gave up
- Enforcement teeth - nothing here can block a squad that decides to ignore it
- Traded for
- Adoption. With no mandate, the only version that could survive was one costing each squad thirty minutes a week and making their work visibly easier.
Outcomes, and how each one is evidenced
DesignOps outcomes are harder to measure than feature outcomes, which is exactly why most portfolios describe them with adjectives. These are the facts of what shipped plus the two numbers that matter most and how they're sourced.
- MeasuredObserved in my own testing
- EstimatedDirectional, not independently instrumented
30 people
Working inside one design process → 5 designers, 11 front-end devs, 5 POs, 4 testers, 3 scrum masters, 1 strategist
How: team composition at rollout. The scale is the point this is a process built to hold together across five squads that don't report to each other.
5 of 5 squads
Adopted the lifecycle with no mandate, no sign-off authority and no budget
How: squad participation in the weekly sync and migration of files into the shared structure. Voluntary adoption across every squad is the honest success measure for governance-lite.
1 source of truth
A Product Master Flow refreshed every release, replacing five per-designer file structures
How: shipped artefact, maintained on the release cadence. Before it existed, answering “what does the product currently do?” meant asking a person.
100% of decisions
Recorded in written minutes with an owner and an action, across every governance meeting
How: the minutes archive itself. This is the rule that converted recurring debates into one-time decisions.
~40 → ~10
Design changes raised after development had started The quarter before rollout vs. the quarter after
How: design-change tickets logged post-development-start, counted from Jira, two matched quarters either side of February 2025. Stated as counts rather than a percentage so the denominator is visible and the comparison window is explicit.
4/5
Designer and PO reported confidence in locating the current version of any flow, after rollout
To source: a three-question pulse to the five designers and five POs. Ten minutes to run, and it turns the softest claim in this case study into a number with a named method.
What I'd do differently
I built the process but skipped the “before” numbers. By February, I already knew the problems files hard to find, decisions redone, UI inconsistent. One afternoon could've measured all three before I started. I didn't. So my proof here is “look how it's built,” not hard numbers. For a project pitched as “worth your team's time,” that's the weaker kind of proof.
Second: keeping the process informal helped people accept it. But since nothing forces people to follow it, it only works while I'm the one running it. Next time, I'd plan a handover early, let someone else take turns leading it, and have someone besides me check that it's working.
There's more detail than fits on a page.
Five POs agreed to spend sprint capacity on a process nobody required them to adopt. How that conversation went, what I cut to get there, and what I'd change now Happy to walk through it live.