[UX] [Content] Decide whether to have modality-specific accordion content or modality-agnostic accordion content

[benbrasso-agile6]

Description

Currently, we have different content in the accordions on confirmation and error pages for each appt modality, e.g., phone vs in-person. Knowing that we're adding VVC and CVT, we need to decide if it makes more sense to have separate accordion content per modality or have it be more modality-agnostic, e.g., "something went wrong, here's a couple ways to contact VA."

In addition, there are scenarios where pre-check-in could include more than 1 type of modality. So, the accordion content could get unruly if we're having to list out content for 4 different modalities.

Tasks

• [x] Identify (and/or have an understanding of the) differences between accordion content on confirmation and error pages for in-person vs phone pre-check-in (using Sketch). Note: one thing that is not documented in the annotations for those accordions are when pre-check-in includes 1 in-person and 1 phone appt. For example, is there content that speaks to both appt types? I had created a ticket a while ago to document these scenarios, but never had a chance. So, we just need to be aware of this. Here was that ticket, but there's not much information in it. I believe the engineers can simulate an pre-check-in UUID with a phone appt and in-person, but we can't do that using the stg site.
• [x] Understanding that we're going to be adding VVC and CVT appts to pre-check-in, talk to engineers about the accordions on the pre-check-in confirmation and error pages and see if they have an opinion, architecturally, for whether it makes more sense to have specific content per modality or generic content. (Brian has confirmed that switching to modality agnostic content would be preferable, i.e., content that can support any modality.)
• [x] Document decision in ticket
• [x] Create f/u tickets for wireframes and content

AC

• [x] Decision documented
• [x] F/u tickets created for wireframes and content

[kellysmith1008]

Based on the information we have in accordions and that we've set a precedent in using 2 options (updating NOK and contact information, for example) I feel our best option is to create one singular "How can I update my information" accordion that provides instructions on how to do it regardless of appointment modality. We sorta do this now when multiple demos need to be updated - we could riff off that idea. I'm going to pull in the error messages ticket (#72429) next - @benbrasso-agile6 do you want me to separate the follow-up tickets for each of these into 2 follow up tickets? Or should I wait to see what I discover in the error message ticket and, if the decision is the same, create 1 follow-up ticket to create the content and wireframes for both accordions and error messages?

[benbrasso-agile6]

Agree with that analysis. One thing worth mentioning, which I agree with... Laura was a big proponent of, at the end of pre check in, if demos needed to be updated before the appt, then make those instructions more of a priority on the confirmation page. E.g., maybe don't place them in an accordion, even if the accordion is expanded on page load. I'm not saying we have to move away from that approach, but just wanted to pass that info along.

And, yes, I'd say it's up to you on how to handle the tickets. If you do the analysis on the other ticket and then decide it makes sense to knock out all the changes in 1 new ticket, that's totally fine.

Sounds like you're on a good track! TY!

[kellysmith1008]

After speaking with Ben this morning, the best plan for this content is to be modality-agnostic, 1 set of content to account for all modality types in error messages. However, I think this content might be a little trickier to write than the accordions because of its prominence and need for absolute clarity, so instead of making 1 follow up ticket for both this and the accordion ticket, I'll create 2 separate tickets and can reference both in each ticket.

[kellysmith1008]

Follow up ticket for wireframe and content creation created Closing this ticket

[benbrasso-agile6]

LGTM