Add guidance for the "one thing per page" design principle

[humancompanion-usds]

Feature Request

• [x] I’ve searched for any related issues and avoided creating a duplicate issue.

This update is for:

• [ ] Content style guide
• [ ] Component
• [x] Pattern
• [ ] Utility
• [ ] Other

What is the name?

One thing per page is a design principle. Check suitability or Check eligibility is a pattern. Essentially, we need to document a replacement for the Wizard pattern.

What is the nature of this update?

• [ ] How to build this component/pattern
• [x] When to use this component/pattern
• [x] When to use something else
• [ ] Usability guidance
• [x] Accessibility
• [x] Implementation
• [x] Research insights
• [ ] Package information

What problem does this solve?

Progressive disclosure of form elements

Additional Context

Out in the world

• https://designnotes.blog.gov.uk/2015/07/03/one-thing-per-page/
• https://www.gov.uk/service-manual/design/form-structure#start-with-one-thing-per-page
• https://beta.ssa.gov/prepare/check-eligibility-for-benefits
• https://home.treasury.gov/policy-issues/coronavirus/assistance-for-state-local-and-tribal-governments/emergency-rental-assistance-program/service-design/application-web-sites

At VA

• https://dsva.slack.com/archives/C7NJWUA8K/p1648570003292579
• https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/appointments/va-online-scheduling/research/2021-request-clarification/Requests%20discovery%20-%20report.md
• https://va-scheduling.invisionapp.com/console/share/EW35S0RT8V/823651609
• https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/checkin/research/veteran-facing/mvp-usability/research-findings.md
• https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/checkin/research/veteran-facing/mvp-UAT/research-findings.md
• https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/checkin/research/veteran-facing/telephone/research-findings.md

[humancompanion-usds]

Steps to get to some usable patterns

• [x] Clean up the current Patterns > Form > Overview page
• [x] Create new pattern: Patterns > Form > Sub-task
• [ ] Replace Patterns > Benefit applications#E - G with a link to Sub-task
• [ ] Update Wizard to point to Sub-task

[k80bowman]

@caw310 Here is the draft page link: https://design.va.gov/patterns/forms/sub-task

In a comment on his PR, Matt asked that the following people review it and provide feedback in issue #1051:

• Natalie
• Sean
• Allison
• Josh Kim
• Peter Russo
• Kristen McConnell

Could you reach out to them and ask them to review the draft documentation please?

[caw310]

I've messaged those folks and asked them to share their feedback in this ticket.

[kristenmcconnell]

When reviewing the documentation, I got stuck on what the differences were between a "secondary task before a flow" and a "short task within a larger process." The definitions seemed comparable. The only difference that I saw was that "branching eligibility choices" may or may not be included.

I also wonder if the concept of "one thing per page" is somewhat separate from the sub task pattern. For instance, uk.gov has it as a design principle that applies to all forms, not just sub tasks. An example of this principle being utilized on a non-sub task form within VA is the debt team. They did a lot of work exploring how to improve some of their list loops. I guess list loops could be deemed a sub task. Anyway, they used "one thing per page" and completely changed the design.

Besides the above feedback, the documentation looks great.

[GnatalieH]

@kristenmcconnell I too got stuck on the differences between the "secondary task before a flow" and "short task within a larger process" definitions. I understood the differences once I thought more about it, but I'm wondering if we need to differentiate between these two concepts at all. Sub-task also is a term that hung me up, as I don't think it's describing what we're doing with this Pattern (but I haven't thought of a better term, yet). Essentially, we are chunking out step-wise content into easily digestible views. This creates a more conversational flow when a user is moving through task completion, agnostic to the task itself.

Edit: after doing some Googling, it seems like "One thing per page" is the language used by different organizations to describe this pattern. I feel like we shouldn't reinvent the wheel, rather we should use what the industry is already calling this pattern.

[outerpress]

Agree with Kristen - I'm not sure why a one-thing-per design principle would be limited to subtasks/pre-screener questions and not be similarly useful when thinking about a form flow. It'd be helpful to see the principle defined separately from the patterns, and explain why the pattern benefits from using the principle.

[humancompanion-usds]

@outerpress and @kristenmcconnell - If you can, come to Design System Council today at 1pm where we can discuss more.

[kristenmcconnell]

I'll be there.

[humancompanion-usds]

Feedback from DSC left some things unresolved. Next step here is for me to talk to Beth and Danielle about perhaps putting One Thing per Page into the Content style guide as a Content Principle. That follows how Pamela and other designers have been tackling this problem (starting content first, creating a decision tree/flow, then testing assumptions). That would also allow us to define it more than just linking to gov.uk and allow us to point multiple patterns at it. From there I believe I can clean-up sub-task to address the concerns raised above.

[joshkimux]

Just gave this a (late) review! Super excited to see this written up. Some minor bits of feedback:

• (a little unrelated) we may want to review guidance for the yes/no button pair. Specifically providing guidance that this is meant to be used for mobile specific (not desktop) flows as it doesn't remember the user's previous choice when navigating backwards in a flow. Using radio options along with a submit button is more materially honest from a semantic markup perspective as it correctly splits the selection ( input ) from submission ( button ).
• we may want to explicitly point out that a well designed sub-task pattern will have unique (not generic) h1s (as the examples do wonderfully)

Other than that, the subtask pattern by default should meet all of the a11y considerations (assuming all pages within the subtask have a button to submit information or trigger validation e.g. continue).