Scott
Quick answer: The UI design process turns a product requirement into an interface that people can understand and use. A practical sequence is: clarify the brief, map the flow, structure the screen, define visual rules, prototype the interaction, test the task, and hand off the decisions with enough context to build them.
The steps can overlap, but skipping a step creates a predictable cost later. A polished screen cannot compensate for an unclear task, missing error state, or handoff that leaves behavior open to interpretation.
UI design process at a glance
- Brief: user, task, context, platform, constraints, and success signal.
- Flow: entry, decisions, completion, cancellation, and recovery.
- Structure: information hierarchy, navigation, content blocks, and actions.
- Visual design: type, spacing, color roles, imagery, and responsive rules.
- Prototype: connected screens, interaction states, and realistic content.
- Review: task walkthroughs, accessibility checks, and unresolved questions.
- Handoff: components, measurements, assets, behavior notes, and ownership.
1. Clarify the brief
Write the user and task in one sentence, then list the platform, content, permissions, business constraint, and signal that indicates completion. Keep assumptions visible. If the team does not know the answer, mark it as an open question instead of hiding it in the visual design.
2. Map the flow and states
Draw the shortest successful path first, then add cancellation, validation, loading, empty, permission, and error states. A flow that contains only the happy path will look complete in a review while failing in use.
3. Build the information structure
Start with a wireframe or simple blocks. Check whether the primary action is easy to find, whether content is grouped by the user’s decision, and whether navigation labels match the language people use. Use wireframing to resolve structure before investing in decorative detail.
4. Establish visual rules
Define a small type scale, spacing rhythm, color roles, and component states. Include realistic content so line wrapping and density are visible. If a pattern repeats, make it a component and document its variants in the design system.
5. Prototype the task
Connect the screens that matter to the decision. Use the prototype to test timing, focus, feedback, and recovery rather than only to demonstrate transitions. Interactive prototyping is most useful when every link answers a question about the user task.
6. Review with evidence
Ask a reviewer to complete the task without a verbal tour. Record where they hesitate, what they expect next, and whether the interface explains an error. Check keyboard focus, contrast, text size, touch targets, and content at narrow widths. Separate observed issues from preferences.
7. Hand off the decisions
Share the source file or inspectable link, prototype, component states, content assumptions, assets, and unresolved questions. Name the frames and components so a developer can locate the relevant decision. A handoff is complete when another person can implement the intended behavior without reconstructing it from a screenshot.
Illustrative example: checkout form
Example brief (illustrative, not a Pixso customer case): A returning shopper needs to add a delivery address and recover from an invalid postal code.
- Brief: returning shopper, mobile web, address required before payment.
- Flow: cart → address form → validation → saved address → payment.
- States: empty, focused, invalid, loading, saved, and server error.
- Review: can the shopper identify the next action, correct the field, and understand whether the address was saved?
- Handoff: field component states, keyboard order, validation copy, and the event that enables the payment step.
UI design process deliverables
| Stage | Useful output |
|---|---|
| Brief | Task statement, constraints, assumptions |
| Flow | Screen map and state inventory |
| Structure | Wireframes and content hierarchy |
| Visual | Annotated screens and reusable components |
| Prototype | Clickable path with key states |
| Review | Findings, decisions, and open issues |
| Handoff | Inspect-ready file, assets, behavior notes |
How to choose the right level of UI design detail
Match the fidelity of the work to the decision the team needs to make. A low-fidelity flow is faster for navigation questions; a realistic prototype is better for interaction, content, and accessibility review.
- Use wireframes when hierarchy, labels, or task order is still changing.
- Use components and realistic content when repeated patterns, density, or responsive behavior need review.
- Use an interactive prototype when timing, focus, validation, or recovery affects the task.
- Keep an inspectable source, state inventory, and open-question list with the handoff.
For a maker workflow that connects these stages, see the UI design maker guide and the UI design examples.
FAQ
Does the UI design process start with visual design?
Usually the first useful step is clarifying the task and flow. Visual exploration can happen early, but the team should know which question it is helping answer.
How long does a UI design process take?
There is no fixed duration. The scope depends on the number of tasks, states, platforms, reviewers, and unresolved constraints. Estimate by deliverables and decisions rather than by a promised number of hours.
Where does UX fit?
UX work frames the user problem, flow, and information structure. UI work gives those decisions a visible, interactive form. In practice the responsibilities overlap and teams should agree on ownership.
Next step: Pick one task, inventory its states, and prototype the smallest path that lets the team test the decision.
