[Pattern] Help users to... Know when their information is prefilled

[msbtterswrth]

User Story

As a logged in Veteran, I want to know when my forms include prefilled data, where it comes from and how I can edit it so I can save time, reduce errors, and complete forms more efficiently when applying for benefits or services.

Background

We did some workshopping about what this pattern is/isn't, the current pain points and user flow and how we might make improvements in this mural.

Hypothesis

We believe that creating a comprehensive pattern for form prefill based on authenticated user data, including guidance, example code, and design resources, will:

• Enable easier implementation of form prefill across various VA.gov applications
• Promote consistency in how form pre-fill is implemented across the platform
• Lay the groundwork for future improvements in Veterans' form completion experience
• Facilitate more complete and up-to-date Veteran profiles as applications adopt this pattern
• Allow users to review their prefilled information before submission
• Reduce the need for custom code related to form prefilling, leading to more maintainable and consistent applications

We believe that this pattern will consist of a variety of components and content including, but not limited to:

• Alerts
• Address OR Card including (TBD in testing)
  • Locked variation
  • Editable variation
• Directions to update profile data (relates to [Pattern] Help users to... Update prefilled information #22)
  • instructions to call
  • (action?) link to edit

Current examples

Additional Notes

• Ask VA research findings that relate to this work

  • Many Veterans will choose to sign in so their information is pre-filled, but donʼt fully understand when sign in is required to use Ask VA
  • Itʼs clear why information is prefilled, but thereʼs uncertainty about whatʼs impacted if you edit pre-fill
    • People expect to edit pre-filled details by clicking into the field and making changes. Could our pattern explore this approach to editing UX or should we stick with the editing pattern that are established?
    • But, thereʼs uncertainty about whether those changes will be reflected across VA.gov or just the form theyʼre working on. Could our pattern explore this idea more and how we could inform people that their updates to pre-filled fields will propagate to the profile side as well?
    • Many people continue to expect personal information to be first after they sign in, before they get into the bulk of the form. Include guidance with the pattern to start a form with the main pre-fill info fields, and then move into more specific form pages? How could this guidance potentially affect the overall form flow and the digital vs paper organizational parity?

• The pre-fill design system component that is located in the form > pre-fill section of the docs consists of just an alert with specific language around pre-filling the information.

  • this is a component and not a full blown pattern

• The closest pattern Know how their information is updated includes content saying that it will use the pre-fill component, and that the pattern should be used when 'Prefilled Profile data is being displayed and is editable'

  • So does that mean the Pre-fill forms pattern should extend this pattern, or replace it or we should just make the pattern better and add specific code examples.
    • There are no existing code examples or concrete links to developer docs for this pattern

Implementation Details

• Vets-website _mock-form This is where the existing patterns are prototyped and displayed as a reference. We can build within this application or possibly create our own application along the lines of '_mock-form-auth-patterns'
• forms-system > ContactInfo.jsx A contact info page that allows a user to update each piece of info on their own mini respective editing page, and then return to the contact info page and proceed with the rest of the form steps. Sitting well over 400 LOC this component could serve as a base for use to build a similar pattern from, or improve to integrate into our pattern.
• forms-system > EditContactInfo.jsx Component responsible for rendering the single field editing experience in a form. The fields supported are Home Phone, Mobile Phone, Email, and Address. This component uses the ProfileInformationFieldController to render the form and connecting the logic to update these profile fields in the same way that the Profile application updates data (same api calls and validation logic)
• ProfileInformationFieldController.jsx A 'monolithic component' it has grown a bit too large, does too much, and is difficult to maintain, test, and reuse. It is also a legacy class based component and could really use a refactor. Can't really get rid of it altogether, but there might be room for us to abstract its pieces into individual hooks, components, and modules. Adam originally experimented with this idea in a discovery branch (which is admittedly now very dated) and had created a useProfileTransaction hook but the work was stopped when the VAFSC was abandoned.

ACs

• Existing prefill component is moved out of components and into patterns
  • Code examples are provided
  • Design resources are provided
  • Governance is updated
• Audit of products currently using Know how their information is used pattern
  • Merge with prefill