Structuring Figma before the team outgrew it
A fast-growing fintech with no design practice yet
BMG Money was shipping fast, but design didn't have an established practice to keep up with it. I was the only designer on the team, which meant every file, naming convention, and handoff pattern existed only in my head — fine while I was the only person who needed it, but a liability the moment anyone else had to open a file I'd made.
I wrote and structured a DesignOps guide from scratch to fix that, built around one guiding question:
"Would a new designer, going through onboarding, be able to understand the structure of our Figma setup without needing specific training?"
If the answer was no, the structure wasn't done yet.
Six principles for a Figma workspace anyone can read
The guide covers everything from how teams are structured down to how individual layers are named — because at a fast-moving company, the smallest inconsistency is the one that slows down a handoff.
Teams
Figma offers three team visibility types. The right structure depends on how designers, PMs, POs, and engineers need to access work.
Since our designers were each generally responsible for one product area, a single team was enough — organized into project folders rather than split across multiple teams.
Projects
Projects function like folders within a team. At BMG Money, organizing by the "surface" of the product — rather than by team or sprint — made the most sense, since projects map to major deliverables.
Files
It's tempting to keep an entire project in one file to centralize access — but that becomes overwhelming fast. The better approach: break files down by deliverable, following the story the Product Owner defined.
Every file follows the same internal page structure, so anyone opening it — designer or not — knows where to look:
- Overview: a summary of the task, delivery timeline, and relevant links.
- Hand-off: the interfaces engineering will actually build from.
- User Flows: the flowcharts describing how screens connect.
- Playground: where I test ideas and keep benchmarks that won't ship.
- Legacy: retired items, kept but no longer active.
- Thumbnail: a standardized cover — project name, deliverable, description, and date.
Naming
Names should be descriptive but not overly long, and must always include both the project and the file name — so anyone can find what they need without opening five tabs to check.
Frames
Frames are named after the main interface and its state, so a flow reads top to bottom without guessing.
Since stakeholders often view a file before every screen is finished, each frame also carries a stage tag:
Flows are separated by state with section dividers, and spacing between frames stays consistent throughout.
Layers
The only moment it's acceptable to leave layers unnamed is early ideation and wireframing. Past that, descriptive names are what let developers and stakeholders actually read the file. Names are written in English, to stay consistent with code and the Design System.
Not just policy — hands-on practice
Beyond the written guide, I built practice exercises to reinforce two habits that are easy to explain but only really click with hands-on repetition:
Groups vs. Frames — when to group elements simply to move them together, versus when a frame's layout and resizing behavior is what the design actually needs.
Grids — layout grids for structuring a screen versus column grids for consistent spacing, and how to apply them without fighting the file's existing structure.
Results
Want to see how this applies to your team?
Open to remote roles in fintech and healthtech — full-time or contract.