®Many app projects lose time in the gap between design and code. The screens look finished in Figma, but developers find missing states, unclear spacing and flows that do not work on a real phone. A smooth Figma to app handover closes that gap, so what users get matches what the team approved.
Why handovers go wrong
Designers and developers think about screens differently. A designer often shows the ideal moment: a full list, a perfect photo, a short name. A developer has to build every moment, including the empty list, the failed upload and the name that runs onto three lines.
Common causes of trouble include:
- Screens designed only for one phone size
- Colours, fonts and spacing that vary slightly from screen to screen
- Missing loading, error and empty states
- Interactions described in a meeting but not written down
- Several versions of the same screen with no clear final one
None of these are hard to fix. They just need to be handled before development starts rather than discovered halfway through.
Prepare the Figma file
A tidy file saves days of back-and-forth questions.
Use a design system. Define colours, type styles, spacing and corner radius as shared styles or variables in Figma. Build buttons, inputs, cards and other parts as reusable components with variants for each state. Developers can then map each one to a single component in code.
Use Auto Layout. Frames built with Auto Layout behave much like layouts in code. They show how a screen should stretch, wrap and scroll, which removes a lot of guessing.
Name things clearly. Layers called "Frame 214" tell developers nothing. Name screens, components and key layers in plain words.
Mark what is ready. Keep explorations on a separate page. Use Figma's Dev Mode and its ready-for-development status, or a clear page structure, so developers know which screens are final.
Prepare assets properly. Icons should be vector, with consistent sizes. Images should be marked for export at the right resolutions, or supplied separately.
What to include in a handover
A handover is more than a link to a file. A complete one covers:
| Item | What it should show |
|---|---|
| User flows | How screens connect, including back and cancel paths |
| All states | Loading, empty, error, success, offline and disabled |
| Responsive rules | How layouts adapt to small and large phones and tablets |
| Interactions | Gestures, transitions and animation timing |
| Content rules | Maximum lengths, truncation and how long text wraps |
| Accessibility | Colour contrast, touch target sizes and screen reader labels |
| Platform choices | Where iOS and Android should behave differently |
Clickable prototypes help for the main flows. A short walkthrough call, recorded for later, answers questions that are hard to write down.
Common mobile UX mistakes to avoid
Some problems appear again and again in mobile app designs.
- Touch targets that are too small. Buttons and links must be easy to tap with a thumb. Apple and Google both publish minimum size guidance.
- Ignoring the safe areas. Notches, camera cut-outs, rounded corners and the home indicator can hide content placed too close to the edge.
- Forgetting the keyboard. When the keyboard opens, it can cover the field being typed in or the submit button.
- Desktop-style navigation. Deep menus and hover effects do not translate to phones. Keep main actions within thumb reach.
- Low contrast text. Light grey on white may look elegant in a design tool and be hard to read outdoors.
- Fixed text sizes. Many users increase their system font size. Layouts should cope with larger text without breaking.
- No feedback. Every tap should produce a visible response, and slow actions need a loading indicator.
- Ignoring platform habits. Back navigation, date pickers and share sheets work differently on iOS and Android. Users expect familiar behaviour.
Working well together after handover
Keep the designer involved during development. Review builds on real devices, not only screenshots. Agree a simple way to log design questions and decisions, such as comments in Figma linked to tickets in your project tool. When something changes in code for a good technical reason, update the Figma file too, so it stays the source of truth.
Small design quality checks before each release catch spacing, alignment and colour drift early, while they are still cheap to fix.
Handover checklist
- Design system with styles, variables and components in place
- Final screens clearly marked and separated from explorations
- Every screen has loading, empty and error states
- Layouts tested on small and large phone sizes
- Interactions and animations described or prototyped
- Accessibility checked for contrast, target size and text scaling
- Assets exported or ready to export
- Walkthrough held and recorded, with an open channel for questions
Frequently asked questions
Can developers turn Figma designs straight into code?
Tools exist that generate code from Figma, and they can help with styles and simple layouts. The output usually needs significant rework for a production app, so treat it as a starting point rather than the final build.
Does Figma Dev Mode replace a handover meeting?
Dev Mode makes measurements, styles and assets much easier to inspect. It does not explain intent, edge cases or flows, so a short walkthrough is still worth the time.
Should iOS and Android apps look identical?
They should share the same brand and structure, but small differences that follow each platform's conventions often make the app feel more natural to its users.
If you want designs that are ready to build, our UI and UX design team can create or review your Figma files and work alongside developers through to launch.