Pattern proposal: Help users to... Know when their information is prefilled #6053

bellepx0 · 2024-09-10T18:16:42Z

bellepx0
Sep 10, 2024

Component name

Prefill pattern

Component description

This prefill pattern addresses the challenge of effectively managing prefilled data in forms for logged-in Veterans. Currently, when Veterans access forms, they frequently encounter prefilled information derived from their authenticated profiles. However, they often face confusion regarding the source of this data, how to edit it, and the impact of those edits. To enhance the efficiency and accuracy of completing forms, Veterans need a clear and consistent way for understanding and managing prefilled data. This will help them save time, minimize errors, and navigate the benefits or services application process more smoothly.

Additional context

User research is currently being conducted and some design decisions are still pending. For instance, the choice between using Card or Address components for presenting locked and unlockable data formats has not yet been finalized. We will update the proposal with the final design decisions once our research and analysis are complete.

Design files: Figma

Why USWDS needs this component

The addition of a prefill pattern to the USWDS is essential for enhancing the efficiency and user experience of filling out government forms. Government agencies frequently require users to complete a variety of forms, from tax filings to benefit applications. The prefill pattern addresses several key challenges and aligns with federal laws and guidance on user-centric design.

Key Interactions and Current Gaps

Efficient data entry: Users often encounter redundancy when filling out forms with repetitive information. This can lead to frustration and errors, ultimately resulting in a poor user experience. By incorporating a prefill pattern, the USWDS can streamline the form-filling process, allowing for automatic population of fields based on previously entered data or known user information.
Consistency across agencies: Different federal agencies use varying form formats leading to inconsistency and confusion for users. A standardized prefill pattern within USWDS will promote uniformity, ensuring a consistent user experience across various government platforms.
Reduction of errors: Manually re-entering data increases the risk of errors and incomplete submissions. Prefill functionality reduces these risks by leveraging existing data to minimize user input and improve form accuracy.

Problems The Prefill Pattern Solves

Streamlining user experience: The prefill pattern reduces the time and effort required for users to complete forms by automatically filling in known user information. This enhancement will lead to a more efficient and user-friendly process, improving overall satisfaction with government services.
Reducing redundancy: Users often have to provide similar information across multiple forms within the same government agency. By using prefilled data from within the agency’s own system/database, the prefill pattern minimizes the need for users to re-enter information that has already been provided. This approach reduces duplication and streamlines the form-filling process, making interactions more efficient and cohesive within the agency’s application/website.
Supporting accessibility: Prefill patterns contribute to accessibility by reducing cognitive load and simplifying data entry tasks. This would be beneficial for users with disabilities who may find repetitive data entry challenging.

Alignment with Federal Laws, Guidance, and Policies

Section 508: The prefill pattern enhances accessibility by simplifying the form completion process, making it easier for users with disabilities to interact with digital forms.
The U.S. Digital Services Playbook: The playbook emphasizes the importance of user-centered design and iterating based on user feedback. The prefill pattern aligns with these principles by addressing user pain points and improving the overall digital experience.

How the component works

This prefill pattern will include the following components and content:

Alerts
- Unauthenticated alert
- Authenticated alert
- Prefilled info alert
- Success alerts that state where the updated info is saved
Contact/personal information block or Card variations (including locked and editable states)
Buttons with language that confirms where the user is saving their updated info to (e.g., “Save to profile”)
Directions for updating profile data
Instructions for calling/linking to edit

For unauthenticated users:

They will see an unauthenticated alert at the top of the form informing them to sign in to update their information online.

Once signed in, before they begin the form, users will see an alert stating “Note: Since you’re signed in to your account, we can prefill part of your form based on your account details. You can also save your form in progress and come back later to finish filling it out.”

Within the form:

Users will be shown a locked view of certain data (e.g., SSN, DOB) that is not editable on the website. This view consists of the contact information block shown below.
A note below the locked data will explain how to update their information.

When users get to an edit page:

An alert at the top informing users, “We've prefilled some of your information from your account. If you need to correct anything, you can select edit below.”
A note at the top informing the user where their changes will be saved. For example, “Note: Any updates you make here will only be reflected in this form.”
An unlockable view of their data (e.g., mailing address) which will also have an Edit link. This view consists of the contact information block shown below.

When the user clicks on the Edit link:

They will be taken to an edit page displaying their prefilled data within the form fields. OR
The user will see their previously provided data in a locked format (Card component) and the form fields will NOT be prefilled.

Once a user updates their info:

A success alert will appear with language that confirms that their update was successful and their changes have either been saved to their VA.gov profile or only to this form.

Describe alternatives you've considered

For the following steps below, an alternative to using the contact information block is using the Card component as shown below.

a) Within the form:

Users will be shown a locked view of certain data (e.g., SSN, DOB) that is not editable on the website. There will also be a note below the locked data which will explain how to update their information.

b) When users get to an edit page:

An unlockable view of their data (e.g., mailing address) which will also have an Edit link.

c) When the user clicks on the Edit link:

They will be taken to an edit page where they will see their previously provided data in a locked format (Card component) and the form fields will NOT be prefilled.

Real-world examples

Currently, VA.gov has a Prefill component implemented, but there is no standardized prefill pattern in place.

When to use this component and when to consider something else

When to use this pattern

You need to display and manage prefilled data in forms for logged-in Veterans. The pattern is designed to handle the complexities of showing, editing, and updating prefilled information from authenticated user profiles.
You aim to ensure consistency in how prefilled data is handled across various VA.gov applications. This pattern will help standardize the approach to displaying and editing prefilled information.

When to consider something else

The form or application does not involve authenticated users or does not need to display or manage prefilled data based on user profiles. The pattern specifically addresses scenarios where data is prefilled from a logged-in user’s profile.
The form or application only requires simple data entry without prefilled information or does not involve complex data editing scenarios. If the form does not need to handle prefilled data or provide editing functionality, the pattern may not be necessary.
The form relies on data that is not sourced from authenticated user profiles.

Usability considerations

No response

Accessibility considerations

No response

Who’s involved

VA Authenticated Experience Design Pattern team

Adam Whitlock @adamwhitlock1 - Engineering Lead
Belle Poopongpanit @bellepx0 - Engineer
Christine Rose Steiffer @ChristineRoseSteiffer - Design Lead
Lynn Stahl @msbtterswrth - Product Manager
Becky Phung @beckyphung - Product Owner

MathiasaurusRex · 2024-09-16T18:41:17Z

MathiasaurusRex
Sep 16, 2024

+1

Think this would be great for a lot of different people and help give them more information and power to resolve issues with the underlying data.

A use case that pops up would be when data is coming from two sources. For example:

A person filling out information on behalf of someone else (A child filling out on behalf of a parent)
Subcontractors who may be working for multiple organizations (A billing specialist who works on behalf of multiple providers)

Having some design guidance around how to clearly show multiple sources and how it prefills, and how to resolve with multiple sources would help reduce burden.

0 replies

bellepx0 · 2024-10-17T14:20:21Z

bellepx0
Oct 17, 2024
Author

UPDATE:

We have successfully completed our Prefill research study and synthesized our findings, leading us to our final design pattern. Please refer to the artifacts provided below for details.

Key Changes:

Uneditable Data: This will now utilize the gray card variation (instead of the address block with blue border).
As mentioned in Option A from the "Describe alternatives you’ve considered" section
Editable Data: This will use the white card with a black border (instead of the address block with blue border)

Research report

Final Figma Designs

Pattern guidance

VA Design System Storybook
**This is currently a WIP pull request to add components and usage examples related to the Prefill pattern in VADS. If you’re interested, please feel free to take a look.

0 replies

jaclinec · 2024-10-30T16:26:54Z

jaclinec
Oct 30, 2024

Hello there! Thanks for submitting this comprehensive proposal - there are a lot of great details and research here. We're reviewing it now and had a few questions for you all:

Have you done any manual accessibility testing with assistive technology like screen readers, etc.? If so, what were the results?
What was the test environment? The prototype link in the research plan doesn’t work for us.
In our desk research, some sources suggest it's better to present pre-filled data in editable, interactive fields because users often ignore the static presentation of the data (source: Baymard Institute article). Was there a reason you decided to present static/locked data in a card that the user has to click “edit” instead of presenting prefilled data in editable fields?

4 replies

msbtterswrth Oct 30, 2024

Thanks for the questions, our team will review these and get you some answers soon!

msbtterswrth Nov 18, 2024

Yes, we have tested our pattern internally, found and addressed several small a11y issues, but overall had no issues with AT.
We used codespaces to test this with users during our research study. This allowed us to use the existing VA code bases with custom data endpoints and our mock form app that we could control and update on the fly during studies if we ran into any issues. We do need to turn on the codespace every 4 hours. We'll make sure it's up and running during the next 2 weeks as much as possible.

@bellepx0 and @adamwhitlock1 can extrapolate on the above two comments if you have further questions.

In the article you cited, the authors explained their reasoning for presenting prefilled information as editable, interactive fields as "Users often overlook prefilled and autofilled values when they are presented as static text, so we recommend presenting prefilled and autodetected values as open text fields or other interactive form elements." We haven't yet seen that users are overlooking their prefilled information in our research. However, we're running a second round of research now, and we'll stay tuned to see how users respond to prefilled information when displayed outside of interactive form elements.

Additionally, the VA.gov environment is different from the e-commerce experience referenced in the article in that not all prefilled information is editable on VA forms. Some sensitive information (such as legal name and social security number) requires the user to call and verify their identity before updating it. Because we want to display prefilled information consistently across forms, and we can't display un-editable data in an open text field, we currently recommend to display all prefilled information in a card format. We're currently testing a few ways to display this uneditable information in ways that would also work well for display editable information.
Finally, we think that displaying the data in a non-editable format (with a link to edit the data, of course) will help reduce accidental user changes to the data. This is especially important if the changes will be saved to their VA.gov profile, as those changes would impact future forms.

adamwhitlock1 Nov 19, 2024

As far as prototyping, because we are using the VA website and authenticated form flows, we are using the codespaces feature to allow a fully mocked authentication environment to do user research.

We currently do have our first pattern's prototypes available here at this url: https://effective-space-tribble-rq7q67g6gv359p5-3001.app.github.dev/mock-form-ae-design-patterns/1

The environment does spool down after 4 hours of inactivity, but can be spun back up at a moments notice. Feel free to @ me if you would like to view the codespace url and it is not functioning, and I can make sure it is live. We are also discussing how we might be able to show some of this without mocked authentication, but it is also of note that our pattern storybook stories are also live to check out.

jaclinec Nov 19, 2024

@msbtterswrth and @adamwhitlock1 thanks so much for your responses! We're currently developing our guidance for this new pattern to eventually publish on our site and will reach out if we have more questions or want to run our ideas by you.

annepetersen · 2024-12-13T18:48:38Z

annepetersen
Dec 13, 2024

As a brief update for everyone, the USWDS core team has done our initial evaluation and are moving this forward to the next step now, which is creating a formal proposal for community comment. This includes writing up how this would appear on our site, making sure the terminology and format all matches, and then double-checking that what we create supports the original authors' intent and use case.

As a reminder, the outline of this whole process is over here. We're pretty far along here, thanks to the great work done in the original proposal (thanks for that!), and the team's answers to our questions, and have just about reached that last sentence:

Once a component discussion has addressed all of these, the USWDS core team will create a formal proposal, open the proposal for community comment, then evaluate it. We’ll share our decision with the community on the relevant discussion page.

The step we're working on is the "formal proposal" part of that.

For that matter, if anyone has other examples or implementations they'd like to share, or specific things they'd like or wouldn't want in this type of pattern, we'd still love to hear from you!

0 replies

Navigation Menu

Repository navigation

Pattern proposal: Help users to... Know when their information is prefilled #6053

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments 4 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Pattern proposal: Help users to... Know when their information is prefilled #6053

Uh oh!

Component name

Component description

Additional context

Why USWDS needs this component

How the component works

Describe alternatives you've considered

a) Within the form:

b) When users get to an edit page:

c) When the user clicks on the Edit link:

Real-world examples

When to use this component and when to consider something else

When to use this pattern

When to consider something else

Usability considerations

Accessibility considerations

Who’s involved

Replies: 4 comments · 4 replies

Uh oh!

Uh oh!

bellepx0 Oct 17, 2024 Author

UPDATE:

Key Changes:

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 4 comments 4 replies

bellepx0
Oct 17, 2024
Author