The progress bar is one of the most trusted elements in modern software.
It is also, frequently, a fiction.
Anyone who has installed or launched an application on a computer, mobile device, or game console, would have encountered a loading bar, whether horizontal, circular or with a quirkier design. In principle, they are made to inform users about the progress of an action that the computer system is doing. They provide the user with visibility of system status, one of the ten Usability Heuristics for UI Design, as defined by the Nielsen Norman Group, a UX research and training firm.
Yet, there is a particular kind of quiet dread that users of a certain age will recognise, a software installer ticking smoothly from 0% to 99%, then freezing. You wait for a minute, two, five, assuming things are still happening in the background. Then, without explanation, it lurches to 100% and declares itself done. What happened in that gap?
In many cases, this is a deliberate design decision. One that sits at the precise intersection of engineering honesty, human psychology, and the ethics of user experience. The progress bar, it turns out, has always been less about measuring progress and more about managing anxiety. And the more sophisticated our software becomes, the more sophisticated its deceptions grow.
A Bar is Born
How did we begin graphically representing the passage of time? Henry Gantt’s project charts from the early 1910s used horizontal bars to represent workflow against time, however the digital progress indicator emerged at a more specific moment in computing history.
The first graphical progress bar appeared in Mitchell Model’s 1979 PhD thesis, Monitoring System Behaviour in a Complex Computational Environment, written at Xerox PARC, a research powerhouse. It was an engineering artefact for observing system behaviour. Six years later, it made its way into shaping user experience.
Brad Myers, a graduate student, presented a paper in 1985 on the importance of percent-done progress indicators. His theory was that progress bars made computer users less anxious and more efficient. He represented this in the form of a capsule that filled from left to right, and asked students to run computer searches with and without the bar. The results were clear.
Users who saw a progress bar rated the computer as faster, more reliable, and more trustworthy than those who saw nothing, even when the actual wait time was exactly the same. Those who saw nothing frequently attempted to interrupt the task, restart the computer, or abandon the operation entirely.
But the most consequential finding was a footnote that would quietly authorise decades of designer behaviour. “People didn’t mind so much if it was inaccurate,” Myers noted. “They still preferred the progress bar to not having anything at all.” 86% of his participants liked the bars. Designers now had academic cover to show users progress bars that weren’t telling the whole truth.
Informing Users or Just Buying Time?
To understand why progress bars are so often deceptive, we must first understand why accurate ones are so hard to build.
A genuine percent-done indicator requires the system to know, at any given moment, how much work has been completed relative to the total. In practice, this is fiendishly difficult. Let’s take the example of a software installer unpacking files: it might know how many files there are, but not that one of them is 40 times larger than the rest, or that writing to the Windows registry, takes as long as all the other steps combined. This is why baffled users frequently notice a progress bar galloping to 90% in thirty seconds before stalling for two minutes.
So engineers have to make choices, by estimating, animating, and smoothing curves. Loading bars were often designed to move slowly at the beginning, so the user would think the process would take longer, then accelerate toward the end so users would feel positive about finishing earlier than expected. This trick is applied in real world queues, such as theme parks: if you overestimate the wait and underdeliver on time, the customer leaves happy.
A common design technique today is to use a simple indeterminate spinner, such as a rotating circle with no percentage, and then switch to a fake determinate progress bar to give the appearance of measurable progress. The spinner tells the user that “something is happening.” The bar says “we’re nearly there.” Neither necessarily knows what it’s talking about.
The Science of Waiting
it is no secret that human perception of time is wildly unreliable. Research shows that people tend to overestimate passive waiting by a significant margin, which is frustrating but also significant from a commercial perspective. Every second a user spends staring at a blank screen is a second in which they might close the tab, abandon the basket, or lose confidence in a product.
More research reveals that the way a progress bar moves matters as much as the fact that it moves at all. In a landmark 2010 study, Chris Harrison, Zhiquan Yeo, and Scott Hudson at Carnegie Mellon University, tested some visual augmentations to progress bars. Specifically, a ribbed or striped pattern moving backwards against the direction of progress. The experimental design reduced perceived duration by approximately 11%. Though the bar wasn’t moving faster, the eye was being tricked into perceiving it was, by creating an optical illusion of motion flowing in the opposite direction to fill.
Similarly, a progress bar moving faster at the beginning and slowing toward the end is perceived as quicker than a constant-speed bar, even when the total time is identical.
There is also an asymmetry in how we experience the beginning versus end of waiting: waiting to start a task feels longer than waiting for it to finish. This is why skeleton screens, the ghosted placeholder layouts which have gained in popularity over the years across websites and mobile apps, feel so effective. They signal that something has already begun, converting the user from someone waiting for a process to start into someone waiting for it to conclude. The wait is the same, but the psychology is not.
Studies comparing different types of loading screens have found that participants prefer interactive animations during medium and long waiting times, owing to their ability to divert attention and provide a simple task to perform during the wait. One example can be seen in some video game loading screens, which display game tips and facts, keeping the front of the mind occupied so the back of the mind does not fixate on the passage of time.
The UX Paradox
Jakob Nielsen’s first usability heuristic, formulated in the early 1990s, states that the design should always keep users informed about what is going on, through appropriate feedback within a reasonable time. This principle is about communication and transparency, as people strive for predictability and control, and in most cases, more information translates to better decision-making.
A fake progress bar passes this test by the narrowest of margins. It does communicate that something is happening, while betraying its spirit. The user is informed that a process is underway, but they are not informed how far along it actually is, or whether it has stalled. A fake progress bar completely fails to report when the process has stalled or failed, leaving the user with a false expectation. The 99% problem is then both irritating, and a violation of trust.
Some designers have attempted to resolve this tension with what might be called the “benevolent deception” framework. If a fake animation makes users stay, and no animation causes them to leave frustrated, then the fake animation is, realistically, a good outcome. This placebo effect can be compared to the pedestrian crosswalk buttons: many of these buttons do nothing when pressed, yet pressing them increases patience at the crossing, because it creates a sense of agency. The system is, in effect, lying, but only to provide a better outcome for everyone.
Progress, Reloaded
Today’s loading experiences span a spectrum from the bluntly honest to the elaborately theatrical.
At one end sit determinate bars, those that reflect genuine, measurable progress, tied to real back-end telemetry. These are ethical but technically demanding: when a file upload reaches 67%, it genuinely is 67% done. At the other end sit indeterminate spinners, which make no claims at all: they signal activity without promising any particular timeline, and are appropriate when the system genuinely cannot predict duration.
Between these poles lies the vast middle ground of modern UX: skeleton screens, which have largely replaced the blank white page of the early web and proven to reduce perceived load times; step-progress indicators which break a long process into labelled stages (“Uploading”, “Processing”, “Finalising”) so users experience multiple small completions rather than one long wait; and what might be called “narrative loaders”, the animated interludes that tell users what the system is doing in plain language while it does it, similar to a command line interface.
The principle of optimistic UI represents perhaps the most sophisticated version of progress management: allowing users to proceed with next steps while a background process continues, shifting them from passive to active waiting. When you post on social media and it appears in your timeline instantly, before the server has confirmed receipt, that is optimistic UI. The interface is betting on success and shows you the outcome in advance. In the rare event something fails, it quietly rolls back.
Each of these approaches reflects a different answer to the same question: what do users actually need from a progress indicator? The research is consistent on one point: users sometimes prefer a longer waiting time with information over a faster process with a bland progress bar, because they know what to expect. Transparency, even about slowness, builds trust in a way that choreographed optimism cannot.
The Ethics of the Empty Bar
If there is a lesson in four decades of progress bar psychology, it may be this: the problem with fake loading bars is not that they deceive users in the moment. It is that they erode the user’s model of the system over time.
A bar that moves at a constant rate from 0% to 100% was rated as acceptable even when the underlying task progressed unevenly, but that finding was made in 1985, with users who had no accumulated experience of bars that lie. Today’s users are wiser. They have watched too many bars stall at 99%, seen too many “estimated time remaining” figures jump from two minutes to forty seconds to twelve minutes and back again, to place unconditional faith in the format.
In a way, this accumulated scepticism is a UX debt charged to the entire industry by decades of well-intentioned but imprecise feedback. The designer who makes the choice of deploying a fake determinate bar today is making a small withdrawal from a shared account of user trust.
The wiser approach and, increasingly, the one that design systems are converging on, is to be honest about uncertainty while still being present and communicative. An indeterminate animation that says “this can take a minute or two” is telling the truth. A bar that confidently tracks to 100% and hangs at 97% is not.
Myers proved in 1985 that humans need the illusion of progress. That finding has not changed. But there is a difference between offering users a reassuring signal that work is underway and constructing an elaborate fiction about how much of it is done. The first is good design. The second is a confidence trick, one that keeps working right up until the moment it doesn’t.