Many teams jump straight from an idea to colourful screens, then wonder why users get lost and developers keep asking questions. A clear design process prevents both problems and saves rework later.
A solid UI/UX design process moves through six stages: understand users and business goals through research, structure the product with information architecture and user flows, sketch layouts as wireframes, apply visual design, test with real users, and hand off organised, specified designs to developers. Each stage reduces risk before the next, more expensive one begins.
Stage 1: User research and discovery
Design starts with understanding, not drawing. Discovery brings together business goals, user needs and technical constraints so that the whole team agrees on what problem is being solved.
- Stakeholder workshops to agree goals, success measures and constraints.
- User interviews to learn how people currently handle the task and where it hurts.
- Analytics and support data from an existing product, if there is one, using tools such as Google Analytics, Hotjar or Microsoft Clarity.
- Competitor review to understand conventions users already expect.
The outputs are usually personas or user profiles, a list of key jobs users need to get done, and a short problem statement. If the idea itself is still unproven, combine this with the methods in our guide on validating an app idea.
Stage 2: Information architecture and user flows
Information architecture decides how content and features are organised and named. User flows map the steps someone takes to complete a task, such as signing up, placing an order or approving a request. This stage answers questions like "where does this feature live?" and "what happens when payment fails?" before anyone worries about colours. Card sorting and tree testing (with tools such as Optimal Workshop) help check that your navigation makes sense to users.
Stage 3: Wireframes
Wireframes are low-fidelity layouts that show structure and hierarchy without visual styling. They are quick to produce and quick to change, which makes them the right place to debate layout, content priority and interactions. Keeping them deliberately plain stops reviewers getting distracted by colours and fonts.
Stage 4: Visual design and design system
Once structure is agreed, designers apply typography, colour, spacing, iconography and imagery that reflect the brand. Rather than designing each screen in isolation, a good team builds reusable components (buttons, inputs, cards, navigation) and style tokens as they go. This is the start of a design system, which we cover in why startups need a design system sooner than they think.
Accessibility belongs here, not at the end. Check colour contrast, text sizes, touch target sizes and focus states against the Web Content Accessibility Guidelines (WCAG 2.2), and follow platform conventions from Apple's Human Interface Guidelines and Google's Material Design for mobile apps.
Stage 5: How do you run usability testing?
Turn the designs into a clickable prototype in Figma and ask representative users to complete real tasks while thinking aloud. Small rounds of testing with five or so participants tend to reveal the most obvious problems, and you can run another round after fixing them. Moderated sessions over video call work well; unmoderated tools such as Maze or Lyssna are useful for quick checks.
Watch what people do rather than what they say. Hesitation, wrong taps and backtracking are the signals that matter.
Stage 6: What makes a good developer handoff?
Handoff is where many projects lose quality. A designer who simply exports screens leaves developers to guess at spacing, states and behaviour. A good handoff includes:
- Organised Figma files with clear page names and only final, approved screens marked as ready for development.
- Components and tokens that match how developers will build them.
- All states: empty, loading, error, success, disabled and edge cases such as long names.
- Responsive behaviour for different screen sizes.
- Interaction notes and simple prototypes for animations and transitions.
- Exported assets and icons in the right formats.
Figma's Dev Mode makes measurements, variables and code snippets easy for developers to inspect. Even with good tools, a short walkthrough meeting between designers and developers catches misunderstandings early.
The process at a glance
| Stage | Key question | Typical outputs |
|---|---|---|
| Research and discovery | Who are the users and what do they need? | Personas, problem statement, goals |
| Information architecture | How is the product organised? | Sitemap, user flows |
| Wireframes | What goes where on each screen? | Low-fidelity layouts |
| Visual design | How does it look and feel? | High-fidelity screens, components, tokens |
| Usability testing | Can users actually complete tasks? | Test findings, revised designs |
| Developer handoff | Can developers build it without guessing? | Specified files, states, assets |
Is the process always linear?
No. In practice the stages overlap and loop. Testing often sends you back to wireframes, and developers may raise technical constraints that change a flow. On agile projects, design usually works a sprint or two ahead of development, delivering tested designs feature by feature rather than the whole product at once. How long each stage takes depends on the product's complexity, the amount of existing research and how quickly decisions are made.
Key takeaways
- Research and structure come before visuals; skipping them leads to attractive screens that confuse users.
- Build reusable components and check accessibility during visual design, not after.
- A complete handoff with all states and behaviours saves far more time than it costs.
AppifyDevs runs the full design process, from research and wireframes to tested Figma prototypes and developer-ready files, and our developers build from the same files. Request a quote for UI/UX design or explore our case studies to see the process in action.