department-of-veterans-affairs / tmf-auth-exp-design-patterns

Developing design patterns for the authenticated experience
2 stars 0 forks source link

Respond to USWDS feedback #182

Closed msbtterswrth closed 1 week ago

msbtterswrth commented 3 weeks ago

Background

USWDS has responded to our proposal with some questions, let's review and provide some answers.

They asked us these questions:

Have you done any manual accessibility testing with assistive technology like screen readers, etc.? If so, what were the results?

Yes, we have tested our pattern internally, found and addressed several small a11y issues, but overall had no issues with AT.

What was the test environment? The prototype link in the research plan doesn’t work for us.

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.

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?

Many forms on va.gov currently do prefill data directly into input fields (and our pattern does still recommend doing this), however we found that by presenting users with a page to review any prefilled data, they were able to complete forms faster and increased trust in the VA by demonstrating that we were responsibly user's 'on file' data to reduce their burden.

kristen101606 commented 1 week ago

For the final question listed above, which touches more on design than the others, I'm suggesting this response:

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.

msbtterswrth commented 1 week ago

Thanks! I replied using the above and tagged both @adamwhitlock1 and @bellepx0 in the thread if they want to extrapolate on anything further.