\n
\n
![\"demo](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/CTA-blog-banner-1-1.png\")
<\/a><\/p>\nDo progress bars actually work?<\/h2>\n
The short answer is: it depends.<\/p>\n
The problem is that this isn’t a binary decision (show one or don’t); the real variable here is pacing. That variable determines whether you need a progress bar and how effective yours will be.<\/p>\n
What the research says<\/h3>\n
In 2010, Frederick Conrad and his colleagues at the University of Michigan’s Institute for Social Research published one of the most rigorous studies on progress bar behavior in digital tasks<\/a>.<\/p>\n They ran two large-scale experiments testing how the speed and timing of a progress bar affected whether users completed an online questionnaire. This test covered four conditions:<\/p>\n They tracked the abandonment rates for each of these states.<\/p>\n The fast-to-slow bar, the one that was most encouraging early on, even though it overstated initial progress, produced the lowest abandonment rate at 11.3%. But there was a catch (more on that in a minute).<\/p>\n The slow-to-fast bar, which was technically the most honest representation of how the process was actually progressing, produced the highest abandonment rate at 21.8%.<\/p>\n The constant-speed bar, the default implementation most teams reach for, didn’t reliably outperform having no bar at all (14.4% vs. 12.7%).<\/p>\n The first impression was critical. An accurate, well-intentioned progress indicator designed to reduce uncertainty actually made things worse when the early news it delivered initially was discouraging.<\/p>\n Conrad’s team named this dynamic “knowledge cuts both ways”: a progress bar that communicates encouraging news helps users persist, but one that communicates discouraging news (however accurately) drives them to leave. This is the piece most UX guides on progress bar design skip entirely.<\/p>\n Beyond the abandonment rate, Conrad’s team asked users how they felt about their progress. Users whose progress started slowly but moved quickly toward the end maintained a negative view of the process.<\/p>\n Although the pace had fully reversed towards the end to match the initial speed of the fast-to-slow group, they still judged the process to be slow and time-consuming.<\/p>\n The conclusion? Users formulate their opinion about the task early on and hold on to that opinion even as the evidence changes.<\/p>\n I’ve seen this play out with a lot of onboarding checklists. The designer weighs the first steps smaller, because they are simpler, and reflects that in the progress bar design. By Step 3, the user is convinced the process is too taxing and leaves, regardless of how fast things are designed to move from there.<\/p>\n I once came across a study by Eytan Adar of the University of Michigan in which he used the phrase “benevolent deception.” He described it as the decoupling of the visual indicator from actual system progress to make users feel better.<\/p>\n If you’re like me (and most users are!), what you want more than anything is to know that your system is working, even when you have to wait for it.<\/p>\n Perhaps you’ve even seen this in practice. A client complains that the system feels broken while waiting for it to complete a background task. The moment you add a progress bar, though, the user is less agitated.<\/p>\n It doesn’t matter if that progress bar correctly estimates the task time, so long as it shows the user that the system is working. And therein lies the usefulness of a progress bar.<\/p>\n The goal of any progress bar UI\/UX in SaaS is to reassure users that the system is working, manage their expectations about timing, and reduce the anxiety that comes from uncertainty. Accuracy is useful if it is positive; otherwise, well… you have other design options.<\/p>\n No.<\/p>\n Sometimes, having no progress bar is better than having any at all. At other times, you absolutely must have a progress bar. So, how can you know when you need one?<\/p>\n The answer comes down to timing:<\/p>\n For waits under one second, any loading animation is wasted. There isn’t enough time to process the transition before it disappears. If you insist on putting one in, you may only be training your users to expect a delay that never comes.<\/p>\n For waits of one to three seconds, a simple spinner or skeleton screen<\/a> is the right choice.<\/p>\n These indeterminate indicators do just enough to tell the user that the process is running and will soon finish. Skeleton screens do even more for page loading states. They give the user a preview of what they’re about to see, which makes the transition feel faster.<\/p>\n One product I’ve seen combine indeterminate screens to good effect is Mural. A loading page starts with a blank screen, which is soon replaced by a skeleton screen. But, all the while, an indeterminate progress bar stays on screen with a useful short tip.<\/p>\n This combination makes a genuinely slow load feel intentional rather than broken.<\/p>\n For waits above three seconds, a progress bar becomes worth implementing.<\/p>\n As a rule of thumb, the longer the wait, the greater the anxiety a spinner elicits. So, always use a progress bar (one that shows actual or estimated completion status) for any wait above 3 seconds.<\/p>\n I find that the best progress bars contain descriptive labels. For anything below 10 seconds, a clear percentage of progress may be enough to keep the user at ease.<\/p>\n Above 10 seconds, a horizontal bar slowly moving across a blank screen becomes frustrating. Instead, pair it with a label that says\u00a0“Uploading file…” or “Saving your changes…” This tells the user what’s happening, which bolsters their confidence.<\/p>\n For any multi-step process, like an onboarding checklist<\/a> or flow, a basic progress bar isn’t enough. Users need to understand the structure of what they’re moving through: how many sections there are, where they currently sit, and what happens when they finish. Without that structure, a 45-second process feels indeterminate even when the bar is technically moving.<\/p>\n You can see this principle applied in Slack’s onboarding flow. The tooltip directly tells the user how many steps they’ve completed and how many are left.<\/p>\n ActiveCampaign takes things even further, with its onboarding flow combining three indicators:<\/p>\n Of course, if your onboarding process is simpler than theirs, I’ll tell you this combination is overkill, but it’s perfect for their flow. Each element serves a different layer of the experience, without competing for attention. Together, they give users a sense of control over a genuinely complex setup process.<\/p>\n The most underdiscussed dimension of a progress bar UI\/UX in SaaS is pacing. Once you’ve decided a wait needs a progress indicator, the design question shifts from “what type of progress bar do we need?” to “how should it move?”<\/p>\n Most teams stop thinking at this point. They implement a linear bar tied to system progress and call it done.<\/p>\n Thanks to Conrad’s research, we know that’s not always the best approach. So, here’s how I’ll approach the question.<\/p>\n If your system can track completion, you don’t have to display the raw percentage. Instead, weigh early progress more. Conrad’s team called this the “fast-to-slow” approach: calculate progress using a function that advances faster early and slower later.<\/p>\n This is the benevolent deception described earlier.<\/p>\n My weighting typically looks like this: if a process has 10 steps, I can weight the first three to represent 50% of the visual bar’s fill area, then distribute the remaining 50% across steps 4 through 10. The user sees the fast early progress, and their perception of speed never changes.<\/p>\n A note of caution:<\/strong> Your progress bar should never stop moving until the process is complete. The moment it does, users assume the process is broken or the application is frozen.<\/p>\n For indeterminate processes (report generation, complex data analysis, third-party API calls), you can’t show an accurate percentage because you don’t have one. Some say you should fake a percentage anyway, but that creates a different kind of trust problem when the estimate turns out to be wildly off.<\/p>\n What I’d do instead is to use an animation that communicates confidence.<\/p>\n First, I’ll test the process under varying network conditions and determine the average time it takes to complete. Then, I’ll set the animation’s pacing to match the process time, while maintaining the fast-to-slow approach.<\/p>\n Alternatively, if the wait is genuinely long and also indeterminate, you can use an intermittent progress bar. This shows the user the milestones they’ve reached, without showing them a steady but slow-moving process that could be discouraging.<\/p>\n Whatever pacing approach you use, never let your progress bar freeze at 99%.<\/p>\n Going fast to slow, only to grind to a halt at 99%, is not worth it. Whatever early optimism you built, the halt feels like a crash (of the process or the application). Keep the 99% long enough, and the user gives up, and refreshes the page or abandons it altogether.<\/p>\n If the final part of the system process takes disproportionately long, build that into the pacing from the start. Reserve the last 15-20% of the visual bar for that final step, so users see slow, but continuous movement rather than a freeze.<\/p>\n Once you’ve designed and shipped your product, it’s time to audit your loading states to make sure they aren’t discouraging your users. During any loading state audit, I focus on a single question: “Is the current loading state actually helping?”<\/p>\n Here’s how I’ll approach my response:<\/p>\n First, list every point in the product where a user waits more than one second.<\/p>\n No, not from memory. You’re too familiar with the product and may consider a wait time normal when it really isn’t.<\/p>\n Instead, watch users’ session recordings filtered for pauses in user activity longer than two to three seconds. This should surface the delayed loading states you’d otherwise miss.<\/p>\n For each wait you identify, answer the following questions:<\/p>\n Notice that timing data alone isn’t enough to answer these questions. Timing data may tell you how long<\/em> a wait is. Session recordings, however, tell you what the user does<\/em> during the wait.<\/p>\n Kevin O’Sullivan, our Head of Product Design at Userpilot, puts the value of combining both clearly:<\/p>\n “The best way of conducting any sort of research is not to follow one method only; try to marry the quantitative with the qualitative. Session replay is the perfect tool for that. It’s a blend of a qualitative method, watching sessions, through at a quantitative scale of sessions for every single user that’s ever interacted with a feature.”<\/p><\/blockquote>\n Applied to loading states: a three-second wait that everyone sits through patiently is a different problem from a three-second wait where 40% of users refresh the page. The timing number looks the same in both cases; the session recording<\/a> tells you whether the indicator is doing its job.<\/p>\n Once you’ve inventoried your loading state and examined the session data for each, run them through this decision tree:<\/p>\n The result will be a loading state that sets expectations, reassures users, and ushers them smoothly to the end of the process.<\/p>\n There’s a reason I don’t conduct audits using product data alone. A sharp drop-off at a specific step in a funnel often has two possible explanations: the loading state is confusing, or the process is genuinely broken.<\/p>\n Session replay distinguishes between the two. Loading state confusion looks like erratic clicking and scrolling; a broken process looks like stillness followed by a page reload or exit.<\/p>\n When confusion is the culprit, the fix is never a full re-engineering of the underlying process. Abrar Abutouq, one of our product managers at Userpilot, ran into exactly this when the funnel for a new feature showed a drop-off at a specific verification step. The process was working correctly; the indicator wasn’t communicating that it was.<\/p>\n In her words: “Within a few hours, I just created a targeting tooltip and showed it to users and highlighted the correct steps for them to make it clear what to do next. That helped a lot to reduce friction and support users in real time without involving our dev team.”<\/p>\n Finding that friction in the first place required product analytics<\/a> to flag the drop-off and session recordings to confirm what was happening during the wait. Neither tool alone would have surfaced both the problem and the direction for fixing it.<\/p>\n So, how do you build a better progress bar?<\/p>\n If you’re still asking that, you’re still asking the wrong question.<\/p>\n Instead, you want to ask: “How do I design waiting so users feel confident enough to stay?”<\/p>\n The answer to that question is subjective, but the most important factor is communication. Your indicator must communicate your process in a way that inspires trust and confidence.<\/p>\n If you’re ready to start building, Userpilot has all the tools you need. Our session replay provides the behavioral data you need to audit your existing loading state’s performance, and our flow builders and messaging tools enable you to communicate confidence to your users.<\/p>\n See how Userpilot works in practice<\/a>. Want to keep users engaged and satisfied even during long wait times? Discover the power of a progress bar and learn how to implement it effectively.<\/p>\n","protected":false},"author":68,"featured_media":639952,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[7568],"tags":[217,872,699,5690,316,536],"class_list":["post-12542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-in-app-messaging-guides","tag-in-app-guidance","tag-progress-bar","tag-ui-design","tag-ui-patterns","tag-user-engagement","tag-ux-design"],"acf":[],"yoast_head":"\n\n
![\"progress](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/PROGRE3.png\")
Why first impressions from a progress bar are almost impossible to undo<\/h3>\n
Your progress bar must deceive to impress<\/h3>\n
Does every wait need a progress bar?<\/h2>\n
![\"progress](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/PROGRE2-1.png\")
When you need nothing<\/h3>\n
When you need a spinner or skeleton screen<\/h3>\n
![\"Progress](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/03\/murals-progress-bar_f7a7d4d6c604fc6207a6481f79f0269a_800.png\")
When you need a determinate indicator<\/h3>\n
![\"percentage](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/03\/percentage-progress-bar_4710a7b77959eb2936e5d2bd02836706_800.png\")
When you need a “steps left” indicator<\/h3>\n
![\"slack's](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/05\/image_12fbfa4fa4886ac2a53adda297e313c5_800.png\")
\n
![\"checklist-activecampaign-progress-bar-ui-saas\"](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/02\/image_a2939284852b43cfd7ac8bcce105d617_800.png\")
How do you build and pace a progress bar?<\/h2>\n
When you can measure progress: Weigh the early progress more<\/h3>\n
When you can’t measure it: Pace the animation, not the number<\/h3>\n
The one thing that will always break trust: the frozen 99%<\/h3>\n
How do you audit your existing loading states?<\/h2>\n
Start with a loading state inventory<\/h3>\n
![\"userpilot's](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/03\/fe0dd2bf-8f40-442c-8e5a-08bf3e6ad7f7.gif\")
\n
Refine your loading state<\/h3>\n
![\"progress](\"https:\/\/blog-static.userpilot.com\/blog\/wp-content\/uploads\/2026\/06\/PROGRE4.png\")
A note of caution…<\/h3>\n
Build onboarding flows that keep users moving<\/h2>\n
\n
\n<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"