You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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:
We believe that this pattern will consist of a variety of components and content including, but not limited to:
Current examples
Additional Notes
Ask VA research findings that relate to this work
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.
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'
Implementation Details
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)ACs
The text was updated successfully, but these errors were encountered: