Discovery: identify gaps in alert consistency across the portal

[jonathanjnelson]

Description

A ticket recently picked up by our team revealed that health tools need a variety of "portal-wide" alerts that have consistent design & architectural placement so that users understand what to expect and get the same messaging when they encounter an error or have an access issue that requires user-action.

However, our current-state documentation of how the health tool teams handle those alerts reveals serious gaps in approach, design, and consistency. We believe that standardizing these alerts across the portal will greatly improve the UX of My HealtheVet on VA.gov, and should be prioritized as an effort related to the sign-in transition work.

The goals of this ticket are:

1. Identify gaps in access alert consistency across tool teams and the MHV landing page
2. Identify "north star/preferred" experiences for each alert scenario
3. Discuss a governance + standardization requirement for these 7 alerts outlined in the body of this ticket (below) for all the "big 4" health tool teams, as well as the My HealtheVet on VA.gov landing page.

User story

As a Veteran, I want access alerts across the health portal to be consistent in design and placement, so that I understand what to expect when I see them and experience consistency + clarity about steps I need to take when I move from one tool to another.

Resources

• Mural to record current-state discovery

  Notes

  Sara did some work and believes there are 7 alert types that each of the health tools need to: a.) either implement themselves, or route-guard users to the My HealtheVet on VA.gov landing page to see. The alerts include:

1. Alerts that we need to determine how we want to handle architecturally across the portal:

Alert type	Standard established?	Exempt tools (if any)	Notes
ID-verification alerts	Yes	N/A	Published in VADS
No access to My HealtheVet alert	Yes	N/A	Created by Cartography team. Applies when LOA3 users w/o any facilities in their profile try to access any URL in the /my-health domain space
"Register with My HealtheVet" alert	Yes	Appointments	Created by Cartography team. Will be replaced with Account Creation API alerts once launched.
Account Creation API alerts	Not yet	Appointments	Work to develop FE alerts around API failures is still in progress by Cartography team, in collaboration with Identity and MHV Portals + Access teams
Cerner/OH routing alerts	Yes	N/A	Appointments team has most updated version that incorporates latest governance team feedback

We'll need stakeholders across tools teams to decide on the best architectural approach for alert placement. Then, those teams will need to document their current state approach to these alerts (do they handle this at all? If so, what happens when users w/o access to My HealtheVet type in their URLs? etc.).

Routing considerations:

• In general, do we want to block users who do not meet access requirements from getting to health tools (child pages) of My HealtheVet & route-guard them to the MHV Landing Page?
• Would we prefer to let users get to the tools, but prevent them from getting deeper than the main entry points to the tools if they do not have access?
• Do different alerts require different handling? Why or why not?
• What about OH/Cerner routing? What pages should those alerts live on within the "big 4" health tools?

2. Alerts that should be handled individually by health tool teams:

Alert type	Standard established?	Exempt tools (if any)	Notes
System error alerts	Unsure	N/A	Need to do discovery to see whether this should be templated / or if individual tool apps can differ
Downtime notification alerts	Unsure	N/A	Need engineer to remind us what this looks like today

Possible tasks:

• [x] Take this idea to office hours & discuss w/ OCTO stakeholders about making governance requirement
• [x] Identify current gaps in a Mural
• [ ] Get feedback from stakeholders around preferred experience for side-door entry points for each type of alert scenario
• [ ] If needed - ask tool teams to do discovery around these alerts & report back their current state / how they handle each (if we cannot identify it ourselves in staging due to test user complexity)

Acceptance criteria

• [x] current state is documented
• [ ] we have decisions on the desired experience for each alert type
• [ ] Receive feedback from Kaitlin and Robyn on how to move forward with this initiative in terms of coordinating a standardization effort across teams.
• [ ] Ticket next steps

[sterkenburgsara]

@fmccaf1 I'm feeling like there are a couple of things probably outstanding on these A/C's, so I have bumped this ticket up to a 5 & pulling into the next sprint as-is. I probably did some of the work this sprint w/o really realizing it, but that's okay.

Here is the Mural where I've been documenting the current state.

I posed questions about a few of these scenarios in Slack to the following teams:

• Appointments
• Medications
• Medical records
• SM

[sterkenburgsara]

I think we need to do these outstanding items:

• finish documenting current state &
• get decisions (if there are places we don't have them yet) about the "preferred" experience for each alert scenario.