A process designed to
survive people.

The problem

No system, only memory

When I joined the IKEA New Business Platform 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.

The process that existed depended on specific individuals to hold it in memory and transmit it informally. When those individuals weren't available, or when new team members joined, the system collapsed. Every onboarding was a fresh negotiation. Every handoff required someone to explain things that should have been documented.

Approach

Principles first, tools second

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.

The framework

Four tools, one backbone

The framework defines a clear hierarchy across the four primary tools the team uses:

• Figma

  Source of design truth. All live design work lives here. No design decisions exist only in Confluence or Jira.

• Confluence

  Source of context truth. The why behind decisions, research synthesis, process documentation, onboarding materials.

• Jira

  Source of progress truth. Task status, sprint scope, blockers. Not a design repository.

• Phrase

  Source of copy truth. All localisation-ready strings flow through Phrase. No copy lives only in Figma.

Outcome

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 that can be fixed by adjusting documentation, not by hunting through files.

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.