UI/UX Design Process 2025: From Wireframes to Production-Ready Apps in Figma

Most design process articles describe an idealised sequence that no real project follows. What follows is closer to how the work actually goes, including the parts that are usually skipped and what it costs when they are.

Discovery: Understanding the Actual Problem

The brief you receive is a proposed solution. The job in discovery is to find the problem underneath it.

Talk to People Who Do the Work

Five or six conversations with actual users will tell you more than any amount of stakeholder alignment. You are listening for workarounds — the spreadsheet someone maintains on the side, the WhatsApp group where the real coordination happens, the printed sheet taped to a wall. Every workaround is a requirement that nobody wrote down.

Watch, Do Not Just Ask

People describe their process as they believe it should work. Observation reveals what it is. If you can spend an hour sitting with someone doing the task, do it — this is consistently the highest-value hour in a project.

Write Down What You Learned

A short document listing the users, their goals, the current process, and the specific pain points. Not a deck. Something a developer can read in five minutes and refer back to when a question comes up in month three.

Information Architecture Before Pixels

Before drawing screens, establish what the objects are, how they relate, and how someone moves between them. A rough map of entities and navigation catches structural problems while they are still cheap to fix.

The common failure is designing beautiful screens for a structure that does not match how users think about their work — then discovering it during development, when changing it means rewriting components.

Wireframes: Deliberately Ugly

Wireframes exist to test structure and flow. Keep them low fidelity on purpose. Greyscale, no real imagery, placeholder type.

There is a practical reason: stakeholders review what they see. Show a polished screen and you will get feedback about the button colour. Show a wireframe and you get feedback about whether the workflow makes sense — which is what you actually need at that stage.

Use Realistic Content

Lorem ipsum hides problems. Use real product names, real address lengths, real error messages. Layouts that work with "Item 1" frequently break with "Chilled Distribution — Route 14B Evening Shift (Amended)". Design with the longest realistic string, not the shortest.

Figma: Structuring Files So They Survive

A Figma file that nobody can navigate is a file that gets abandoned. A few conventions make the difference.

Variables and Tokens First

Define colours, spacing, radii, and type styles as variables before building components. Retrofitting tokens into a file built with hardcoded values is tedious and usually left half-done.

• Semantic naming: surface/primary, text/muted, border/subtle — not blue-600. Semantic names survive a rebrand; literal ones do not
• Spacing scale: A fixed scale (4, 8, 12, 16, 24, 32, 48) removes a decision from every layout and makes implementation predictable
• Modes: Variable modes handle light and dark themes without duplicating every frame

Components with Real Variants

Build components with properties covering every state you will actually need: default, hover, focus, active, disabled, loading, error. The states designers skip — focus and loading — are exactly the ones developers then invent inconsistently.

Auto Layout Everywhere

Auto layout is not a convenience feature. It is how you communicate resize behaviour to a developer. A frame that reflows correctly when you drag its edge tells an engineer what should be flexible and what should be fixed, without a single annotation.

Prototyping: Test the Risky Part

You do not need to prototype the whole product. Prototype the flow you are least sure about.

Usually that is the primary task — the thing users will do fifty times a day. Get that one flow clickable enough to put in front of five people, and you will learn more than from a month of internal review.

Running a Useful Test

• Give a task ("Reassign the 14:00 delivery to a different driver"), not instructions
• Stay quiet. The urge to help is strong and it destroys the data
• Watch where they hesitate — hesitation marks unclear affordances more reliably than anything users say afterwards
• Five participants surfaces the majority of serious usability problems; you do not need statistical significance to know a label is confusing

Visual Design and Accessibility

Accessibility is not a compliance pass at the end. Decisions made in visual design either make it achievable or make it expensive.

The Non-Negotiables

• Contrast: 4.5:1 for body text, 3:1 for large text and meaningful UI boundaries. Check while choosing colours, not after
• Never colour alone: A red border does not communicate an error to someone who cannot distinguish it. Pair it with an icon and text
• Touch targets: Minimum 44×44pt. This helps everyone, not only users with motor impairments
• Focus states: Design them. If you do not, developers ship the browser default or, worse, remove the outline
• Type size: 16px minimum for body text on mobile — below that, iOS zooms the page on input focus

Designing for Arabic and RTL

If the product will support Arabic, design at least the core screens in both directions during visual design, not afterwards. Mirroring is not automatic for everything — icons with directional meaning flip, but logos, media controls, and numerals do not. Arabic text also runs taller and needs more line height than Latin at the same point size, which affects every vertical rhythm decision.

Design Systems: Only When Earned

A design system is infrastructure, and infrastructure has maintenance cost. Building one for a single small product is usually premature.

It earns its keep when you have multiple products or teams, a product that will be maintained for years, or recurring inconsistency that is actively causing rework. Below that threshold, a well-organised component library in one Figma file is sufficient and much cheaper to keep current.

The failure mode is a beautiful system that documents components nobody uses because the code diverged six months ago. A system is only real if the coded components and the design components are the same thing.

Developer Handoff

Handoff is not an event where you send a link. It is a conversation that should have started during wireframing.

What Developers Actually Need

• Behaviour, not just appearance: What happens on tap, on error, while loading, when the list is empty, when a value is too long
• Every state: Empty, loading, error, partial data, permission-denied. Missing states are where implementation diverges from intent
• Responsive intent: Which breakpoints matter and what changes at each. Two or three well-defined breakpoints beat a continuum nobody can implement
• Content rules: Truncate, wrap, or scroll? At what length? This question comes up for every text element
• Tokens mapped to code: If your spacing scale matches the CSS variables in the codebase, implementation is mechanical rather than interpretive

After Launch

The design is a hypothesis until real users are on it. Plan to revisit.

• Instrument the primary flow so you can see where people drop out
• Watch support tickets — they are unsolicited usability findings
• Re-run the same usability task three months in; behaviour changes once the tool is habitual

A Note on Designing for Power Apps

If the implementation target is a Power Apps canvas app, design within the platform's grain rather than against it. Canvas apps have real constraints around responsive behaviour, control styling, and rendering performance. A design that ignores them produces an app that is slow and expensive to maintain. Talk to whoever is building it before finalising visual direction — the constraints are specific enough that generic mobile patterns do not always translate.

Conclusion

The parts of this process that get cut under deadline pressure are discovery, usability testing, and state documentation. They are also the three that most reliably prevent expensive rework.

Keep wireframes ugly so feedback stays structural, use realistic content so layouts survive reality, design every state including the boring ones, and get an engineer involved early. The polish matters, but it matters much less than getting the structure right first.