Progress bar - Segmented - Does not handle complex forms

[humancompanion-usds]

Description

The Progress bar - Segmented component is limited in the scope of form flows that it can accurately reflect. There are multiple rounds of research that detail user expectations that the progress bar should increment on each page. That doesn't happen when:

1. The form is dynamic in nature and adds or subtracts steps based on responses from users.
2. The number of steps is greater than 13, which is the max number the component can reflect.

Therefore VFS teams need to do some discovery to determine the path forward and answer the following questions. Here are two potential paths to explore:

1. What if we were to take the progress bar away entirely?
2. What if the progress bar were more an activity measurement and reflected a % done rather than specific steps?

For both of those we'd need to evaluate the following:

• Do users miss it or miss understand what it represents?
• Do they lose context and fail to understand where they are in the proces?
• Does the lack of a progress bar, or a different progress bar, hinder their ability to complete the task at hand?

Details

GDS research indicates that removal of the progress indicator might actually be just fine. Their current guidance advises:

Only include the total number of questions if you can do so reliably. As the user moves through the form, make sure the indicator updates to tell them which question they are on and the total number remaining.

I cite them only to give credence to the notion of removing the progress indicator component from the design and testing that out. But there is a big caveat here that if the form is simple enough to not need one then our current component likely works OK there and while removing the indicator might help, it isn't the problem we're trying to solve here of handling more complex forms. Also, the recommendation there is to use a simple question or step indicator in text:

That would solve the "more than 13 steps problem" but not the "steps are added and subtracted" problem as the count would still change, which users very much seem to notice and resent.

Solutions to other problems

There are a number of related problems that are not this specific design gap and thus won't be explored as part of this work:

1. Steps can be completed in any order. If steps can be completed in any order our current guidance is to consider the Master/Detail screen pattern and provide status as to when each section is complete and when the overall process is complete. There is also a lovely pattern from GDS that addresses this, which I believe a team is testing out on a more complex form.

Process details

This is a design gap ticket. Thus it is an identified issue in a component or pattern that needs a solution. The solution can come about in 1 of 2 ways:

The Design System team can propose a solution and find a VFS team to test the solution. OR A VFS team can propose a solution, file an experimental request and mention this issue in that new one, and then go off and test the solution. Once the solution is tested, the team that conducted the testing should come to Design System Council to review the results.

Acceptance Criteria

• [ ] The Design System contains guidance that advises VFS teams when, and when not, to use a progress indicator.
• [ ] If necessary, the Design System contains one or more components and patterns that VFS teams can use to implement the guidance above.

[humancompanion-usds]

Issue 70094 is a variation on this theme.

[tygindraux]

@humancompanion-usds – I'm following up on a conversation we had back in March. We've now tested a progress bar (A/B tested, without any progress indicator or with a % complete bar).

• Findings report
• Prototype's are linked in the research plan

Here's some highlights, responding to considerations you've listed above:

Do users miss it or miss understand what it represents?

• We consistently found that users pointed out the progress bar, without any prompting from us.
• This is likely due to the fact that we made the bar orange, to standout from "all the blue."
• It was actually rare for people to misunderstand what it represents, but it did (sort of) happen once:

  "So, what does this 5% mean? Am I not going to get my question in if I'm not at a hundred percent?"

Do they lose context and fail to understand where they are in the process?

• Ultimately, people want more information than we can give them. They're hoping it will say step X of X. Which is, unfortunately, something we can't clearly articulate in a form with many branches.
• So, the % complete doesn't give them all the context they want.
• That being said, it helped them understand that they needed to keep going in the form.
• One user, who tested a prototype without a progress bar, thought the form was over before they actually got to the review and submit page. They were missing context and failed to understand where they were:

  "[At the end] I would be congratulating myself on actually following through and clicking all of the buttons afterwards. Otherwise I likely wouldn't have submitted it, [but would have] thought that I submitted it [on the question page]."

Does the lack of a progress bar, or a different progress bar, hinder their ability to complete the task at hand?

• Without the progress bar, we saw users were confused about whether they were finished. People mentioned (without prompting) wishing there was a way for them to know how much longer they have left.
• At first, people found the progress bar daunting:

  "My first reaction to this [is], 'Oh my god! I'm only 5% complete with this process.' [...] I have a long way to get an answer to this question."

• The progress bar helped motivate folks, especially as they got further into the form:

  "I think if there's no indication, I'm going to get frustrated, because it was already more screens than I was expecting to go through. [... I need to] know that I'm moving towards the end."

"It's kind of surprising in the beginning, but in hindsight I guess it's good to know how far along you are."

Based on your process details, above, it sounds like we should have filed an experimental request before we did research... At this point, should we go ahead and: "propose a solution, file an experimental request and mention this issue in that new one, ~and then go off and test the solution~. Once the solution is tested, the team that conducted the testing should come to Design System Council to review the results."

From our team, we're hoping the next step could be to build this and test again with assistive tech users. We want to confirm whether it should the first element in focus or the question heading would make more sense (for one thing).

Let me know your thoughts on our next steps.

[humancompanion-usds]

@tygindraux - Thanks for the update. You should file an experimental request, point to this issue, come to DSC. Building and testing again with assistive tech users sounds like a great first step to me, but I'm just one voice on the Design System Council and others should weigh in. Having the research results to look at is very helpful and I'm very happy to hear about your progress here! Sharing that progress at DSC is important so folks can know what we've tried and where we may be headed on this. Thanks again!

[humancompanion-usds]

Presentation

Thomas: The default design falls short when doing some forms.

After testing we found out that #1 the order of questions didn’t make sense so we moved things around. There was a challenge creating “chapters”. Covering 18 business lines (health care, banking, etc). Conditionals for personal info…since there are numerous questions the progress doesn’t get update with the segmented updates

Research says users were confused about “complete” so added verbiage “complete with form”.

Updated with colors. The color stands out since it’s orange from the blue everything else on the page.

User feedback

Helps to end confusion from users about the number of questions and/or sections to complete.

DSC discussion

Allison Christman: Have you thought about showing the sections with titles along with the percentage? Thomas: that was explored

Not able to be divided into nice neat chapters on some forms.

Robin Garrison: We have a form that allows you to add up to a 100 items on a page, then follow up on each of those additions. How would that show progress in this design?

Some edge case forms make it so that as user progresses that the change in % is 1 or less each time due to the large # of questions.

Some users wanted some sort of indication of where in the form they were so the progress bar was useful as an indicator that they were moving forward.

Tyler: Parts of the form are not intuitive so the progress bar helped to let users know how far they are to completing the form.

Ray: Would we be able to describe the progress bar in terms of total fields/questions/pages in stead of percentages?

Matthew: Because of the conditional nature of some forms questions can get added so the % would change and the total number goes up. The progress bar should always go forward and never backward. This is close to an activity bar (for an upload/download of a file). So this pattern is more about steps, but conveying a % of completion. It reflects to the user that they are making progress but not yet done. In guidance there would be help to differentiate between use of this component and the activity bar.

Ryan: This has been a persistent issue in the for a while and this is the 1 instance that a paper form is superior so you can “see” what’s in front of you to finish. I think the problem here to solve is 1. “users don’t know the length of the form before they start to complete it.” People are comfortable with the pizza delivery part or fedex. The user knows that there is an indeterminate amount of time from jump of 1 section to the next. It could be 20 min for a pizza delivery, could be 5 days for fedex. Is this the right problem to solve? Is this the right solution? Maybe disclaimer at the beginning to let them know what they’re in for.

Matthew: I don’t think we’re quite done here. But in the intro page we include a time estimate. But it’s for the paper form from OMB, not the digital one. There is an online tool that rate PDFs and realistic time. Our forms are in the hours, not 25 min. I agree Ryan we should do more for the user to know the expectation. And that could be discouraging as an unintended side effect. It could be discouraging to the user. Maybe we tell users how many forms, how many questions, or some sort of transparency

Ryan: Maybe we need to reformulate how we calculate the time for a form. For healthcare, you have to fill out dependent info. If you have 6 kids that will take a long time.

Matthew: That’s interesting. We haven’t figured out the calculation for % done

DK: If some ppl don’t have the conditionals questions that would speed up, not slow down and be encouraging to the user. Progress bar mark up sound right to me and in the right direction. I like how you’ve designed it more compact and no heading. Makes this easier for one H1 per page, does away with the H2 for the progress bar.

Thomas: Colors. Used orange to stand out?

DK: For guidance, it would help to really be specific on when to use which (progress bar vs this component).

Final Decision

Add to DS as a Use with caution: Candidate component.