Figma progress indicator components

Every upload, import, and onboarding checklist eventually needs a bar. Progress indicators turn up in file uploaders, storage meters sitting at 84% full on a dashboard, profile completion prompts, and the export dialog nobody wants to sit through.

The job sounds trivial: show how much is done. Doing it honestly is the part that takes judgement.

A bar is a promise that you can count

Use a bar when you know the denominator. Bytes uploaded, rows imported, steps finished, seats used: all countable, all fair game.

Nielsen Norman Group's research on progress indicators puts the useful threshold at around ten seconds, past which people want a number rather than motion for its own sake. If the work genuinely cannot be measured, reach for a loading indicator instead. A bar that crawls to 90% and parks there is worse than no bar at all, because it spends trust you will need later.

Eleven positions, five label treatments

Progress is a variant property here, stepping from 0% to 100% in tens, so filling a bar in a mockup means switching variants rather than nudging a rectangle by hand. The track sits 8px tall and 320px wide before Auto Layout stretches it into whatever card you drop it into.

Labels are the second property, with the percentage placed to the right of the track, below it, floating above the filled end, floating below the filled end, or removed entirely. The floating pair is the interesting one: a number that travels with the fill gets read faster than one parked at the end of the row, and it keeps a 320px bar to a single line.

Filling the bar in a prototype

Because each percentage is its own variant, an animated fill is a short chain of "change to" interactions with smart animate interpolating the width between them. Trigger those on "after delay" and the bar fills by itself while you record a walkthrough, which is enough for a demo and considerably less work than a plugin.

Keep the easing linear. Progress is not a spring, and a bar that eases into every tenth reads like a toy.

The label choice matters more in a prototype than it does in a still frame. A percentage parked to the right of the track stays in one place while the fill moves, which is easier to read at a glance and easier to test with.

A floating label moves with the fill and looks better in a screenshot. Pick one per product and apply it everywhere, because the two together in the same view make one bar look broken.

Progress that survives without the picture

The fill carries the whole message visually and none of it otherwise. In code the same bar takes role="progressbar" with a value that updates as the number moves, and MDN's reference for the role is blunt about the indeterminate case: leave the value off rather than invent one.

Decide what happens at 100% too. A notification confirming the import finished is kinder than a bar that quietly vanishes and leaves someone guessing. For the radial version of the same numbers, progress circles share this file, and flows made of discrete stages want progress steps instead.

When it's time to build, the same bars exist in code. Untitled UI React progress indicators are open source, built with Tailwind CSS and React Aria, with the value, the label, and the screen reader announcement wired together for you.