We have an application that various other departments will use to create questionnaires. These questionnaires can hide or show extra questions based on responses to previous questions.

When creating the questionnaires, authors may decide to display completion as a percentage or with a progress bar, with the progress bar working off of author-defined milestones.

Because of the dynamic nature of the questionnaire, we can't reliably know how many questions the user must answer. We have agreed it is bad to show negative progress, so for percentages we assume all questions will be shown and if we pass a group of questions that we will not show, the percentage may jump a significant amount (e.g. progress may move from 5%, to 10%, to 15%, then we skip a group of questions and end up at 70%).

Our progress bar looks something like this:

(O)===(O)===(X)---()---()---() or (O)===(O)===(O)===(O)===(X)---()

We aren't sure to handle the dynamic questions for this display. We have discussed a few options:

1) Only show the extra milestones once we know they are necessary. We don't like this, because we feel this is similar to reducing progress percentage -- suddenly the user is ambushed by extra work, or so it would seem.

2) Stop showing the milestones once we know they aren't necessary. This may result in, for example, a user going from step 3/8 to step 4/5. We are worried this may confuse users as it changes the number of apparent steps.

3) Show all the milestones, but simply skip ahead in the display. This may result in the user going from step 3/8 to 7/8. We are worried this ALSO may confuse users as they won't know why they have been moved forward or why they don't have access to those questions.

We are leaning towards option 3.

How should we best solve this problem? Are we on the right track with option 3, above? Is option 2 better and we just worry too much?

If we skip steps, as in option 3, should we differ how we display the skipped steps from how we display completed steps?

If it matters, the questionnaire authors will be typical office staff (not technically inclined) so we can't guarantee we can pass the problem off by training them to build questionnaires and choose milestones based on progress bar limitations. End users (people taking the questionnaires) must be assumed to be relatively uncomfortable with technology in general.

  • Progress bar has neither relevance nor much use in this case. What does user gain by knowing a transient parameter? I'd say this is not even as good as the download progress bar that dynamically recalculates based on transfer rate from time to time.
    – Kris
    Commented Sep 22, 2012 at 6:27
  • The idea is to be able to show the user that they are making progress -- our audience may be uncomfortable with technology, so we want to be able to encourage them that they are making progress through the task we are asking of them. We also don't want to just dump numbers on them, especially considering how often those numbers might change in response to their actions.
    – PeterL
    Commented Sep 24, 2012 at 13:01
  • A spinning icon does that much better without complications. Just make sure it really spins only when there is progress.
    – Kris
    Commented Sep 24, 2012 at 13:07
  • I guess I should phrase "show the user that they are making progress" as "show the user they are closer to being done". Ideally they will figure out that as they answer questions or advance pages in the questionnaire that something has happened -- I'm not sure what a spinner adds in this case, other than a delay between when they answer some questions and are presented with more.
    – PeterL
    Commented Sep 24, 2012 at 13:13
  • My point that you missed was that a spinner is an endless loop, unlike a linear progress bar -- it reflects realistically rather than giving a false sense of completion.
    – Kris
    Commented Sep 24, 2012 at 13:22

2 Answers 2


You try to combine linear and measurable progress with non-linear process, that is the problem. So there is no ideal solution.

Version 3 is the best among specified, but you may also try another way, that can minimize the problem of omitted steps, but hide info about them. The goal of progress bar is to show, that there is a progress, and that the end is relatively getting closer and closer (that the end is reachable). Adding extra information about non-linear nature of questionnaire can be rather uncommon and confusing. So you can simply avoid in version 3 any numbers and just display the line moving forward every step:


download bmml source – Wireframes created with Balsamiq Mockups

Where light green piece of bar flashes when user chooses option and goes to the next question and fades away to dark green. It will display that you are moving forward (sometimes faster, sometimes slower, but abscence of number will decrease the problem of "why it happens?"), and that the finish is closer.

  • 2
    Accepting this as answer for "You try to combine linear and measurable progress with non-linear process, that is the problem. So there is no ideal solution." Thank you for the alternative you have proposed as well.
    – PeterL
    Commented Sep 5, 2012 at 13:47

Of the 3 options, #3 sounds like the least confusing to a user.

However, the implication of steps is that there are distinct number of forward movements. Skipping steps might confuse users. One thought is to display percentage complete of the maximum number of steps (instead of displaying steps at all). This way the user is completely unaware of the number of steps and only sees an increasing number towards completion.

  • Thank you for the suggestion of not displaying the exact count to the users. It seems there is no good way to do a more informative display without adding potential confusion
    – PeterL
    Commented Sep 5, 2012 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.