IA Feedback - Staging Review VAOS - Homepage Refresh

[mnorthuis]

VFS acceptance criteria

• [x] Let Platform know when the Must feedback has been incorporated
• [x] Leave any comments for feedback you decide not to take
• [x] VFS team closes the ticket

Thoughts/questions

• The "canceled" label is very prominent and draws eyes to it. The test user may be an extreme case of many canceled appointments, but just confirming that this the most important attribute of the appointment? Was appointment type considered (i.e. in-person, telehealth, lab, etc)

Feedback

• Must = the feedback must be applied
• Should = the feedback is best practice
• Consider = suggestions/enhancements

Must:

• Choosing "requested" from drop list results in an error. Actually had this issue with different statuses at different times. (11) We’re sorry. We’ve run into a problem We’re having trouble getting your appointment requests. Please try again later.

Should:

• The "show by type" drop list appears to be a list of statuses, but "cancelled" (although it is a separate option) appointments show up in "upcoming" and "past". Results could be confusing to users when a "cancelled" appointment appears as the first option in the "upcoming" list. If showing cancelled appointments in the other filters is important (understandably could be), an option could be showing "cancelled" as a separate control - like a toggle to include/exclude cancelled appointments in any of the other views. (108)
• Choosing "requested" from drop list results in an error message that has inconsistent punctuation - missing a period after "We've run into a problem" (26) We’re sorry. We’ve run into a problem We’re having trouble getting your appointment requests. Please try again later.

Consider:

• Consider using "Show by status" rather than "Show by type" for a more descriptive label. (109)
• Regarding the implementation approach to show the filtered appointment list (based on the user's drop list selection) as a separate sub-page (uses a sub-directory like /past) rather than an on-page refresh (i.e similar to how a change in the date range displays) or displaying the selection using parameters (i.e. /appointments?type=past), could create some navigational challenges. Because each set of results is on a new page, it creates a situation where a new page is added to browsing history, but the new page has the same page title, and no other indicators on the page (i.e. breadcrumb, H1, etc) show that they have navigated to a new page. This may create some frustrations if the user is attempting to go back and needs to navigate through multiple variations of a page. It also creates an issue where once on a detail page, if the user uses the breadcrumb to go back, they go back to the default state of the page rather than to a potential filtered page they have been on prior. These are somewhat minor issues, but other implementation methods may create a cleaner experience for all users. (6,78)

[outerpress]

Thanks @mnorthuis!

Choosing "requested" from drop list results in an error.

Is your recommendation to change the error language? Or more broadly about the error itself?

The "show by type" drop list appears to be a list of statuses, but "cancelled" (although it is a separate option) appointments show up in "upcoming"

We went this route because we were worried about cancelled appointments disappearing from the Veterans view, especially when they were not cancelled by the Veteran. We don't have a way to display a temporary update to a veteran when an appointment status changes yet, but we have talked about it.

and "past".

I can't test this now but there shouldn't be cancelled past appointments, since an appointment that was cancelled never happened. I think we ran into this issue a little while ago but fixed it. @laurenernest do you remember this one?

Results could be confusing to users when a "cancelled" appointment appears as the first option in the "upcoming" list.

Agreed. We'll keep an eye out for any confusion around this as we track the release.

If showing cancelled appointments in the other filters is important (understandably could be), an option could be showing "cancelled" as a separate control - like a toggle to include/exclude cancelled appointments in any of the other views. (108)

Just for added context, here's what we heard around cancelled appointments.

Consider using "Show by status" rather than "Show by type" for a more descriptive label. (109)

I don't have a way of knowing if one would be any clearer than the other to a veteran - do we use "status" elsewhere? @peggygannon any thoughts on this one?

Because each set of results is on a new page, it creates a situation where a new page is added to browsing history, but the new page has the same page title, and no other indicators on the page (i.e. breadcrumb, H1, etc) show that they have navigated to a new page. This may create some frustrations if the user is attempting to go back and needs to navigate through multiple variations of a page.

This makes sense. We could update the page title to something like [Your appointments/Past appointments/Requests/Canceled appointments] VA online scheduling | Veterans affairs

cc @laurenernest

It also creates an issue where once on a detail page, if the user uses the breadcrumb to go back, they go back to the default state of the page rather than to a potential filtered page they have been on prior. These are somewhat minor issues, but other implementation methods may create a cleaner experience for all users. (6,78)

Agreed that this is an issue. The detail page is one of those areas that (we may have talked about this) it might be better to not have a breadcrumb and just have a back button at the top of the page that would return to the previous context. This is in the back of my head as something we could test as a variant post-release.

[mnorthuis]

I'll answer to the "Must" feedback item...if this is a known or intended error message due to a service failure, you can ignore this feedback. If this is a QA issue where a result was intended but something is failing, then it needs to be corrected.
Choosing "requested" from drop list results in an error. Actually had this issue with different statuses at different times. (11) We’re sorry. We’ve run into a problem We’re having trouble getting your appointment requests. Please try again later.

In regards to the other feedback, nothing is required to be changed, but should be reviewed for potential improvements.

Your suggestion to updating the H1 and page title to indicate the change in page when a different option is selected may help with clearing up browser history and back behavior.

I do have it on my list of wishes to explore instances where removing the breadcrumb and replacing it with a "Back" link may be helpful. I will add this one to my examples.

[laurenernest]

Choosing "requested" from drop list results in an error.

This was due to downstream system errors (we had a few issues the past week). The Judy user doesn't currently have any open requests so this is what it looks like.

---

and "past".

I was able to repro. we'll fix this.

[outerpress]

@laurenernest everything's captured from this one on my end

[peggygannon]

@laurenernest @outerpress I agree with Mikki's suggestion to use "Show by status" for the drop down label. We use "type" of appt (video, in person, etc) throughout flow, so "status" is more accurate description for this scenario/label.

[outerpress]

Thanks @peggygannon and @mnorthuis that makes sense to me!

[laurenernest]

included changes we're taking action on in #26657. closing ticket.