The UX Design Process: 5 Stages Explained Step by Step

TL;DR: What You Will Learn

• Empathise and research: Understand your users, their context, and their real problems.
• Define: Turn messy findings into a sharp problem statement.
• Ideate: Generate many possible solutions before committing to one.
• Prototype: Build a low-cost, testable version of your idea.
• Test: Put it in front of real users and learn what breaks.
• Iterate and ship: Refine based on evidence, then release and keep improving.

One important caveat: this process is non-linear. You will loop back, skip ahead, and revisit stages as you learn, and that is exactly how it is meant to work.

What The UX Design Process Actually Is

Let me clear up the biggest myth first. The ux design process is not a rigid checklist you tick off once and file away.

It is a repeatable, human-centred framework for understanding real people, testing ideas, and improving a product based on what you learn. Think of it as a way of working rather than a fixed to-do list.

This human-centred lens is not new. Don Norman, the cognitive scientist who introduced the phrase user experience when he joined Apple in 1993 and later co-founded the Nielsen Norman Group, built his career on a single idea: design for how people actually behave, not for the idealised user you picture at your desk. That principle sits underneath all five stages below.

UX Is Not The Same As UI

Beginners often use UX and UI interchangeably, and that confusion costs teams a lot of rework.

UI is the visual layer: the buttons, colours, typography, and spacing you actually see and tap. UX is the whole journey, including whether the task made sense, felt fast, and solved the person’s real problem.

If you want a fuller breakdown, we cover the difference between UI and UX in a separate guide. For now, remember this: a screen can look beautiful and still fail people badly, and that failure is a UX problem.

The Five Stages Loop, They Do Not Run In A Straight Line

The five stages you will meet in this article are empathise, define, ideate, prototype, and test.

On paper, they look linear. In practice, they curve back on each other, because testing almost always reveals something you missed during empathising, sending you back to redefine the problem.

This is why you see the arrow in the infographic feeding back to the start. Good UX teams expect to loop, ship a version, gather feedback, and loop again rather than aiming for a perfect first attempt.

You will notice this maps neatly onto two frameworks you have probably heard of:

• Design Thinking, which uses the same empathise-to-test flow championed by IDEO and the Stanford d.school.
• The Double Diamond from the UK Design Council, which splits the work into discovering the problem, defining it, developing solutions, and delivering them.

Do not get precious about which model is correct. They are different maps of the same territory, and each stage in this article slots cleanly into both.

Who Is Actually Involved

UX is rarely a solo act. On a typical Singapore product team, a UX designer works alongside product managers, developers, and business stakeholders, and each brings a different constraint you have to balance.

A clear local example is how GovTech continues to iterate on Singpass and the HealthHub app. New features and layout changes roll out based on citizen feedback, usage data, and usability testing, which is the UX process running as a live, ongoing loop rather than a one-off launch.

In the sections that follow, I will walk you through each of the five stages step by step, with the tools, questions, and pitfalls you can expect at every point.

Stage One: Empathise And Research

Every strong ux design process starts here, long before anyone touches Figma. You are trying to understand real people, not the users you imagine from your desk.

The trap I see most often is assumption-driven design. A team decides what users want in a meeting room, ships it, then wonders why nobody uses the feature.

Think of a local bank like DBS wanting to simplify payments for hawkers and gig workers. If they never actually spoke to a hawker mid-lunch rush, they would design for an office worker’s habits, not a stallholder juggling a wok and a QR code.

IDEO’s Tim Brown put it sharply at a design conference in Singapore: for a designer, “empathy is not the end, it’s the means.” The point of sitting with that hawker isn’t to feel good about it; it’s to design for their reality instead of your own.

IDEO’s Tim Brown put it sharply at a design conference in Singapore: for a designer, “empathy is not the end, it’s the means.” The point of sitting with that hawker isn’t to feel good about it; it’s to design for their reality instead of your own.

Qualitative Methods

Qualitative research answers the why. You uncover motivations, frustrations, and workarounds that numbers alone will never reveal.

The main methods I rely on are:

• User interviews: Open-ended conversations to understand goals and pain points in the person’s own words.
• Contextual inquiry: Watching someone use a product in their real environment while asking questions.
• Field observation: Quietly noting behaviour, like how a delivery rider actually checks an app at a traffic light.

For that DBS example, sitting with a hawker between orders would show you they need one-thumb operation and huge tap targets, because their other hand is always busy.

Quantitative Methods

Quantitative research answers the what and the how many. It tells you the scale, but not the reason behind it.

Surveys let you reach many users quickly and spot patterns across segments. Analytics show where people drop off, and heatmaps reveal where they tap, scroll, and hesitate on a page.

Be wary of vanity research here. A survey with only leading questions, or a heatmap you glance at once and never act on, gives you comfort without insight.

Synthesising Findings

Raw notes are not insights. You need to turn interviews, surveys, and observations into artefacts your team can rally around.

Two staples are personas and empathy maps. A persona captures a representative user like “Auntie Lim, hawker, 58, cautious with new tech”, while an empathy map lays out what she says, thinks, does, and feels.

These artefacts keep the whole team honest, so decisions trace back to real evidence rather than the loudest opinion in the room. If you are heading into interviews for UX roles, expect to be quizzed on exactly this, as I cover in these UX designer interview questions that hiring managers ask.

Handling Participant Data Responsibly

When you recruit Singapore users, PDPA applies. Collect only the personal data you genuinely need, get clear consent, and tell participants how their information will be used and stored.

Anonymise recordings and transcripts, and delete them once the study is done rather than hoarding them indefinitely.

A quick recruiting tip for small teams: tap your existing network first. Post in a relevant community group, offer a modest voucher as a thank you, and screen with a short form so you speak to genuine target users, not just whoever replies fastest.

Stage Two: Define The Problem

After research, you sit with a messy pile of interview notes, survey answers, and observations. The ux design process now asks you to make sense of it all.

When the British Design Council examined how design actually worked inside eleven global firms LEGO, Sony, and Starbucks among them it kept seeing the same habit, and in 2005 it captured that habit as the Double Diamond. The pattern was consistent: strong teams narrow down to one sharply defined problem before they chase any solution.  Define is where that convergence happens, which is exactly why getting it wrong is so expensive. 

Let me use a running example. Picture a Singapore home and living SME that took up an Enterprise Singapore Grow Digital or Enterprise Development Grant (EDG) to build its e-commerce store, only to watch shoppers abandon the checkout.

Writing a Clear Problem Statement and Point-Of-View

A problem statement names who is struggling, what they are trying to do, and why it matters. It stays free of solutions.

For our SME, a weak version reads “we need a better checkout page.” A sharp version reads “time-pressed working parents in Singapore want to complete a purchase in a few taps, but our multi-step checkout and surprise delivery fees make them give up before paying.”

I like to frame this as a point-of-view statement: user plus need plus insight. A well-defined problem statement is the single sentence that keeps designers, developers, and the business owner aligned instead of arguing past each other.

Framing How Might We questions

Once the problem is clear, we reopen it just enough to invite ideas. How Might We questions do that without jumping to a fixed answer.

From the checkout problem, you might ask: How might we reassure a first-time buyer that delivery costs are fair? How might we let a returning customer pay without hunting for their card?

Keep these questions broad enough to spark several directions, but tight enough that they still point at the same problem. Three or four good ones are plenty.

Prioritising with Affinity Mapping and Journey Maps

You rarely have the budget to fix everything, so you scope. Affinity mapping groups related sticky notes into themes, so recurring complaints rise to the surface.

A customer journey map then plots the buying steps and marks where frustration spikes. For our SME, you might map browse, add to cart, sign up, enter address, choose delivery, pay, and see two clear pain points.

• Being forced to create an account before checking out
• Delivery charges appearing only at the final step

Those two moments become the priority. You consciously park smaller issues for a later release rather than solving every problem at once.

Scoping like this protects the grant budget and the team’s time. When you can point back to one agreed problem statement, stakeholders stop requesting random features, and you avoid expensive rework once design and build begin.

Stage Three: Ideate Solutions

Now that you have a sharp problem statement from Stage Two, it is tempting to jump straight to the one obvious fix. Resist that urge.

The ideation stage is where you deliberately generate a wide range of solutions before you commit to any single one. The goal here is quantity, not polish. Bad ideas often spark good ones, so give them room to breathe.

Throughout this stage, keep pinning every idea back to the defined problem. If a fintech startup framed its challenge as “new users abandon onboarding before verifying their identity”, then every sketch on the wall should answer that, not add unrelated features.

Diverge with Brainstorming, Crazy Eights, and Sketching

Divergent techniques help you widen the field fast. In a Crazy Eights exercise, each participant folds a sheet into eight boxes and sketches eight rough ideas in eight minutes, one per box.

The pressure forces you past your first safe answer into weirder, braver territory. Nobody worries about neat lines, and that is the point.

Rough sketching keeps ideas cheap and disposable. If you want a faster starting point when you move to higher fidelity later, some of the best Figma templates to kickstart your designs can save you from rebuilding common patterns from scratch.

Run Collaborative Workshops and Design Studios

Ideation should never be a solo act. A design studio brings designers, product managers, developers, and even frontline support staff into the same room to sketch and critique together.

Cross-functional input matters more than most teams realise. A developer might flag that one flashy idea needs a payment integration you do not have, while a support agent knows exactly which step triggers the most complaints.

Picture a GovTech team ideating queue-reduction features for a public service portal. Sitting a service officer next to the designers surfaces real bottlenecks, like citizens repeatedly uploading the same document, that a whiteboard alone would miss.

Converge with Dot Voting and Prioritisation Matrices

Once the ideas are flowing, you need a fair way to narrow them down. Dot voting is the simplest method: each person gets a few sticker dots and places them on the ideas they believe in most.

For a more reasoned cut, plot shortlisted ideas on a prioritisation matrix. A common one weighs user impact against implementation effort, so you can spot the quick wins.

For the fintech onboarding sprint, that matrix might reveal that a progress bar and clearer error messages are low-effort, high-impact wins worth prototyping first, while a full identity-verification redesign gets parked for later.

By the end of this stage, you should walk away with a small, focused shortlist ready to test.

Stage Four: Prototype The Experience

By this point in the ux design process, you have a shortlist of ideas from your ideation work. Now you make them tangible so you can test them with real people before committing engineering hours.

The golden rule here is simple: build at the lowest fidelity that answers the question you are asking. A prototype is not a finished product; it is a cheap, disposable tool for learning.

Low-Fidelity Wireframes And Paper Prototypes

When you are still figuring out flow and layout, start rough. Sketch screens on paper or use grey box wireframes with no colour, no real copy, and no polish.

I like paper prototypes because they invite honest feedback. When something looks unfinished, users feel free to tell you it is confusing, whereas a polished screen can make them hold back.

Picture a local e-commerce brand redesigning its mobile checkout. Before anyone touches code, we would sketch three versions of the payment step on paper and walk a few shoppers through tapping each one.

That thirty-minute exercise often surfaces a broken assumption, like users expecting PayNow before card entry, that would have cost days to fix later.

High-Fidelity Interactive Prototypes In Figma

Once the flow feels right, you climb the ladder to a high-fidelity prototype. This is where Figma earns its place in almost every Singapore product team I have worked with.

In Figma, you can link screens, add real branding, and simulate taps, swipes, and transitions so a test participant feels like they are using a live app. For that e-commerce checkout, we would wire the shipping, payment, and confirmation screens into a clickable flow that runs on a real phone.

If you are new to the tool, get comfortable with components, auto layout, and prototyping connections first. Our guide to Figma design basics every beginner should master walks you through exactly these workflows.

You can also move faster now that AI helps generate variations and placeholder content. Have a look at these Figma AI features that speed up design work when you need to spin up options quickly.

Choosing Fidelity Based On What You Need To Learn

The mistake I see most often is jumping straight to a beautiful Figma prototype when a napkin sketch would do. Fidelity should follow your question, not your ambition.

Ask yourself what you are actually testing before you build:

• Testing the flow or information hierarchy? Stay low fidelity with wireframes.
• Testing whether a feature is understood? Use a clickable mid-fidelity mockup.
• Testing visual trust and micro-interactions? Go high fidelity in Figma.

Remember that every prototype is meant to be thrown away. Because they are cheap to change, you can rework the checkout five times in a morning, which is far better than discovering the problem after your developers have shipped it.

This is core to how IDEO works. The studio is known for prototyping early and often, and for the motto to fail early to succeed sooner, surfacing broken assumptions on paper while they’re still cheap to fix, not after engineering has shipped them.

Stage Five: Test With Real Users

You have a prototype. Now comes the moment that separates good teams from hopeful ones: putting that prototype in front of real people before a single line of code gets written.

Testing early is far cheaper than fixing a live product. The whole point of the ux design process is to catch problems while they are still just pixels, not shipped features.

Planning Usability Tests and Writing Task Scenarios

Start with a short test plan. It states what you want to learn, who you need in the room, and the tasks you will ask them to attempt.

The most important part is writing task scenarios rather than instructions. Instead of saying “click the book button”, you frame a realistic goal: “Your mother needs to see her cardiologist next Tuesday. Book that appointment for her.”

Good scenarios give context and a reason, then let the participant find their own way. That is how you spot where they hesitate, backtrack, or give up.

Recruiting the right people matters just as much. If you are designing a HealthHub-style appointment booking flow, you need to recruit older Singaporeans who actually use these services, not just whoever sits near you.

You also need fewer participants than you’d think. Jakob Nielsen of the Nielsen Norman Group has argued for decades that the best results come from testing no more than 5 users; a small round surfaces roughly 85% of a design’s usability problems, and several small tests beat one big one. For a Singapore team on a grant budget, that’s what makes testing every loop affordable.

Moderated Versus Unmoderated Testing

You have two broad choices. Moderated testing means a facilitator sits with the participant, asks them to think aloud, and probes gently when something surprising happens.

Unmoderated testing sends tasks to participants who complete them alone, often through a tool that records their screen and voice. It scales better and costs less, but you lose the chance to ask “what were you expecting there?” in the moment.

For that healthcare booking flow with older users, I would choose moderated sessions. You will catch accessibility gaps that unmoderated tools miss entirely: small tap targets, low-contrast text, confusing icon labels, or a login step that quietly locks people out.

Whichever route you pick, get informed consent before recording. Under PDPA, you must tell participants what you are capturing, why, how long you will keep it, and get their clear agreement. A simple signed or verbal consent form at the start covers you.

Measuring Outcomes and Feeding the Next Loop

Impressions are not enough. Capture a few honest metrics so you can compare designs and track progress over time.

Three that consistently earn their keep:

• Success rate: The percentage of participants who completed the task without help.
• Time on task: How long the task took, which surfaces friction even when people eventually succeed.
• SUS score: The System Usability Scale, a short standard questionnaire that gives you a comparable usability number.

Here is the mistake I see most often: teams test only with their own colleagues. Your colleagues know the product, share your assumptions, and will never struggle the way a real older user does with a small font or an unfamiliar flow.

Finally, testing does not end the process. Every finding feeds back into define, ideate, and prototype, so you loop again with a sharper design before you commit engineering time to building the wrong thing.

Iterate And Ship With Confidence

Testing gives you a pile of findings, but findings alone do not improve a product. The final stretch of the ux design process is about turning what you learned into changes that actually ship, then measuring whether those changes worked.

Here is the mindset shift that matters most: shipping is not the finish line. It is the start of the next loop.

Turning Test Findings Into A Prioritised Backlog

After a usability test, you will have a mix of small annoyances and genuine blockers. Not all of them deserve the same urgency.

I sort findings by two things: how many users hit the problem, and how badly it stops them from completing their goal. A confusing button label that traps every user during checkout jumps to the top. A minor wording preference goes to the bottom.

Write these up as clear backlog items with the observed behaviour, not just your opinion. A ticket that says “3 of 5 users could not find the delivery date field” is far more actionable for a product owner than “improve the form”.

Design Handoff And Specs For Engineers

Once fixes are prioritised, you hand off to developers. A sloppy handoff is where good design quietly dies.

In tools like Figma, I annotate spacing, states (hover, disabled, error), and edge cases such as long names or empty data. I pair the file with a short written spec covering interaction logic and any PDPA-relevant consent copy, which matters a lot for local fintech and healthcare products.

Clear handoff skills also matter for your career. If you want to stand out to employers, understanding how your work translates into shipped features is part of why most UX designer job applications get rejected and how to fix yours.

Post-Launch Measurement And Continuous Improvement

Once the feature is live, you measure. Analytics tools show you where real users drop off, and A/B tests let you compare two versions with actual traffic rather than guesses.

Picture a small product team at a Singapore SME, upskilled through a SkillsFuture-supported course, that has just launched a redesigned booking flow. They set task completion rate as their key metric and check it against pre-launch numbers.

Every month they review the data, spot the next weakest step, run a quick test, and ship another fix. Over a quarter, those small monthly gains compound into a flow that feels noticeably smoother.

This monthly loop is what separates mature UX teams from one-off projects. Anyone can run a redesign once. Teams that keep measuring, learning, and iterating are the ones whose products keep getting better after launch, and whose designers keep growing too.

Common Mistakes That Derail The UX Process

I have watched more projects stumble over the same handful of errors than I can count, and the frustrating part is that every one of them is avoidable.

Think of this section as an honest audit. Read each pitfall and ask yourself whether it describes a project you are running right now.

The Five Classic Traps

The ux design process breaks down when teams treat its stages as optional. Here are the ones I see wreck timelines and budgets most often.

• Skipping research. Building on assumptions feels fast, but you are just guessing in a nicer font.
• Defining the problem too broadly. “Improve the app” is not a problem statement. “Reduce the steps to renew a policy” is.
• Falling in love with the first idea. The first concept is rarely the best one; it is just the loudest voice in the room.
• Over-polishing prototypes too early. Spending three days on pixel-perfect visuals before you have validated the flow is wasted craft.
• Testing only with internal staff. Your colleagues know where every button lives, so their smooth run tells you nothing about a real user.

The Cost of Skipping Steps in Singapore

Let me give you a scenario I have seen play out with local SMEs. A retail business here secured Enterprise Development Grant (EDG) support to build a customer loyalty app.

They rushed straight from an idea to a full build, with no research and no user testing. When it launched, customers could not find how to redeem points, so downloads stalled, and reviews turned harsh.

The team rebuilt the app a second time to fix the same problems that a single afternoon of usability testing would have surfaced. That second build ate into their grant funding and pushed the launch back by months.

Disciplined process is not bureaucracy; it is insurance. The reason UX roles command the pay they do, which you can see in what UX designer salary figures look like in Singapore, is that this discipline saves companies exactly this kind of expensive rework.

Accessibility and PDPA are not Afterthoughts

One trap sits quietly across every stage: ignoring accessibility and your data obligations.

If your colour contrast fails or your forms are unusable by screen readers, you are excluding real customers. And the moment you collect user data in research or testing, the Personal Data Protection Act (PDPA) applies.

Get consent, store responses securely, and never keep personal data longer than you need. Building accessibility and PDPA compliance in from day one is far cheaper than retrofitting them after a complaint.

How To Build UX Process Skills In Singapore

Reading about the ux design process is one thing. Actually running it on a real project is what turns you into someone a hiring manager wants to interview.

Practise on a Portfolio Project

The fastest way to internalise the five stages is to pick a problem you genuinely care about and work it end to end.

Maybe you use a hawker centre queueing app that frustrates you, or a clinic booking flow that feels clunky. Redesign it. Do the user research, define the problem, sketch ideas, build a prototype, and run a quick usability test with three friends.

If you have never opened Figma, start with our step-by-step Figma tutorial for beginners so the tool stops getting in the way of your thinking.

I always tell learners to document every stage as a case study, not just show the pretty final screens. Hiring managers want to see how you reasoned, not just what you designed.

Join Local UX Communities

You will learn faster with people around you. Singapore has active UX and product design meetups, portfolio review nights, and communities on platforms like Meetup and LinkedIn where designers share feedback.

Post your case study, ask for a critique, and volunteer to help a small charity or a friend’s business with their website. Real stakeholders and real constraints teach you things no tutorial can.

Take Structured, Funded Training

Self-study has limits. Structured WSQ UX/UI courses give you a proper framework, a trainer to answer your questions, and a portfolio piece you can actually show.

Here is the part many Singaporeans miss. WSQ courses come with SSG subsidies that lower the fees significantly for eligible citizens and PRs, and Singaporeans can use their SkillsFuture Credit to offset the remaining amount.

• SSG course fee subsidies reduce the base fee for eligible learners
• SkillsFuture Credit can be applied on top to cover more of the cost
• Employers can sponsor staff and tap available SkillsFuture and SSG support for company-sponsored training

Picture Rina, a 38-year-old marketing executive who wants out of a shrinking role. She uses her SkillsFuture Credit to take a beginner-friendly WSQ UX essentials course, builds her first end-to-end case study during the class, then moves into a longer career programme to go deeper.

Within a few months, she has a portfolio that walks a hiring manager through empathise, define, ideate, prototype, and test on one real project. That single, well-told case study does more for her than a dozen half-finished exercises ever could.

Conclusion

If you remember one thing, let it be this: the ux design process is a loop, not a straight line. You empathise, define, ideate, prototype, and test, then you circle back with what you learned and do it again.

That discipline is exactly what saves you from the pain we opened with: shipping features nobody uses. Every hour you spend on research and testing early is an hour you do not waste rebuilding a checkout flow or onboarding screen that confused real users.

The good news is that none of this is a mysterious talent. It is a method, and methods can be learned, practised, and repeated until they feel natural.

So here is my challenge to you. Pick one real project, even a small internal tool or a side idea, and run it through all five stages properly. Interview a handful of actual users, define one clear problem, sketch a few options, prototype the strongest one, and test it with people who are not your teammates.

Then write it up as a portfolio case study, showing your before and after and the decisions in between. That single artefact will tell hiring managers far more than a polished mockup ever could.

When you are ready to build these skills with proper structure and feedback, the WSQ User Experience & User Interface (UX UI) Design Essentials course takes you through this exact five-stage process on live briefs. It is hands-on and SkillsFuture-funded for eligible Singaporeans, so you finish with a real case study instead of a folder of half-done exercises.

And if you already know UX is the direction you want, the UX Design Career Programme picks up where the Essentials course leaves off, taking you from these fundamentals into the deeper, job-ready skills hiring managers actually interview for.

So here is your next step: enrol in the course that fits where you are today, then run one real project through all five stages. Start with one project. The rest follows.