Experimental Design [Simple Form Header]

[joshkimux]

What

I'd like to re-propose conducting more research on simplifying the form header for forms that use one thing per page (e.g. the subtask pattern). This is directly based on the work that Ryan Thurlwell documented in this sketch file.

Some possibilities may include:

• Deleting the progress bar and "step x out of y" heading on short forms
• Replacing the progress bar with sections or a task list pattern on long forms
• Placing the form's name in the header, not the h1 (which redundantly consumes up a large amount of space on mobile)
• Placing "back" at the top of the page (styled as a link) instead of a button at the bottom of the page so (a) users don't need to scroll to go backwards and (b) buttons don't cluster at the bottom. Gov uk has guidance here and a research thread here which calls out potential a11y issues of it being missed by screen reader users. We should enlist the help of a11y specialists to explore this.

Possible explorations for illustration purposes only, not meant as actual UI design suggestions

Purpose

The key purpose here is to reduce the amount of redundant or unnecessary content above the fold. In recent studies, we've observed that:

• some sighted Veterans are confused by repetitive content in forms as the h1 and step heading may repeat for several pages in a row
• screen reader users are disorientated by repetitive h1s as the h1 is meant to be a unique description of the current page (not a summary of an overall flow e.g. a form title)
• for Veterans with low vision who use magnification on mobile devices, questions can be hidden below the fold completely

Usage

This should be experimented with specifically with forms that use one thing per page end to end first.

Behavior

n/a

Examples

Ryan Thurlwell's proposed form changes; note, we should focus more on the intent and less on the UI design (the latter which needs to be explored more).

Accessibility

Research from gov uk implies that placing the back link at the top of the form (as opposed to the bottom) may help some users with cognitive disabilities while also making navigation more difficult for some screen reader users. We should have our own a11y specialists look into this more.

Guidance

--

Research (optional)

Recent studies around one thing per page have been conducted by folk like @thehastingsp

Code (optional)

Gov uk has code we can reference

Next steps

You may present your work to the Design System Council at an upcoming meeting. If you do not or cannot attend the Design Council Meeting, you can opt to get an asynchronous approval.

Submit requests to join an upcoming Design System Council meeting in #platform-design-system.

During the meeting, the Design System Council Working Group will evaluate the request and make a decision.

If your request is approved, you can add your component or pattern to the system. If you have any questions on how to add your component or pattern to the system, please reach out to the Design System Team at #platform-design-system.

[humancompanion-usds]

@joshkimux - @benbrasso-agile6 came to talk to me about testing this out recently. Thus the Patient Check-in team is already working towards this. I gave them feedback on both and encouraged them to go test and then contribute. Once they've designed and tested a reduced header and footer then I would definitely love to see those come to DSC. If you and that team want to bring that to DSC ahead of their test for feedback then that is, of course, welcome but not required.

[humancompanion-usds]

Here is the issue from Ben: #1339

[humancompanion-usds]

A PR has been created to add the first minimal header variation to the Design System:
#1425

This first variation does not support signing in nor accessing the menu. But it's a start. We decided in DSC last week that we'd add this first variation to the system.

[mnorthuis]

Dropping some data here for reference. Across all pages of the 526 flow, in the last 3 months, the breadcrumb was clicked 120,286 times. Most of those clicks are on the /start, /introduction, and /confirmation pages, but there is a small amount of utilization across other internal pages. I have not looked at other forms, but can pull more data if helpful.

In the process of analyzing this change, and in any research done, it would be beneficial to understand when and why someone uses the breadcrumb on those pages. It may also be helpful to consider when we show a breadcrumb (start pages and confirmation page) versus the back button.

My main focus/concern on this change, is making sure that the user has a way to exit the form back into benefit experience that they are in - just having a back option would require several clicks to get out of the form and back to the start, and clicking on the logo to go to the home page would take them completely out of their task flow.

It's a balance of providing them with options for "I need to back up a step or two", "I need exit this form for a moment", and "I need to stop and come back at a later day/time". Plus other scenarios, maybe?

Home segment - 44,535
Disability benefits segment - 75,751

[eileen-coforma]

This would require some more research, but I believe that within the form application itself, the breadcrumb isn't used anymore because there is a more direct option to 'Finish this application later' which gives the Veteran an extra sense of security to leave the form.

Because of that exit option within the form, the breadcrumb isn't as pertinent within the application itself. That may explain why it's used more either in the beginning of the form or after the form has been submitted.

[mnorthuis]

Based on analytics provided above, the data on the 526 shows it is being used within the form, although lower amounts.

[joshkimux]

@mnorthuis just read these concerns and I absolutely agree that alternatives should be provided to the breadcrumb's functionality if removed. Some of the concepts I was exploring above included provided links directly within the header (where the form name would be), making this a true sub-task kinda flow.

I'm sure with more design iterations we can get this right. As @eileen-coforma pointed out, "Finish this application" among others could be paths forward. Super super excited to see where we can go with this.

[mnorthuis]

@joshkimux Although this "back" link looks like its in place of the breadcrumb, is it actually placed where the breadcrumb would be within the code, or is it more connected to main content of the page and not tagged as "breadcrumb" - like our component likely should be? Wondering how screen readers pick this up or find this when navigating the page.

Also curious what this looks like on desktop. On mobile it looks like a direct replacement of the breadcrumb, but is that the case on desktop? It would well above and off to the left on desktop, which could create issues for zoom users, or it just may not be in proximity to the main content area enough to make that cognitive connection.

Last question, would this mean that "back" navigation would be at the top of the screen as a link, and the "continue" navigation would be a button at the bottom of the screen? Are we planning to test that as well?

cc @humancompanion-usds

[joshkimux]

is it actually placed where the breadcrumb would be within the code, or is it more connected to main content of the page and not tagged as "breadcrumb" - like our component likely should be?

This is a great question. For added context, this isn't meant to be an immediate fix so much as a proposal to redesign the larger form experience.

• I don't think we can simply remove the current back button and convert it into a link with our existing form pattern
• I do think we can accomplish this if we found alternative mechanisms and/or content to replace the need for the breadcrumb, which may vary depending on if it is a short vs. long form

Also curious what this looks like on desktop. On mobile it looks like a direct replacement of the breadcrumb, but is that the case on desktop? It would well above and off to the left on desktop, which could create issues for zoom users, or it just may not be in proximity to the main content area enough to make that cognitive connection.

This would look the same on desktop, and references the gov.uk pattern.

I'd hypothesize this wouldn't create issues for zoom users as content located on the top left margin of the page will tend to be seen (issues are more likely to arise for stuff like our feedback button which is randomly out to the right side bottom of our pages).

However, I agree that it's unclear if a clear cognitive connection could be drawn given:

• we've always had back next to continue and
• back stripped away from the context of continue may be awkward

I think it's worth testing, and we can learn alot from gov.uk's conversations on the topic..

The arguments for a back link include it's

• in a similar place to where most browsers put the browser back button
• most likely to be needed soon after the user lands on a page that looks wrong or if the user wants to check what they just entered
• probably not needed once the user fills out the form—if they fill out the form and click back, they will lose their answers
• This approach clearly differentiates the back button from the primary button which should decrease the time it takes users to proceed. And it makes room for additional buttons when needed which I’ll cover later.

Last question, would this mean that "back" navigation would be at the top of the screen as a link, and the "continue" navigation would be a button at the bottom of the screen? Are we planning to test that as well?

We should absolutely test this. I have curiosities on how well it would (or would not) work with screen reader users. Particularly if it is above the h1 it may be skipped over immediately. On the flip side, I don't think I've ever seen our current back button ever been tested with screen reader users. I don't think I've seen anyone use it in studies so far, or if a study has been conducted to stress test it.

[laflannery]

I am currently working through the subtask pattern on a new form with my team and I wanted to mention another item that we don't see specifically called out here but it is something that should be done so I am recommending that it get clearly documented for this pattern:

For each screen/page in the subtask pattern, the <title> must be unique and ideally match the H1 of the page. We would expect, in this case, for the <title> to follow the pattern {H1} | {Form name} | Veterans Affairs

[humancompanion-usds]

Header - Minimal is available: https://design.va.gov/components/header/header-minimal

If your team is interested in using it reach out in #platform-design-system.

[benbrasso-agile6]

Check In has a spike to review it next sprint, thanks