Midpoint Review - Content Feedback - Veteran Facing Forms - Patterns - Form submitter pattern

[KKitagawa-Bosch]

Next Steps for the VFS team

How did this touchpoint go? Give feedback on the Collaboration Cycle at any time.

• Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
• Comment on this ticket:
  • If the Platform reviewer has any Thoughts/Questions that require responses.
  • When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
  • When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
• Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members.
• Close the ticket when all feedback has been addressed.

Thoughts/questions

Feedback

Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

• Must: always use active voice. The copy in warnings is currently passive.
• Must: follow the word list guidance on the use of the term "accredited representative"
• Must: remove bold text per the VADS guidance

Governance team actions

• Format feedback as individual tasks (check boxes)
• Assign this ticket to the VFS team member that opened the Slack request
• Add the VFS team product label
• Add the VFS team the feature label (if applicable)
• Add the touchpoint labels
• Add the practice area labels
• Add the Collaboration Cycle initiative milestone

[JaciWilkinson]

@KKitagawa-Bosch and I met for a follow up call to discuss. Documenting decisions made on that call and actionables:

• For now, leaving the term "non-Veteran claimant" in the pattern to describe someone who is a claimant/beneficiary of a VA service/benefit but who is themselves not a Veteran. Jaci will add appropriate hint text to the questions where "non-Veteran claimant" is used to define and reduce user confusion. Jaci will also add to documentation's related terms list.
• Question 2a will remain as is.
• @KKitagawa-Bosch agreed to take a look at the revised question 2b that Jaci has modified since collab cycle based on further conversation with NCA policy experts and will give content feedback in Figma as they see fit. (See local component "2b. NEW 3rd party question" located on the local components page in the pattern file).

[laurwill]

Hi @JaciWilkinson and @KKitagawa-Bosch ,

Wanted to follow up about the "non-Veteran claimant" term. Here's my understanding of the purpose of this term in the pattern:

• When the form submitter selects "I'm a non-Veteran claimant" or "I'm filling out this form for a non-Veteran claimant," that tells us that we need to collect the personal information of both a claimant and a Veteran separately, because they're not the same person.
• So the important distinction here is not that the claimant is not themselves a Veteran. It's that they're claiming VA benefits under the service-related eligibility of another person, as opposed to under their own service-related eligibility.

And that leads to my concern with this term: If we use the term "non-Veteran claimant," what happens in cases where the claimant is a Veteran, but they're claiming benefits as the family member of another Veteran? This scenario is possible for several VA benefits.

For example, take a Veteran with a discharge status or service history that makes them ineligible for VA health care. They're married to another Veteran who meets CHAMPVA service-related requirements, so they're applying for CHAMPVA family member health benefits as the spouse of a Veteran. Do we expect that person to select "I'm a non-Veteran claimant," even though they are in fact a Veteran?

Or, if we expect that person to select "I'm a Veteran" (which seems more likely), how will we know that the claimant and the Veteran are different people, and we need to collect information for each one separately?

[JaciWilkinson]

@laurwill Since this is a pattern, it will not necessarily cover all use cases, like the CHAMPVA one you suggest. The expectation, like with all patterns, is that each team will use this pattern as guidance and best practice, not that every term and piece of the design will be applicable in every form scenario.

[laurwill]

@JaciWilkinson totally understand that the pattern can't cover all use cases. I'm just concerned that introducing the new term "non-Veteran claimant" in the pattern will lead to teams defaulting to that term or assuming that it's a suggested term to use in many or most forms.

So before introducing that term, would it make sense to first assess how many VA forms could include this Veteran-claiming-benefits-through-Veteran-family-member scenario? Or is that something you already explored in your research? (Even if hint text addresses this with something like "If you're a Veteran claiming family member benefits as the family member of another Veteran, choose 'non-Veteran claimant'," I don't think we'd want to ask Veterans to self-identify as non-Veterans.)

I also realized that the alternative we had started exploring runs into the same problem!

We had started playing with language like "I'm a [family member] filling out this form for myself," where form designers would need to adjust [family member] for specific user stories in their form (like caregivers, etc). But for this Veteran-claiming-benefits-through-Veteran-family-member scenario, that still wouldn't make the choice clear enough. "I'm a Veteran filling this out for myself" and "I'm a family member filling this out for myself" would both be true for that person.

We had been trying to make the answer options more standard by using "filling out this form." But one potential direction would be to accept that designers will need to deal with the variable of [form/request/claim/application], and phrase the model answer options more like "I'm applying for this benefit as the family member of a Veteran." That would need more exploration to see how it fits in different forms (and it's very long), but I think there's a way to approach this that would make the example answer options in the pattern more widely usable. Would you be open to exploring some alternatives before moving ahead with "non-Veteran claimant"? Or will there be an opportunity to test this term with users before it goes into the design system?

[megansiddle]

@laurwill you make excellent points. We don't want to provide guidance in the design system that you feel needs testing to be validated.

I'm looping @jeana-adhoc and @bpandone into this ticket as well so they are aware.