PROJECT AT A GLANCE
Role
Self-initiated · Adoption leadership
Domain
Healthcare · Regulated environment
Scope
14 teams · Design, development, product, stakeholders
Framework
Figma branches · Jira · SAFe
Focus
Behaviour change at scale · Breaking silos · Living documentation
A self-initiated workflow methodology that connected fourteen teams.
Fourteen teams. Each with its own PM, PO, designers and developers. Each shipping features. On paper, one organisation working together.
In practice, fourteen islands.
Nobody had decided it should be this way. Nobody had the time, the space or the mandate to look at the whole picture and ask: what if we worked differently?
PLANTING A SEED, NOT FORCING A PROCESS
No one had the full problem. Everyone had a fragment.
I did not arrive with a fifteen-page document explaining how we should all work from now on. That would have ended the conversation before it began.
What I did was simpler, and I now know it was far more effective. I listened closely to what each team needed, and I connected those needs to each other. A designer who did not know how to version their work without overwriting someone else's. A PO who could not see why Jira seemed to speak a different language from design. A developer who received a Figma file with no idea what had changed since the last one.
None of them had the whole problem. Each had one part of it. My job was to put the parts together and show that they were all describing the same problem from different angles.
That was the seed. I forced nothing on anyone. I named out loud what everyone felt but no one had put into words, and I asked: what if we solved it together?
The answer was that allies appeared. People willing to try, to iterate, to give honest feedback when something did not work. That is what turned an idea into a real methodology.
The designer
Did not know how to version their work without overwriting someone else's.
The PO
Could not see why Jira seemed to speak a different language from design.
The developer
Received a Figma file with no idea what had changed since the last one.
THE METHODOLOGY, PIECE BY PIECE
We built the foundation from four pieces that hold each other up.
Clear roles from the start
Who reports a feature, who decides whether it goes to the backlog or gets prioritised, who turns it into a Jira issue, who designs it, who reviews it, who gives final approval. This was not about adding bureaucracy. When nobody knows who owns a decision, everyone waits for everyone else.
A shared journey for every feature
From the moment a manager reports a need to the moment the feature merges into the master file, we mapped a path with clear, named steps: discovery, design exploration, review with the teams who had to validate it, iteration, a second review, approval, merge. Eleven steps. Few features needed all eleven. What mattered was that everyone could finally see which steps existed, and where any piece of work stood at any moment.
Jira as a shared language
Under the SAFe framework, we defined what each issue type meant (Epic, User Story, Task, Bug, Enabler) and what a well-defined task looked like: clear, specific, assigned, prioritised, estimated, linked to a user story, and trackable. It sounds obvious written down. In practice, before this, each team read those words its own way, which meant two teams could use the same word for completely different things.
Branches in Figma, with real traceability
Every change in its own branch, linked to a Jira ticket. No one touching the master file directly. A version history anyone could follow, and a clear way to create a new release version: duplicate the main file, freeze it, rename it, and move on without losing any part of the work already done.
THE MOMENT OF TENSION: BRANCHES
It wasn't resistance to change. It was fear. And a completely legitimate fear.
Of the four pieces, one caused more pushback than the other three combined: branches.
The pushback came from fear, and a completely fair fear. What if I forget to create a branch linked to a Jira ticket? What if I touch the master file by mistake? What if I break someone else's work without noticing?
For someone who has spent years in a single Figma file, with no versioning and no branches, moving every change into its own space until it is ready is more than a tool change. It changes how you understand your own work inside a bigger system.
A manual would not have solved this. We ran sessions instead, one after another, where people could ask the question they were too embarrassed to raise in a big meeting. Where they could see, in real time, what happened if they created a branch, what happened if they did not, and why the version history they were so afraid of losing was now safer than it had ever been.
Little by little, fear turned into habit. And habit, over time, turned into something no one even questioned.
"90% of our designers no longer knew how to open a Figma file without opening a branch first. Not because they were forced to. By then, working any other way would simply have felt harder."
And when a team completed a feature from start to finish for the first time, following the full journey from the initial report to the merge into the master file, without anyone stopping to ask "what now?", we knew it was no longer an experiment. It was simply how we worked.
THE DOCUMENT FOR YOUR FUTURE SELF
Organisational fish memory. The only cure is documenting for the person who has not arrived yet.
There is something you learn in large organisations that no one tells you until you live it: teams rotate. People change jobs, projects pause for budget, focus moves from one product to another, and suddenly someone new has to understand in a week what took someone else two years to learn.
I call it organisational fish memory. The only cure is the right documentation, written at the right time, for the person who has not arrived yet.
So we created a functional document that answered the questions that future person would ask:
What the product is for, who uses it.
The context it runs in, the devices and languages it must support.
The business requirements behind it: what is essential and what is only nice to have.
The research that backs it, and the guidelines for using it.
How text overflows, how they look and work in RTL, how the handoff to development had to be structured so engineering never had to guess.
"Then we went one step further. We proposed a middle library, sitting between the official design system and the final products, where teams could build their own molecules, organisms and pages, documented in the same language as the central system."
— Intermediate product library
It meant that when the design system released a new version, each product team could decide, with real information, when to upgrade or when to hold its current version without losing its connection to the wider system.
EVIDENCE: THE METHODOLOGY INSIDE THE FILES
This did not just live in people's heads. It lived inside every Figma file, as part of its structure.
