How a product team uses Figma for UI/UX design day to day: organizing files and libraries, variables and design tokens, components that scale, prototyping for tests, and a handoff to developers that holds up.
Key takeaways
- Organize files by product area, with one shared library that every file uses.
- Variables turn color, spacing and type into tokens developers can mirror in code.
- Components with clear variants and properties stop the design from drifting.
- Dev Mode and ready-for-dev status make handoff a habit rather than an event.
Organize files and projects
Keep one Figma project per product, a file per major area, and a separate library file for the design system. Inside each file, use pages for work in progress, ready for development and archive, so nobody builds from an exploration.
Name frames by what they are, such as Checkout / Payment / Error, rather than Frame 312. Good names make search, prototyping and handoff easier for everyone.
- One project per product
- One file per major area
- A separate library file
- Pages for in progress, ready and archive
- Frames named by screen and state
Use variables as design tokens
Figma variables hold color, spacing, radius and type values in one place, with modes for light and dark themes or different brands. Components refer to variables, not raw values, so one change updates the whole product.
Name variables the way developers name tokens in code. When the names match, handoff becomes a lookup rather than a translation.
Related: why Canva is not a Figma replacement.
Build components that scale
Build components with variants for state, such as default, hover, disabled and error, and component properties for text, icons and optional parts. Use auto layout throughout so components adapt to content rather than needing new versions.
Publish the library, and review changes before publishing them, because every file that uses a component will pick up the update.
| Component part | Use it for |
|---|---|
| Variants | States and sizes: default, hover, error |
| Boolean properties | Optional parts: an icon, a helper text |
| Text properties | Labels designers change often |
| Instance swap | Icons and nested components |
Prototype for tests, not just demos
Prototype the tasks you want to test, such as signing up or completing a purchase, with realistic content and the error paths as well as the happy one. Variables and conditional logic let a prototype remember choices and show different outcomes.
Test with five people from the audience before development starts. It is the cheapest point at which to find out a flow does not work.
Review and collaborate in the file
Comments pinned to frames keep feedback next to the design it is about. Resolve them when they are handled, and use branches for larger changes so the main file stays stable while an idea is explored.
Save named versions at each milestone. When someone asks what changed since the last review, the version history answers.
Hand off in Dev Mode
Mark sections ready for development when they are final. Developers use Dev Mode to inspect spacing, variables and assets, compare changes since they last looked, and link components to their code equivalents.
Handoff works best when it is continuous. Designers stay in the conversation during the build, answering questions in the file, rather than throwing a finished file over the wall.
Related: our UI/UX design service.
What we deliver in Figma
Every NeoDimensional design project is delivered in the client's own Figma workspace: the screens with every state, a clickable prototype, and a design system with components and variables. Our websites, designed and built, start at $1,599 for up to five pages.
If you are designing a single landing page rather than a product, our step-by-step guide to landing page design in Figma is the better starting point.
