Research before drawing
The first step is establishing what the user is trying to complete, and under what conditions. An app for warehouse staff operating one-handed while carrying stock is nothing like a dashboard a manager reads on a large screen — even when both show the same data.
For products that already have users, existing data answers a lot: which screens people abandon, which actions get repeated, where support calls come from. For new products you need interviews — but interviews about what people do today, not about which features they want.
A design system, not a pile of screens
Designing screen by screen produces three different button styles inside one product. Nobody does that deliberately; it happens because each screen was drawn at a different time by a different person.
A design system — a set of rules and reusable components — addresses the cause. It defines colour, spacing, type, and a component set with explicit states: default, hover, disabled, loading, error, and empty.
Empty and error states are the two most often missing from design files, and the two users hit exactly when they are most confused. A list screen with no data yet should tell the user what to do next, not just show white space.
Handoff to engineering
A design is only worth anything if it gets built correctly. So handoff includes the Figma file with full components and tokens, interaction state specifications, responsive rules per breakpoint, and accessibility notes — tab order, screen reader labels, colour contrast.
When 9S does both design and build, the design system becomes CSS variables and component code directly, so what runs in production matches what is in the design file.