Systems Thinking
How I organize my
Figma
file
One of the reasons why my teammates and developers love me :')
Date:
Thumbnail goes here
The Problem
The onboarding tax
A new hire, a PM two sprints behind, a dev picking up a ticket each opens the same file and pays the same tax: ten minutes figuring out where should I even start?
The Solution
A File Map, Not a Maze
There's no universal standard here. Every designer, every team has their own working philosophy for structuring a file which is exactly why a "README" carries so much weight.
It's not documentation for its own sake, it's the translation layer between how you think and how everyone else needs to read it.
The Problem
The Progress Black Box
PM asks “are we on track?” and the honest answer is a shrug as nothing in the file ties a screen back to an actual requirement, so “progress” is a feeling, not a number.
The Solution
Screens Tied to the “Why”
Every flow is labeled against the user story or ticket it serves, with a coverage checklist sitting right beside it. So progress reads as "6 of 8 stories covered," a number, not a vibe.
One rollup page with release status and what shipped this cycle so devs get the context behind a flow without a meeting and a PM or manager gets the same visibility without opening a single frame.
The Problem
The final_FINALLLLLL problem
Three versions of the same screen sit side by side. Nothing says which is exploration, which is approved, which shipped so devs and PMs end up pinging you to check.
The Solution
Screens Tied to the “Why”
Figma Pages are grouped either by sprint or delivery milestone. Once a design ships, the page gets marked ready for dev and the tag changes with it.
Critique and feedback live in a separate file from the shipped files and scratchpad, and are labeled with so stickies.
Which means my "messy" page gets to stay messy :)