Making Figma files self-explanatory
Clearer Figma files, with less need for extra handover

Figma files are central to day-to-day collaboration between designers, PMs, engineers and QA. They are also revisited later for implementation, follow-up iterations and onboarding, sometimes weeks, months or years after the initial work.
I started this project to make Figma files easier to understand, revisit and maintain without relying on the original designer for context.
Problem
Many Figma files were difficult to understand without the designer walking someone through them. Screens were often presented without explaining what had been validated, what was still under discussion, which edge cases existed, or where supporting material lived.
PMs, engineers, QA and stakeholders regularly had to ask for context before they could review or implement a feature. Older files became progressively harder to revisit because the reasoning, business rules and supporting resources were not always clearly connected to the design work. Designer turnover made this more visible: when someone left, part of the knowledge behind a feature often disappeared with them.
The same issue appeared during onboarding. Understanding an existing feature often meant asking the original designer why a decision had been made instead of finding the answer in the design file itself.
Approach
Not everyone at Deezer had access to DevMode, so native Figma annotations could not become the primary documentation system. The information had to remain directly on the canvas, accessible to designers, PMs, QA, engineers and leadership.
I created an Ops Library: a dedicated Figma UI kit containing reusable documentation components that could be dropped into any project.

As designers started using the library, they regularly requested new blocks for cases that were not yet covered. I added these progressively, based on recurring needs across projects rather than trying to define the full library upfront.

Outcomes
Figma files became easier to navigate without requiring a handover meeting. Context, implementation notes and supporting resources stayed attached to the work itself, allowing reviews, QA and development to move forward with less back-and-forth.
The same files also became more useful over time. Existing projects could be revisited with less effort, and new designers could understand a feature by following the documentation embedded directly in the canvas.