How to Create a User Flow Diagram (With Examples)

TL;DR: What You Will Learn

• A user flow is a visual diagram of the steps, screens, and decision points a user takes to complete a specific task, like signing up or checking out.
• Use one when you are designing a new feature, fixing a leaky funnel, or handing a design over to developers who need clarity.
• The payoff: fewer dead ends, smoother experiences, and a shared reference that stops your team from building the wrong thing.

By the end of this guide, you will have concrete examples and a step-by-step mapping walkthrough you can apply to your own product this week.

Let us start with what a user flow diagram actually is, and why it beats guessing.

What a User Flow Actually Is

Let me start with a plain definition. A user flow is a visual map of the paths a person takes to complete a specific task, from the moment they arrive to the moment they reach their goal.

Think of a resident booking a polyclinic appointment on a HealthHub-style portal. The flow traces every step: landing on the homepage, logging in with Singpass, choosing a clinic, picking a slot, and confirming the booking.

It is not a sitemap, which just lists all the pages on a site. It is also not a wireframe, which shows the layout of a single screen. A user flow sits between them, showing how someone moves through screens to get something done.

Entry Points, Actions, And Decision Points

Every flow has three building blocks. Entry points are where users begin, actions are what they do, and decision points are the forks where the path splits based on a choice or a condition.

In our booking example, the Singpass login is a decision point. If authentication succeeds, the user proceeds to select a clinic. If it fails, they are routed to a retry or a help screen.

• Entry point: The resident opens the appointment portal from a health app link.
• Action: They tap “Book appointment” and search for a nearby polyclinic.
• Decision point: Are slots available this week? If yes, choose a time. If no, join a waitlist.

Mapping these out forces you to answer awkward questions early, like what happens when a preferred slot is already taken.

Task-Based Thinking Versus Screen-By-Screen Design

Here is where many first-timers go wrong. They start by sketching individual screens, then try to stitch them together afterwards.

A user flow flips that around. You think in terms of the task first, then design the screens the task actually needs. This is one of the practical ways the difference between UI and UX shows up in daily work.

When you focus on the goal, you often discover a screen is redundant. Perhaps the confirmation page and the summary page can merge into one.

Why Flows Reduce Guesswork for Developers

A clear flow is a gift to whoever builds the product next. Developers no longer have to guess what happens after a button is pressed, because the diagram already states the outcome.

A good user flow exposes wasted steps before a single pixel is designed. If your booking flow reveals that users must log in twice, you fix it on a whiteboard, not after the code is written.

That is the real payoff. Catching a redundant step in a flow costs minutes, while catching it in a live portal costs a rebuild.

User Flow Versus Journey Map

One of the most common mix-ups I see in workshops is people using “user flow” and “journey map” as if they mean the same thing. They do not, and confusing them will cost you real time in stakeholder reviews.

Let me clear this up using a Singapore e-commerce scenario, because that tends to make the difference click.

Scope and Level of Detail

A user flow is task-level and screen-specific. It maps the exact clicks and decisions a person makes to complete one job, like adding a pair of running shoes to their cart on a Shopee storefront and paying via PayNow.

A journey map is much broader. It stretches across time and captures phases, emotions, and touchpoints, from the moment someone sees an ad on Instagram to the day the parcel arrives and they leave a review.

So the flow zooms in. The journey map pulls back to show the whole relationship.

What Each Artefact Answers

Each one answers a different question, and that is really the heart of it.

• A user flow answers “How does someone actually get from A to B on our screens?” For a Lazada seller, that is the precise sequence of screens between tapping a product and confirming payment.
• A journey map answers “What is the customer experiencing, feeling, and needing across the whole relationship?” That includes the frustration of a delayed delivery or the delight of a smooth returns process.

Here is why this matters in practice. If a stakeholder asks why customers keep abandoning checkout, showing them a sprawling journey map wastes everyone’s time. What you need is a user flow that pinpoints the exact screen where the PayNow QR code fails to load.

Bring the wrong artefact to the wrong conversation, and you will spend the meeting explaining the tool instead of solving the problem.

When to Use Both Together

The good news is these two are not rivals. They feed each other.

I usually start with a journey map to spot the moments that matter, then drill into a user flow for the tricky ones. If the map shows that customers feel anxious during checkout, that anxiety becomes the signal to design a cleaner payment flow.

It works the other way too. When you build a detailed flow and discover a clunky step, that insight gets pushed back up into the journey map as a pain point worth flagging.

Use the journey map to decide where to look, and the user flow to fix what you find. For a growing local seller juggling multiple marketplaces, that pairing keeps both the big picture and the fiddly details honest.

Symbols and Notation You Need to Know

When I first started mapping a user flow, I made the mistake of inventing my own shapes as I went. The result was a diagram only I could read, which defeats the entire point.

The good news is you do not need to memorise the full library of flowchart notation. A handful of borrowed conventions keeps your diagrams readable across an entire product team.

Ovals for Start and End Points

I always begin and close a flow with an oval. It marks the entry point, such as a user landing on a homepage, and the exit point, such as a completed checkout.

Using ovals for both means anyone scanning the diagram instantly knows where the journey opens and where it wraps up. Every flow should have a clear start and at least one end.

Rectangles for Actions and Screens

Rectangles carry the bulk of your flow. I use them for any concrete action or screen the user encounters, like “View product page” or “Enter delivery address”.

Keep the wording inside each rectangle short and verb-led. A rectangle that reads “Tap Pay Now” is far easier to build from than a vague label like “Payment”.

If you are working in Figma to prototype these screens alongside your flow, brushing up on Figma design basics every beginner should master will help you keep the flow and the actual interface in sync.

Diamonds for Decisions and Arrows for Direction

Diamonds are where a flow branches. Any point where the user or the system makes a choice becomes a diamond, and each answer leads down a different path.

Picture a Singapore e-commerce startup mapping a Singpass login. The diamond asks “Authenticated successfully?”, and it splits into two labelled arrows.

• Yes: The user proceeds to their account dashboard.
• No: The user hits an error branch that loops back to retry or offers a help link.

Arrows connect everything and show direction of travel. I always label the arrows leaving a diamond so no one has to guess which branch is the “yes” and which is the “no”.

Stick to these four elements and your flow reads the same way to everyone. That consistency matters most during sprint planning in a small team.

When a designer, a developer, and a product manager at a local startup all interpret the same diamond, the same arrows, and the same rectangles identically, you cut out a huge source of miscommunication. A shared visual vocabulary turns your user flow into a single source of truth, not a document that needs translating in every stand-up.

Mapping a Task Step by Step

The best way to learn user flows is to build one end-to-end. So let me walk you through a real example: the sign-up and first-purchase journey for a fictional Singapore food delivery app I will call MakanNow.

Define the User Goal and Entry Point

Every user flow starts with a clear goal, not a screen. For MakanNow, the goal is: a new user downloads the app and completes their first order.

Next, pin down the entry point. Ask yourself where the user actually begins, because it changes everything downstream.

Our user taps the app icon after seeing a promo on Instagram, so the entry point is the app splash screen, not a homepage. That single decision tells us the first thing they see is a sign-up prompt, not a menu.

List Every Action and Decision in Order

Now write out every action and decision the user takes, in strict sequence. I do this in plain text first, one line per step, before drawing anything.

For MakanNow, the raw list looks like this:

1. Tap “Sign up” and enter email plus mobile number.
2. Tick the PDPA consent checkbox to allow marketing messages (this is where a decision branches: some users skip it, which is fine, but you must not force it as a condition of signing up).
3. Verify the mobile number via OTP.
4. Browse restaurants and add items to the cart.
5. Reach checkout, where the payment method decision appears: PayNow or credit card.
6. Confirm and place the order.

Notice how each decision creates a fork. The PDPA checkbox is a true user choice under Singapore law, so your flow needs a path for consent given and consent declined, and the account is created either way.

This isn’t just good UX hygiene; it’s a legal requirement. Under the PDPA’s Consent Obligation, an organisation cannot make consent to collect, use, or disclose personal data a condition of providing a product or service beyond what is reasonably needed to deliver that product or service. An account can clearly be created without marketing consent, so bundling the two is not allowed.

Because MakanNow is also collecting a mobile number for marketing messages, the Do Not Call provisions apply on top of this: sending marketing SMS or calls to a Singapore number requires the recipient’s clear, unambiguous consent, and that consent likewise cannot be forced as a condition of signing up. Practically, that means the checkbox must be unticked by default, and the “Sign up” button must work whether or not it’s checked.

The PayNow versus card decision is the trickiest fork, because it introduces failure states.

If the card is declined, the user should not be dumped back to an empty checkout.

Instead, the flow branches to an error message with a “Try again or switch to PayNow” option. Mapping that declined-card branch now saves you from an angry one-star review later.

Draw, Then Test and Refine the Flow

Once the list is solid, translate it into boxes for screens and diamonds for decisions. I usually sketch it in Figma, and if that tool is new to you, this step-by-step Figma tutorial for beginners will get you drawing shapes and connectors quickly.

Then test the flow by walking it yourself as three different users: one who declines PDPA consent, one whose card fails, and one who breezes through with PayNow.

Each walk-through exposes a gap. On my first MakanNow draft, I forgot to add a path for a user who abandons at OTP, so I added a “resend code” loop.

Refine until every arrow leads somewhere and no user hits a dead end. Do this on your own product task now, and you will have a working flow within an afternoon.

Worked Examples for Common Scenarios

Let me show you three flows you can copy and adapt tomorrow. Each one is deliberately tight, and each one exposes a friction point that a pretty static mockup would happily hide from you.

The point of a user flow is not to look impressive. It is to force you to trace every decision, dead end, and error state before you commit a single pixel to a design.

Login and Password Reset Flow

Start at the login screen. The user enters their email and password, and you branch: credentials correct or credentials wrong.

Most teams draw the happy path and stop. The real work is the branch where the user has forgotten their password, so map: click “Forgot password”, enter email, receive reset link, set new password, then return to login.

The hidden friction shows up here. If your reset email lands in spam or the link expires in fifteen minutes with no clear message, the user is stuck in a loop, and a flow diagram makes that trap visible in a way a login mockup never will.

E-Commerce Checkout Flow

Picture a small Singapore fashion retailer selling on their own site. The user has three items in their cart and taps “Checkout”.

Now comes the decision that quietly kills conversions: do you force account creation before payment, or offer guest checkout? Forcing sign-up first is one of the most reliable ways to lose a ready buyer, so branch clearly into “Continue as guest” and “Log in or create account”.

After delivery details, map the payment branch. In Singapore, that usually means at least two paths:

• PayNow, where the user scans a QR code and confirms in their banking app before returning to a success screen.
• Card payment, where they enter details, pass a 3D Secure step, then reach the same confirmation.

Drawing both side by side reveals something a single mockup hides: the PayNow path leaves your site and comes back, so you need a clear “waiting for confirmation” state, or the user assumes payment failed and abandons.

Lead-Capture Form Flow

For a B2B services firm running a SkillsFuture-funded workshop, the goal is a completed enquiry form. Start at the landing page call to action.

Branch on form validation: valid fields lead to a thank-you page and an automated email, while a missing field or bad phone format must loop back with an inline error, not a full-page reload that wipes their input.

The friction point here is asking for too much too soon. A flow diagram lets you see, at a glance, that a ten-field form has ten chances to make someone quit, which nudges you to trim it.

Once you have built these three, save them as reusable patterns. For a lean Singapore team without a dedicated designer, reusing a proven checkout or reset flow saves days on the next project, and it reinforces why UI and UX work together rather than treating flows as an afterthought.

Tools to Build Your User Flow Diagram

Once you know what your user flow needs to show, the next question is where to draw it. I have used everything from a scribbled napkin to a fully linked prototype, and the truth is that the best tool is the one your team will actually open.

Let me walk you through the options I reach for most, along with the trade-offs that matter for a lean Singapore startup or an SME sending staff for upskilling.

Figma and FigJam for Design Teams

If your product team already lives in Figma, keep your user flows there too. FigJam is the whiteboard side, great for messy mapping, while Figma proper lets you connect real screens into a clickable flow.

The payoff is that your diagram and your interface stop drifting apart. When a designer updates a checkout screen, the flow that references it sits in the same file, which saves painful reconciliation later.

There is a learning curve, so if you are new to it, our guide on what Figma is used for in design teams is a sensible starting point. Figma has a free tier that suits a small startup, and the paid plans only make sense once you have several editors.

Whimsical, Lucidchart, and Miro for Quick Diagramming

When I just need boxes and arrows fast, I skip the design tools. Whimsical is the quickest for clean flowcharts, Lucidchart handles more formal, detailed diagrams, and Miro doubles as an infinite whiteboard for workshops.

• Whimsical: Fastest to a tidy flow, gentle learning curve, generous free tier for small teams.
• Lucidchart: Strong for structured, documentation-heavy diagrams and stakeholder sign-off.
• Miro: Best for live remote workshops where the whole team maps together.

For an SME upskilling staff through their SkillsFuture Credit, these are approachable because they do not demand design expertise. Anyone in marketing, ops, or product can drop in a shape and label it.

Pen and Paper or a Whiteboard for Early Drafts

Do not underestimate a pen, some sticky notes, and a wall. For the first draft, I almost always start offline, because it removes the temptation to fuss over spacing while the logic is still wobbly.

A picture of a whiteboard sketch shared in your team chat is often enough to align a founder and a developer before anyone touches software.

Start simple, then graduate into a design tool as your flow matures. Sketch the logic first, tidy it in Whimsical or Miro, and only rebuild it in Figma once the flow is validated and tied to real screens.

One last thing that quietly saves hours: pick a tool the whole team already uses. During a remote review, nobody wants to create yet another account, so shared familiarity keeps the conversation on the flow rather than the software.

Testing and Improving Your Flows

Here is the thing I wish someone had told me earlier: the user flow you just mapped is a hypothesis, not the truth. You are guessing how people will move through your product, and until real users prove you right, that is all it is.

Spot the Weak Points on Paper First

Before you test with anyone, read your diagram like a critic. I look for three things every single time.

• Dead ends: where a user lands on a screen with no clear next step or way back.
• Unnecessary steps, like an extra confirmation page that adds friction without adding value.
• Missing error states, such as what happens when a payment fails, or a form field is left blank.

That last one catches so many teams out. Think about a bank’s digital onboarding here in Singapore. The happy path where a customer scans their Singpass and gets approved is easy to draw. The messy path, where the camera cannot read the NRIC or MyInfo times out, is where real users get stuck, and it is usually missing from the first draft of the flow.

Validate with Real People, Then with Data

Once the paper version looks solid, put it in front of actual users. You do not need a lab, and you do not need very many people either. Jakob Nielsen, co-founder of the Nielsen Norman Group and one of the most cited researchers in usability, has long held that “elaborate usability tests are a waste of resources.“

His research with Tom Landauer found that a first round of five users typically uncovers around 85% of a product’s usability issues, with each additional tester past that point. Once the paper version looks solid, put it in front of actual users. You do not need a lab, and you do not need very many people either. Jakob Nielsen, co-founder of the Nielsen Norman Group and one of the most cited researchers in usability, has long held that “elaborate usability tests are a waste of resources.”

His research with Tom Landauer found that a first round of five users typically uncovers around 85% of a product’s usability issues, with each additional tester past that point mostly turning up problems you have already seen.

That is why sitting five people down, giving them a task like “book a health screening appointment,” and watching where they hesitate is not a corner cut, it’s close to the most efficient use of your testing budget, giving them a task like “book a health screening appointment,” and watching where they hesitate is not a corner cut, it’s close to the most efficient use of your testing budget.

This kind of observation is the backbone of usability testing, and being able to talk through it is one of the things that comes up when you look at what UX designers are asked in interviews.

Then let the numbers confirm what you suspected. If you were working on something like HealthHub, funnel drop-off data in Google Analytics would show you exactly which step of the appointment flow bleeds users. When your suspected friction point and the drop-off spike line up, you have your answer.

Keep the Diagram Alive

After every round of feedback, go back and update the diagram. I treat mine as a living document, redrawing the abandoned step, adding the error state I missed, and re-testing the new version. A flow diagram that never changes is a flow diagram nobody is learning from.

One caution I take seriously: any data you capture during testing, whether it is screen recordings, task notes, or personal details, must be handled in line with the PDPA. Get consent before recording, anonymise where you can, and store nothing you do not genuinely need. Good UX and responsible data handling are not in conflict; they are the same discipline.

Common Mistakes to Avoid

Over the years, I have reviewed many user flow diagrams that looked polished but fell apart the moment a developer or stakeholder started asking questions. The problems are almost always the same handful of avoidable mistakes.

Let me walk you through the ones I see most often, using a scenario I have watched play out with more than one Singapore SME.

Cramming Multiple Tasks Into One Diagram

Imagine a small local retailer building an online store. Their team drew one giant flow covering browsing, account creation, checkout, and returns all at once.

In the stakeholder review, nobody could follow it. The marketing lead was asking about promo codes while the developer was trying to trace the checkout path, and the meeting ran over with no decisions made.

Keep one flow to one task. If you are mapping checkout, map only checkout. This keeps the diagram clean and gives developers a single job to build and test.

Mapping Only the Happy Path

This is the costliest mistake I see. The same retailer mapped a PayNow checkout that assumed every payment succeeded instantly.

They shipped it, then discovered that when a PayNow payment timed out, or the customer closed the QR screen too early, the order sat in limbo. Some customers paid twice; others thought the order failed and abandoned it.

None of this appeared in the diagram, so none of it got built. The fix landed as an urgent patch weeks later, which is exactly the kind of rework a flow is meant to prevent.

Always branch out your error and edge cases: payment timeout, network drop, session expiry, insufficient funds. Ask yourself what happens when the ideal path breaks, and draw that.

Over-Detailing Before Validating the Happy Path

The opposite trap is polishing every micro-interaction before anyone has confirmed the core journey makes sense. You waste hours on hover states for a flow that stakeholders later scrap.

Validate the happy path first, get sign-off, then add detail and edge cases.

Inconsistent Notation

When one person uses diamonds for decisions and another uses rectangles, reviews stall while people argue over what the shapes mean rather than the logic.

Agree on a simple notation key up front and put it on the diagram itself.

Here is a quick checklist you can run before your next review:

• One task per flow, not four
• Every decision point has a failure branch
• Happy path validated before detailing
• Consistent, documented shapes and labels
• No orphaned steps that lead nowhere

Avoid these, and your reviews get shorter, your developers ask fewer clarifying questions, and delivery speeds up considerably.

Conclusion

We started this article with a frustrating problem: users landing on your product, starting a task, and then quietly abandoning it before they finish. You often never find out why.

A user flow diagram is one of the simplest ways to solve that. By mapping every screen, decision, and dead end before you build, you replace guesswork with something you can point at and question.

Think back to that abandoned checkout or half-completed sign-up form. A quick flow diagram would very likely have exposed the moment things break down: an extra verification step, a confusing branch, or a form asking for details the user does not have to hand.

That is the real value here. Flows expose friction on paper, where it costs almost nothing to fix, rather than in production where it costs you conversions and rework.

Remember, too, that user flows and journey maps work best together. Journey maps tell you how people feel across the whole experience, while flows show you exactly where each screen leads. One gives you empathy, the other gives you precision.

So here is my challenge to you. This week, pick one real task in your product a booking, a purchase, a password reset- and sketch its flow using whatever you have, even a whiteboard or a sheet of paper.

This article draws on guidance from the Personal Data Protection Commission of Singapore, including its overview of the Personal Data Protection Act and its guidance on the Do Not Call Registry and Your Business. The usability testing statistic references Jakob Nielsen’s 2000 Nielsen Norman Group article, Why You Only Need to Test with 5 Users.

Ready to Build This Skill Properly?

Sketching your own flows is a great start, but nothing replaces structured practice with feedback from people who do this for a living.

The WSQ User Experience & User Interface (UX/UI) Design Essentials course walks you through user flows, journey mapping, and the rest of the UX toolkit hands-on, and it’s SkillsFuture-eligible, so most or all of the fee can be covered by your credits.

Map one flow, learn from it, and let that habit quietly make every product you touch a little easier to use.