The U.S. Department of Veterans Affairs (VA)
The PACT Act expands VA health care and benefits for Veterans exposed to burn pits, Agent Orange, and other toxic substances. This law enables the Department of Veterans Affairs (VA) to provide generations of Veterans and their survivors with the care and benefits they have earned and deserve. However, the VA needed to synchronize the digital version of the 526ez form with the paper version by adding toxic exposure questions and content. Key changes included updating the form flow and information architecture to enhance usability and reduce the burden on Veterans.
Collaborating on the design and data mapping of the 526ez form presented several challenges, making it the most extensive full-stack feature our product team had tackled to date. The reason being, paper and digital forms are fundamentally different. For example, paper forms maximize the use of each page to save on paper and printing costs, whereas VA digital forms follow the "One Thing per Page" guidance. This guidance requires dividing long forms into multiple smaller sections that make up a logical series of pages or steps. As a result, mapping questions from paper to digital was not one-to-one, and our team had to troubleshoot fitting new questions into the existing 526ez digital flow.
Additionally, understanding how Veteran Service Representatives (VSRs), who assist Veterans with their claims for benefits, and Rating Veteran Service Representatives (RVSRs), who evaluate and decide claims for VA benefits, would use the form data was critical to optimizing data collection from Veterans. We also faced external technical dependencies with the Lighthouse API and the VA Component Library, which required careful coordination and technical skill to ensure functionality.
Collaborating on Design and Data Mapping
This initiative required a significant team and cross-team effort, involving numerous meetings, collaboration, and brainstorming sessions to achieve our current results, which are still in progress. Using Mural proved very effective for the team. By comparing screenshots of the paper/pdf form alongside the downstream Lighthouse API and proposed mocks, we identified and addressed gaps, aligning everything smoothly.
Writing and refining detailed stories and tickets was essential for ensuring we built the right features with clear acceptance criteria. This detailed planning helped maintain clarity and focus throughout the development process. Additionally, our retrospective discussions on the team’s Quality Assurance (QA) process were invaluable, as they allowed us to improve the quality of each product increment with every story.
Implementing a New Multiple Response Flow
During implementation, we discovered the existing tooling for the multiple-responses flow could not support the checkbox-driven, multiple-page flows proposed in the designs. We collaborated with the VA Forms team, who developed a proof of concept (POC) to build the flow using the existing tooling.
Below is a map showing how the digital form’s questions will populate the PDF. Note that question 15A (a yes/no checkbox) is not explicitly asked on the digital form but is derived from a question with checkboxes. The design also rectifies the limitations of the paper form. For example, question 15B only asks for a yes/no answer and a single date range, while the digital form can provide multiple date ranges associated with specific locations or hazards.
Using the proof of concept mentioned earlier, our team built the pages shown in the screenshots, which we call the "Checkbox and Loop Flow" (as opposed to the "List and Loop Flow" in the VA Design System). This approach adheres to the "One Thing per Page" guidance. When a Veteran selects one or more locations on the first page, they then see a separate page for each selected item to add additional details, such as optional date ranges.
The digital form is used to populate a PDF version, which the VA then uses to process the claim. We went full circle: paper → digital → paper.
Our team not only integrated these new pages into the digital form but also made several improvements along the way. We added toggle awareness to the end-to-end tests, performed automated regression testing to ensure we didn't disrupt the existing form 526 flows currently in production (toggle disabled), and implemented new feature testing as we built each page (toggle enabled).
Contributor: Christine Cereca, Lead Frontend Engineer
