Maturity through standardization

I fought for standards to eliminate significant inconsistencies across 8 siloed product teams. It shifted and matured the ways we all work together.

Overview

After stumbling upon some widespread inconsistencies in the VA’s health portal, I began to document the current-state with a goal of recommending an improved, standardized approach for a series of common access or error-related scenarios that users could run into.

After gaining stakeholder alignment on the significance of the problem, I was given full support to recommend a standardized approach. I drafted, designed, and worked with engineering & QA to document each one. The final step was to announce these new standard requirements to all 8 teams building in the healthcare portfolio.

This work is the first massive standardization effort for the health portal on VA.gov, and is a huge milestone in our maturity. Eight siloed teams are now using shared components and respecting the same high-level application logic for the first time, which is a boon for usability heuristics and our over 3 million monthly users.

Perhaps more interestingly, this attention to standardization has caused an amazing ripple effect, whereby designers from teams that previously lived in siloes are connecting with one another & thinking about the holistic user journey. Individual tool teams now reach out when they run into scenarios that are likely to scale beyond their own application. They ask for guidance and templates for error states, and look to each other for examples in how various things are handled.

Caption: Diagram of high-level access and gating logic for My HealtheVet on VA.gov

Problem

The health portal requires ID-verification, and users with low-level sign-in credentials should always see clear messaging that helps them understand next steps in completing the verification process online. A couple of months ago, I signed into our test environment with a test user that was not ID-verified to look at a few things. In moving between tools with this test user, I noticed that 3 different health tools handled ID-verification issues in very different ways.

Two tools had messaging that was blatantly wrong. One tool just redirected those users to a different part of the site. Others had boutique alerts with inconsistent heading text. This was only one type of access scenario, so I went on down a rabbit hole documenting the current-state for several more common scenarios and realized we had a pretty big problem. It quickly turned into a big initiative.

Approach

In order to get stakeholder approval to ask 8 product teams to prioritize standardizing their approaches, I knew we’d have to clarify the problem and any next steps.

  • Diagram high-level access logic: I focused first on the gating criteria that affects the most teams, and therefore poses the biggest issue for users if inconsistent.

  • Visualize the inconsistency: I asked for help from other designers on my team and together we grabbed screen-shots of current-state experiences for each health tool in the portal across a number of scenarios. Then we dropped these into a Mural table for full-effect.

Caption: table mapping inconsistencies in what was the current-state experience.

  • Identify common approaches: Once we had the current state documented, it was easy to identify patterns in how each team approached each scenario. I could see from a high-level which experiences were completely inaccurate and eliminate those, but also see strengths and weaknesses of the ones that were better.

  • Draft standards: Recommend solution(s) for each scenario that all teams could implement to enforce greater cohesion across the portal.

  • Get buy-in: Share-out the visualization of the problem & the drafted standards with stakeholders. Incorporate their feedback and iterate.

  • Design: Create polished designs, alerts, and/or pages in Figma for agreed upon designs for each scenario. Solutions that required flexibility became templates with interchangeable content blocks, where content can be customized by teams based on the unique needs of their downstream APIs.

  • Document: Create thorough documentation aimed at designers and stakeholders that includes the high-level description of each standard alongside the design. Collaborate with engineering to further flesh-out documentation & create shared components that all teams can “grab” so that only one master instance exists wherever possible, reducing overall tech debt.

  • Announce: Meet with product owners of all affected teams and discuss the requirements and timeline; answer any questions, including implementation details. Continue to follow-up and ensure these updates make it onto product roadmaps and meet deadlines.

Caption: Screenshot of standards documentation.

Design

Some standardization required all teams, but other standards only affected tools that rely on shared backend databases or APIs. I had to first clarify the API logic with diagrams before I could explain why certain error states or alerts impacted each team.

From there, we developed standards in two rounds. This work heavily relies on clear content + plain language, so it involved close collaboration with our content specialists. A few of these standards were not only inconsistent in the health portal, but we identified sitewide consistency issues across VA.gov and submitted some of these components to the broader design system for scaled impact.

Round 1

The highest level and most widespread scenarios that affected most, if not all of the health portal. These are based on our high-level gating logic (diagram at the top of this case study).

  • ID-verification alerts

  • No access alerts

  • UX for unauthenticated users

Caption: We have 3 variations of identity verification alerts based on the type of credential that the user signs-in with.

Caption: Image of “no access” alert implemented on the My HealtheVet on VA.gov landing page.

Round 2

Tool-specific error states that needed to be handled consistently, but were more edge cases, or did not necessarily apply to every health tool in the portal.

  • Page not found component (404 error)

  • Access denied component (403 error)

  • Internal service error / failed API call (500 error) - helpful content for 500 errors varies based on the API, so this one was templated, but could be customized.

Caption: 404 page not found component

Caption: 403 access denied component, customized for the health portal

Impact

The immediate impacts are clarity and consistency. Knowing what the problems are and how to solve for them makes alignment easy, and ensures a more cohesive health portal. This in turn builds trust and confidence with our end-users. People will now see more accurate messaging that is representative of the problems they are actually facing at each turn, with clear steps to resolution. If they use our secondary navigation bar to hop between health tools, such as appointments to medical records, the same error messages should show up everywhere.

Before

Caption: Examples of inconsistent & wrong error-messages within the same tool (Medications) before this effort. None of these told the user how to fix the real problem: verifying their identity.

After

Caption: Now, users get redirected to the top of the health portal anytime they attempt to reach any URL without first meeting our basic criteria of an ID-verified credential. This alert accurately describes the problem and gives them next steps to resolve it.

The longer-term impact has been a mindset shift. Sometimes, the best evidence of progress isn’t in metrics - it’s in how people talk and work. It’s easy to be head’s down, building in your own product space and lose sight of the broader, holistic user journey. Teams beginning to realize that their product problems may be broader than themselves is an incredible step in the maturity of our portal. Signs of maturity include:

  • Teams proactively raise edge-cases

  • Designers expect and look for Figma components & templates when they run into scenarios that they realize are probably common beyond their own application

  • When teams get user feedback about problems with these patterns, they raise it in broad channels and collaboratively find improvements

  • Questions build from a place of shared understanding, and are more holistic in nature

  • New team members can orient themselves to how it all works

For example, I had not originally created a template for 500 errors, but at least three independent teams asked about it within a 3-week period of time, so we prioritized it and rolled it out. Getting feedback on common problems, points of confusion, and collaboratively working through these challenges saves time, ensures a cohesive approach, and reminds us all of our shared goal to build a portal, not one single health tool.

Caption: Screenshot of a conversation in Slack, where teammates proactively asked for information about design files to solve their problems.

Caption: Screenshot of a conversation in Slack, where a teammate was seeking guidance on several access and error states.