Transforming VA’s Medications tool with better information architecture
How I helped the VA’s medications team re-frame user problems, solve structural issues, and future-proof their product.
Role:
Information architect
Contribution:
Major problem discovery, including competitive analysis, data modeling, and concept designs for an improved user experience.
Overview
The VA’s healthcare patient portal has a medications product that connects Veterans to their historical list of prescriptions and lets them request refills online when they need more. Research revealed that Veterans run into significant challenges finding and tracking the statuses of their refill requests after submitting them. I identified the roots to the problem & refocused the team on what was really going on.
The design team initially responded to these user pain points by racing to design a filter component to help Veterans sift through their bloated medications lists, which really just offloads the work to users.
I realized that the actual problem was the list itself, and the way we were organizing the data. It wasn’t a UI or content issue, but a structural information architecture issue.
Structural solutions are hard sells. I needed to lead the team to understand the problem themselves. I failed in my approach several times, but eventually we framed two findability issues. Problem framing helped us connect the dots between user problems and gaps in the underlying data model.
We blueprinted a revised structure, which enabled the design team to get to work making updates to the user interface. Those enhancements shipped in January 2025.
Problems
In Spring 2024, user research revealed some significant findability issues with the medications tool on VA.gov.
Problem 1: the medications list was bloated
The page title for a Veteran’s historical record of medications is “Medications list,” but this was misleading. It was actually a list of all prescriptions for a specific medication, of which there could be many. For instance, if you’ve had a chronic condition like Type I diabetes for over a decade, you’d see “insulin” in your list dozens of times. Only one of those would be the “most active” one, and it might not be that easy for you to find.
This conflation of prescriptions & medications balloons the size of the list and reduces scannability.
Problem 2: it was hard to find the status of refill requests
Veterans were using the language “I can’t find the status of my refill” to describe their pain points. This specific feedback about the need to retrieve “refill information” is important, because I realized the medications taxonomy only included two core objects: the medication & prescriptions for it. We never built out the “refill” as a separate and narrower object in the taxonomy. Without this, we’d never be able to solve user problems related to finding a specific refill. We cannot design for what doesn’t exist.
Old taxonomy
We use “medications” as the highest order parent concept in this product, but the medications list is full of card components for prescriptions. Tools like OOUX can help us understand that we’ve assigned metadata to the wrong objects in the hierarchy. All CTAs currently happen at the prescription level, which explains why users cannot easily retrieve “refill” information. There is no “refill” object.
Revised taxonomy
This revised taxonomy more accurately organizes key objects in the data model, and clarifies what actions can be taken on each object.
This model serves as a north star, illustrating how the product could grow to include medical supplies according to the same data modeling logic.
Solution: Content and data modeling
After walking through named user pain points as a team and situating that feedback next to the product in real time, I asked the team some probing questions to help align us on what was going on. Things like “We call this the medications list, but I often see 5+ instances of some of these medications. What’s going on there?” The goal was to build shared understanding around the fact that we call the list “Medications,” and display the name of each medication, but the core information in each of these cards are prescriptions.
The team had been focused on how a new filtering component might help Veterans limit results in their medications list, but I needed the team to see that this approach can be helpful, but currently it puts most of the work on user’s shoulders without solving the core problem. Instead, we could shrink the problem and simplify this upfront for all users by consolidating the content model. Doing so would also enable us to build out & address the missing object: refills.
Medications list
Current state
Revised future-state
Medication details page
Current state
Revised future-state
Impact
These updates launched in early January 2025, and unfortunately we continue to find that additional findability issues persist. This work made a meaningful dent in consolidating our data to be simpler to parse and design with on the front-end, but there are additional, related issues to tackle next, and that work is slated for the remainder of 2025. We call it our “blue sky” thinking project, because we believe that the entire product footprint is fighting the users’ mental models for what they expect to see when they enter a pharmaceutical tool like this.
Now that we have a data object for the concept of “refills” we can package that object in new ways. For instance, we allow users to submit refill requests in bulk, but previously had no way to return that “set” of things to the user in a packaged way. But now, we could ideate around adding an “order history” page to the product to help findability issues in newer, more robust ways that future-proof medications.
