VA Decision Reviews:
Designing the Onramp
Helping Veterans navigate complex, policy-driven decisions through a simpler, guided experience
Product Design · UX Research · Service Design · Accessibility
June 2025 - August 2026
My role
Product Designer/UX Researcher
Agile 6
What I did
Led end-to-end product design and research for a new guided Decision Reviews experience, from discovery and journey mapping through experience architecture, prototyping, usability testing, and implementation. I translated complex policy, legal, and technical requirements into a clearer path for Veterans, partnering closely with Product, Engineering, policy, legal, and VA stakeholders to move the experience from concept into development.
Methods
Product Design · UX Research · Service Design · Journey Mapping · Information Architecture · Interaction Design · Prototyping · Usability Testing · Accessibility
Tools
Figma · Mural
The Challenge
Veterans trying to understand their Decision Review options must navigate several lengthy, complex VA.gov pages covering: VA decision reviews and appeals, Choosing a decision review option, Supplemental Claims, Higher-Level Reviews, and Board Appeals. The information is there, but understanding how it applies to an individual situation isn't easy. Different pathways have different rules, eligibility requirements, evidence needs, timelines, and tradeoffs - making it difficult for Veterans to understand which options may fit their circumstances.
The existing Decision Reviews experience requires Veterans to navigate multiple dense VA.gov pages to understand and compare their options.
Our goal was to create a guided experience that could help Veterans understand which Decision Review options might apply to their situation without requiring them to first understand the complexity of the VA system. Officially, this guided experience was called "Explore disability claim decision review options", but on the team we just called it "The Onramp".
Our challenge was to turn that complexity into a guided experience that could help Veterans understand which options may fit their situation without oversimplifying the policy behind them.
Making complex rules understandable
Before we could simplify the experience for Veterans, we had to make sense of the complexity behind it. I worked through 30+ iterations of the Mural decision-tree model, translating eligibility requirements, prior decisions, evidence rules, deadlines, worsening conditions, contested claims, and multiple appeal pathways into a branching structure that could drive the experience.
As the model evolved, it became more than a UX artifact. It gave Product, Content, Engineering, Accessibility, and VA stakeholders a shared way to understand the rules, identify gaps and conflicting requirements, and see how a change in one part of the experience affected everything downstream.
Selected iterations from more than 30 versions of the decision-tree model are shown below. Full-size PDFs of each model are available for download here:.
06/17/2025 · An early exploration
An early version of the decision tree established the core Decision Review pathways and began translating VA policy and eligibility requirements into a structure Veterans could navigate.
07/11/2025 · Adding content and strengthening decision logic
As the model evolved, content stated to come into focus. Additional conditions and branching logic were introduced to account for factors such as prior decisions, evidence requirements, deadlines, and changes in a Veteran’s circumstances.
03/30/2026 · Resolving growing complexity
As the model evolved, content stated to come into focus. Additional conditions and branching logic were introduced to account for factors such as prior decisions, evidence requirements, deadlines, and changes in a Veteran’s circumstances.
07/22/2026 · From complexity to clarity
By the final iterations, the decision tree represented the policy and conditional logic needed to support the guided experience, providing a foundation for translating a complex Decision Review process into clearer, contextual guidance.
My design approach
Veterans shouldn't have to understand the Appeals Modernization Act, eligibility logic, or the structure of VA's Decision Review system before they can figure out which options apply to their situation. My goal was to keep that complexity behind the experience and ask Veterans only for the information needed to identify their applicable paths.
The system is complex.
The Veteran's experience doesn't need to be.
Designing for "and," not just "or"
Through discussions with the Product Owner and VA subject-matter experts, followed by our first review with OAR and the Board of Veterans' Appeals, I uncovered an important gap in our decision model.
The tree assumed that a Veteran either:
-
disagreed with a previous VA decision or
-
had a service-connected condition that had worsened.
It didn't account for someone experiencing both:
A Veteran could disagree with a previous VA decision AND have a service-connected condition that had worsened.
That distinction mattered. A Veteran in this situation might need to pursue a Decision Review, such as a Supplemental Claim (VA Form 20-0995), and file a separate claim for increase (CFI) through a VA disability compensation application (VA Form 20-526EZ). If the guide surfaced only one path, we risked giving Veterans an incomplete picture of the actions available to them.
I redesigned the decision tree to carry the claim for increase state through every applicable pathway and endpoint. That also required rethinking the summary experience so both actions could be presented together when appropriate.
Because much of the original logic had already been coded, the change required significant engineering rework. I walked the Product Owner, Enablement Team, Engineering, and Delivery through the revised model several times to explain why the change was necessary, how it affected downstream logic, and what needed to change in the experience.
Decision Logic
The questions about whether the Veteran's condition had worsened and whether they disagreed with VA's decision were independent, meaning both could be answered “Yes.” When that occurred, the Summary needed to show the appropriate Decision Review options along with the Claim for Increase (CFI) option.
Both can be true
Two separate questions preserve BOTH states.
Both paths can be seen in the result
Summary screen shows 1) available options AND 2) claim for increase information
1
2
1
2
1
1
From system logic to product experience
As the decision model matured, it became a shared implementation artifact alongside Figma. Engineers used the decision tree to understand branching logic and dependencies, while Figma documented the corresponding interactions, content, and interface states.
We regularly walked through complex paths together, using working sessions, standups, and impromptu huddles to resolve questions and edge cases as they surfaced during implementation rather than treating design as a handoff.
Complex Logic, simple questions: The complexity stayed in the decision model, so the Veterans could move through a clear focused experience.
Decision Tree Model #34
The logic, rules, branches, dependencies, and edge cases behind the experience.
~ Versus ~
One question at a time: Complexity made simple.
Testing the experience with Veterans
The Figma prototype was complex and heavily relied on components within components, so that content changes would only need to be made once. We conducted 7 moderated usability sessions with Veterans using the real coded staging experience. We wanted to understand whether Veterans could enter and complete the guide independently, understand the questions and terminology, interpret their personalized results, and feel confident about what to do next.
The research validated the guided approach, but also revealed an important distinction: making the decision logic accurate wasn't enough. The experience also had to match the way Veterans understood their own situations and support them through a consequential decision.
Finding 1: Getting into the onramp was harder than actually using it.
5 of 7 needed help identifying how to start, while 6 of 7 completed the question flow independently once inside. Only 1 participant out of 7 launched the guide without moderator assistance as their first action taken. The primary CTA to launch the guide was an action link “Explore your options”, which we hypothesized wasn’t clearly actionable.
-
4 participants explored the accordions as a first click in an attempt to learn more about the DR pathways. We hypothesized that this behavior implied they were unaware of the guide’s purpose.
-
It was our hope that the users would feel comfortable to start the guide WITHOUT needing to fully understand the details and complexities of all decision review options. The main goal of the guide is that it would be a helpful tool to lead the user in finding the option that works best for them, however we observed that some participants still felt like they needed to have chosen a decision review option before starting the guide.
-
P5 said: “[The accordions] draw my attention and makes me want to open it up to look at everything.” (The accordions were included to provide ancillary context for those who may have navigated to the landing page in error.)
-
Design changes:
-
Updated the page to make the call to action clear and actionable.
-
Changed the link from an action link to a primary entry action link to help users know how to start, without help, and
-
Revised the content to focus on the purpose and output of the guide.
-
Since the accordions were distracting, we removed them and reviewed the accordion content for inclusion elsewhere in the flow.
Finding 2: VA's mental model wasn't always the Veteran's mental model.
On the Disagreement with Decision page, the original language talked about disagreement, as well as requesting a review when their condition got worse. Participants expressed hesitation and confusion when answering this question. Some participants had difficulty with this question due to having multiple claims for multiple conditions open at once.
Design changes:
-
Changed the language on this screen to update the language to focus the content just on disagreement
-
Updated terminology, for example: we changed “submit a review” to “request a review”
-
Restructured the content using line breaks to improve readability
We gathered specific feedback on content by…
-
Collaborating closely on our Research Plan with the Content Team
-
Identifying key screens about which to ask targeted questions. The questions included:
-
“What does that sentence mean to you?”
-
Is there anything on this page that is confusing or unclear that you would like to understand better?
-
Was there any language or wording that caused hesitation or confusion?
-
-
Observing participant behavior and asking questions when there were pauses or when they repeated sections when reading aloud
Finding 3: Veterans interpreted the question as what to do next.
We initially organized claim types around the structure of the VA system. But the question, "What type of decision do you want us to review?" created an important mismatch between the system's mental model and the Veteran's.
The guide needed Veterans to identify the type of claim or appeal VA had already decided. Instead, some participants answered based on the type of Decision Review they wanted to pursue next. Participants were also confused by combining an Initial Claim and Claim for Increase into a single response option.
I redesigned the question and response options around the decision the Veteran had already received, making the point in time we were asking about much clearer.
Design changes:
-
Changed the question to "What type of claim or appeal decision do you disagree with?"
-
Added guidance directing Veterans to identify the claim or appeal VA had previously decided.
-
Reframed the response options around the prior decision rather than the Veteran's desired next action.
-
Separated Initial Claim and Claim for Increase into distinct choices while maintaining the appropriate downstream logic.
Research Design vs Legal/Policy Design
While research showed that Veterans misinterpreted the question as asking "which review they wanted to pursue" rather than "identifying the decision they had already received", we had designed the question around that mental model and separated out the 5 different claim types. Later, legal review challenged both the terminology and how those options could be represented, requiring another iteration.
Legal review didn't merely constrain the design. It exposed the fact that a binary question encoded the wrong model. Simplification wasn't always the goal. Legally accurate simplification was.
1 question, 3 iterations
The claim type question evolved through research and legal team / policy review.
Finding 4: Veterans wanted guidance, not just an answer.
The guide could help Veterans identify which Decision Review options applied to their situation, but research showed that identifying an option wasn't always enough to support a decision.
Participants wanted to understand the differences and tradeoffs between their options before deciding what to do next. Some wanted additional information, time to consider their options, or confirmation from a VSO, attorney, VA representative, or another trusted source before taking action.
This changed how I thought about the summary experience. Its job wasn't simply to tell Veterans which options were available. It also needed to help them understand why those options applied, how they differed, and what they could do next without pressuring them into an immediate decision.
Design implications:
-
Made differences between applicable options easier to understand and compare.
-
Preserved important decision-making information, including expected timeframes.
-
Provided clear paths to learn more before starting a Decision Review.
-
Supported Veterans who weren't ready to act immediately, including options to print their results or seek additional help.
Understanding of decision review
options increased from 2.57/4 → 3.33/4
AFTER using the Onramp.
Accessibility throughout, not afterward
Accessibility was part of the design process rather than a final QA step. I worked with our accessibility specialist throughout design to evaluate patterns against VA standards and identify potential screen-reader and information-access issues.
Patterns continued to evolve as the product matured - including replacing a hidden and deprecated "Additional information" VA Design System (VADS) component with a more modern "Details" VADS component; moving supporting explanations into clearly labeled "Learn more" links.
Designing across competing requirements
In February 2026, at our team's recommendation, the Product Owner expanded legal review beyond the Office of Administrative Review (OAR) and Board of Veterans' Appeals to include the Office of General Counsel (OGC).
Working on a regulated product meant there was rarely a single source of truth. User research, legislation, VA policy, legal interpretation, accessibility requirements, content standards, and technical constraints could point in different directions.
My role wasn't simply to advocate for one of them. It was to understand the constraints, make the tradeoffs visible, and find the clearest experience we could responsibly deliver.
When requirements conflicted, I brought the conversation back to the decision tree so stakeholders could see how a proposed change affected both the Veteran experience and everything downstream. The tree often exposed conflicts that weren't obvious when we were discussing individual screens and became an invaluable shared artifact for working through tradeoffs and reaching decisions together.
Claim type
Research showed a need for clearer separation between claim types. Legal review later changed how those categories could be represented.
Evidence
Legal review shifted the language from "new and relevant evidence" to the more actionable concept of "additional evidence to submit or identify," while preserving the underlying policy requirements.
Hearing preference
Legal review clarified that the hearing question represented a preference rather than a simple eligibility condition. A binary "Yes/No" question became "Yes/No/I'm not sure", allowing Veterans who weren't ready to decide to see the Board Appeal options that still applied to them.
From a binary yes/no to room for uncertainty
Veterans who were not ready to decide if they wanted a hearing, could respond "I don't know" and see all Board Appeal options that applied to them. This became know as a 'preference question', which also factored into what was later displayed on the Summary screens.
Maintaining continuity through team transition
Between March and April 2026, a contract transition replaced most of the delivery team, including the Scrum Master, Product Manager, Delivery Manager, engineers, and team leads. For roughly two months, I was the project's sole UX practitioner and became the continuity point for the design as a new team was assembled.
I maintained the decision model, continued design and stakeholder work, and helped onboard the incoming team by providing the context and rationale behind the decisions that had shaped the Onramp experience. Because I retained the history behind the decision model, research findings, stakeholder decisions, and unresolved questions, the new team could continue the work without rebuilding that context from scratch.
Where the product landed
By August 2026, the experience had progressed through more than 30 iterations of its underlying decision model, coded implementation, Veteran usability testing, ongoing accessibility review, and multiple rounds of policy and legal review.
When my work on the project ended, the experience remained in Staging (As of August 2026: https://staging.va.gov/decision-reviews/explore-disability-claim-options/) while Engineering continued implementing the design and content changes we had delivered.
The usability study gave us early evidence that once Veterans entered the guide, they could move through a highly complex decision process using a much simpler experience.
My contributions to the Onramp
Product Design
Translated research, policy requirements, and complex decision paths into a guided VA.gov experience, developing the information architecture, interaction patterns, content structure, and high-fidelity Figma designs.
Service Design
Mapped the broader Decision Reviews journey to understand what happens before, during, and after a Veteran chooses a review option, connecting the digital experience to decision letters, forms, evidence requirements, and downstream processes.
Research
Led discovery and evaluative research to understand how Veterans interpret decision review options, where the existing experience created confusion, and what information they needed to make an informed choice.
Impact
Helped transform a complex, policy-driven process into a clearer decision-making experience designed to help Veterans understand their options, compare paths, and move forward with greater confidence. The experience progressed into development and was coded in staging while continuing through policy and legal review when my work on the project ended.
Reflections
Onramp reinforced something I have seen throughout my career: simplifying an experience doesn't mean the underlying problem becomes simple. Often the opposite is true.
The most important design work happened behind the interface - understanding policy, modeling edge cases, testing our assumptions with Veterans, and continuously reconciling user needs with accessibility, engineering and legal requirements.
The result was an experience that asked Veterans relatively simple questions while carrying an enormous amount of complexity on their behalf.