“A teammate asked how they managed move from concept to spec without losing fidelity at each stage. They started explaining and realized every step ran through figma. Specifically, shared team libraries with publish/update flow had become load-bearing.”
When I'm two days from a design review for a new feature, I want to move from concept to spec without losing fidelity at each stage, so I can maintain a component library that doesn't become a maintenance burden.
A mid-to-senior product designer at a tech company with 3–8 years of experience. Figma is where they spend most of their working day — from rough explorations to polished specs. They work across a shared team library and collaborate with PMs in comments and engineers in dev mode. They are fast, opinionated about component architecture, and quietly frustrated by how the tools around Figma still slow everything down.
To reach the point where move from concept to spec without losing fidelity at each stage happens through figma as a matter of routine — not heroic effort. Their deeper aim: maintain a component library that doesn't become a maintenance burden.
figma becomes invisible infrastructure. Move from concept to spec without losing fidelity at each stage works without intervention. The old problem — engineers who don't use dev mode and ask questions already answered in the spec — is a memory, not a daily fight. Reliable dev mode adoption by engineers reduces back-and-forth by half.
They're two days from a design review for a new feature. The file has 12 frames, 4 component variants, and 23 comments — 8 of which are from a PM who reviewed last week's version, not this one. Engineering wants the spec for a parallel component tomorrow. They have two hours before their next meeting. They are making choices about what counts as "done" right now.
Works in a team of 2–5 designers. Uses a shared component library maintained by a design systems designer (if they're lucky) or themselves (if they're not). Has a file naming convention they follow that nobody else does. Spends 20% of their time in meetings that involve their designs. Does usability testing irregularly. Uses Figma plugins — Unsplash, Stark, Content Reel — as standard operating procedure. Has opinions about auto-layout that they learned through pain.
The proof is behavioral: move from concept to spec without losing fidelity at each stage happens without reminders. They've customized figma beyond the defaults — especially dev mode with CSS and token inspection — and their usage is deepening, not plateauing. They've built a component library that other designers adopt without being asked.
Not a feature gap — a trust failure. Engineers who don't use dev mode and ask questions already answered in the spec happens at the worst possible moment, and figma offers no path to resolution. File performance became unbearable — the lag on large files was forcing them to split designs into worse, smaller files. Their belief — design is a conversation, not a deliverable — but it needs structure to be useful — has been violated one too many times.
Pairs with `frontend-engineer` for handoff workflow mapping. Contrast with `design-systems-engineer` to surface the gap between component design and implementation. Use with `product-manager` to map the design review and feedback loop.