Background
Opening a Figma file at Kiwi.com had become an exercise in interpretation. There was no consistent structure to tell you what was current versus exploratory, what had been approved versus abandoned, or what a particular page was actually for. Context was either missing entirely or applied so inconsistently across files that it could not be relied on. For designers, this slowed down every review and handoff. For engineers, who needed to consume design work without always having a designer in the room to explain it, it was a persistent source of friction and misreading.
The redesign of the team's delivery workflow, completed the year before, had produced clear requirements for what design files needed to communicate. This project took those requirements and turned them into a concrete file architecture, starting with page structure, the layer of the problem that affected everyone every day.
The approach
I was responsible for defining the requirements, creating the initial proposal, running it through stakeholder review, and managing the transition. To keep the project realistic in scope and timeline, we split it into two phases. This case covers phase one: the page structure within individual files. Phase two, covering file and project organisation, followed separately.
Use case validation
The delivery workflow project had already documented most of the use cases from both design and engineering perspectives. Before proposing anything, I validated these with stakeholders at leadership level to confirm the scope covered what teams actually needed and to build alignment before any structural decisions were made. Getting that sign-off early meant the proposal that followed had a clear mandate rather than being one opinion among many.
Initial proposal
With the use cases confirmed, I designed a page naming and structure system that reflected how design work actually moves through a project: from early exploration through iteration, review, and final handoff. The goal was not just organisation but legibility. Anyone opening a file, regardless of how familiar they were with the project, should be able to orient themselves within seconds. That meant predictable naming, a consistent page order, and a clear signal of what each page's content represented.
Stakeholder review and iteration
I ran a structured review round with stakeholders across design, product, and engineering to stress-test the proposal against the reality of day-to-day work. The goal was to surface the cases the initial proposal did not cover well, particularly edge cases in how different teams used Figma differently. I iterated on the proposal based on that feedback before finalising it.
Rollout
The documentation describing the new structure was handed to the design system team, who built guidelines and presentation materials for designers and developers to learn and adopt it. We defined a transition period rather than a hard cutover: designers owning each file could migrate to the new structure progressively, with a tracking template giving leadership visibility into adoption across the team.
Outcome
A consistent page structure eliminated the guesswork that had made files difficult to read for anyone not directly working on them. Design reviews became faster. Engineers no longer needed a designer present to interpret what they were looking at. The transition period approach let the team adopt the new structure without disrupting work in progress, and adoption was monitored and iterated on from rollout onwards.