A process designed to survive people.

Eight failure modes, not one

When I joined the team, the working process existed — but only in people's heads. Files were spread across Figma, Confluence, and local drives with no consistent structure. The hierarchy of work — what belonged in Figma, what in Confluence, what in Jira — was unclear and inconsistently applied.

What looked like a cultural problem was a structural one. A root cause audit surfaced eight distinct failure modes actively slowing the team down. They were not independent — each fed the others:

Principles first, tools second

The first step was making the existing state legible. Mapping what was actually happening — not the ideal, not what people believed happened — revealed that the problems were structural, not behavioral. People weren't being careless; the system had no clear rules about who owned what at which stage.

The instinct in these situations is to audit the tools and then write documentation for them. That's the wrong order. Documentation without a structural principle is just more noise.

I started by mapping the actual work — the types of tasks the team performed, their interdependencies, the decisions that kept getting lost, the questions that kept being asked by new team members. From that map, I derived a set of structural rules: what type of information lives in each tool, when it moves between tools, who owns it at each stage.

Once the principles were clear, the documentation wrote itself. Tools were assigned roles. Naming conventions followed from those roles. Onboarding followed from the naming conventions.

Four tools, one backbone

The framework assigns a single, non-overlapping role to each of the four primary tools. The rule is simple enough to hold in memory without documentation:

Five phases. Two owners.

Alongside the tool framework, the team needed a clear workflow for how design work — particularly content and translations — moved through the production cycle. The existing process had no defined phases, no explicit ownership handoffs, and no point at which translations could be verified before they reached users.

The redesigned workflow is structured as five phases with explicit ownership. Phases one through three are designer-owned: content is defined, localisation keys are set up, and designs are handed off. Phases four and five are engineering-owned: implementation, integration, and QA happen here. The release is the output of a completed cycle, not a deadline that compresses earlier phases.

The critical structural change was in Phase Two. Content localisation keys — the strings that feed the translation system — had to be created during design, not during development. Moving key creation earlier made translations a parallel track from Phase Two onward, which meant they were ready when QA began rather than still in progress.

Component decisions, not component chaos.

File structure and naming conventions solve the organisation problem. Component governance solves a different one: when to use what already exists, when to adapt it, and when to propose something new.

IKEA's Skapa design system provides a solid foundation of icons, foundations, and components. But a product team building features for the Home App will eventually encounter scenarios Skapa doesn't cover. Without a rule, those gaps get filled inconsistently — every designer making a different call, with no trail and no review. The Skapa-First decision framework makes the rule explicit: check Skapa first, adapt if needed, and only propose new components when no existing solution is feasible — with written justification and a governance review before anything enters production.

From untestable to verifiable

The translation workflow was the most acute failure point. In the existing state, localisation keys were created late in the cycle — typically by engineering, not design — which compressed the translation window, forced localisation to happen in parallel with development rather than before it, and left QA with no mechanism to verify language quality before release. Translation errors were caught by end users, not by the team.

The redesigned workflow shifted both the ownership and timing of key creation. Designers create content keys during Phase Two — as part of the design process, before handoff. This turns translation into a parallel track that is ready when development completes. Quality assurance now includes a dedicated translation review step: language errors are catchable before they ship.

The change also reduced the cognitive load on engineering. When keys arrive in development already created and named correctly, engineers aren't making content decisions under deadline. The system produces better work because each role is doing the work it's positioned to do.

When the process is solid, you can design what comes next.

Fixing the structural failures was necessary. But it also opened a different question: now that handoffs and ownership were explicit and documented, which parts of the design workflow could be fundamentally restructured — not just improved — using AI?

Two threads emerged from this:

This work is ongoing and is being shared with senior design professionals at Garaje de Ideas as part of an active AI literacy programme.

Imperfect adoption. Structural bones held.

The framework was adopted — imperfectly. Some habits take time. Some team members adapted faster than others. There are corners of the process that are still negotiated informally.

But the structural bones held. New team members can now onboard without needing a personal guide through every tool. Handoffs have a consistent shape. When the process breaks down, it breaks down in identifiable ways — a naming convention ignored, a Confluence page not updated — that can be fixed by adjusting documentation, not by hunting through files or asking the right person.

The translation workflow change had the most immediate effect: QA could verify language quality before release for the first time. The feedback loop shortened from "a user reports a translation issue" to "QA catches it in pre-production."

I've come to think that imperfect adoption of a well-structured system is the actual success condition — not perfect compliance. A process that survives is more valuable than a process that was theoretically perfect but required constant maintenance by a specific person to function.