Our Approach: Plain-Language Content Grounded in Taxpayer Research
We placed actual taxpayers at the center of our research strategy, made certain we protected their private information, and used trauma-informed practices to guide our conversations.
Human-centered Design and User Research
Taking a mixed-methods approach, we conducted over 100 hours of user interviews and testing with a wide swath of Americans who would engage with this service, focusing in particular on those with low-to-medium tax literacy.
Through these continuous user research loops, we were able to quickly identify when a design decision addressed the issues we discovered in our research. This included our validated hypothesis that long, complex content did less to improve comprehension and didn’t effectively guide users to answer questions accurately.
UX/UI Design and Design systems
As research came in, we translated our findings into a modernized flow and interface while working within technical constraints that limited how much we could restructure the experience. Our design and engineering teams leveraged the US Web Design System (USWDS) to upgrade the interface swiftly and drastically improve interactions and accessibility.
Designers worked in lockstep with engineering to identify how to configure and build the best solution to meet UX and UI needs. Progressive disclosure—showing users the most important information or feature first and giving them the option to reveal more—became a key strategy, and we found creative, intuitive solutions to help users focus on their task, anticipate what the tool would ask of them next, and feel less overwhelmed by complexity.
Implementing an Auditable Calculation Engine
“The system models tax law as less of a linear checklist and more of a web of interrelated and conditional facts. Fewer hard-coded assumptions, allowing the program to evaluate what information from the taxpayer is missing and what might be contradictory.” —Forbes
To improve maintainability, we matured a declarative logic framework known as the Fact Graph. Originally built for Direct File, this framework represented tax policy as a clear list of relationships and dependencies rather than traditional imperative code. All user inputs and mathematical calculations became separate data points within the graph.
Under this new architecture, when a taxpayer updates a single entry in the TWE, the system instantly recalculates all dependent values. To help policy experts verify accuracy, the team built the first version of a custom audit mode, which allows tax lawyers to examine the underlying logic rules during live operations.
Information Architecture (IA) and Content Strategy
Tax law is notoriously difficult to parse, and research told us much of the confusion and erroneous entry stemmed from the original content in the TWE app. We set out to simplify that content while making sure it still informed and guided taxpayers to an accurate outcome.
To do this, we needed to make the front-end of the app work for users and not strictly reflect math and tax law. Content designers worked with engineers to understand how we could restructure the IA and the order of data collection on the front end while ensuring the system received the right data on the back end.
At the screen level, we designed our content patterns to make the relationships between questions and other on-screen content clear. Drawing on our experience from Direct File translating complicated tax concepts into plain language, we rewrote the app content, working closely with stakeholders and SMEs for reviews to validate accuracy. We also staffed a bilingual content designer on the team, who translated all English content into culturally contextual, plain-language Spanish content.
Prototyping, Modeling, and Usability Testing
This project had a very tight timeline so it could be available at a key point in the tax season. As such, testing concepts quickly was important. While engineers conducted technical discovery, designers used that time to perform quick usability testing on the original app, generating validated information that gave us a head start on design direction.
We ran paired Figma design sessions with engineers, co-designed content and interfaces in real-time collaborative sessions, and built interactive prototypes to enable quick user testing. To convey interaction design patterns and easily iterate on options, engineers spun up quick CodePens. Building in-browser concepts with throwaway code enabled designers and engineers to ideate quickly and cheaply.
As implementation continued, we iterated on live code while user-testing results rolled in, and ran live accessibility testing with designers and engineers to expedite the turnaround from insight to execution.
Accessibility Engineering and Compliance
While many teams treat accessibility as a final checkpoint, it guides our decisions from initial concept through implementation. Accessibility was a launch-blocker for the TWE, so we had to get it right.
The team shifted accessibility left, with design and engineering working closely together to ensure inclusive design at every step. By embedding accessibility into early design sprints, the team reduced the amount of remediation work needed prior to production.
Our accessibility specialists performed usability testing with assistive technology users to test for true usability beyond written compliance standards. This manual testing included screen magnifiers, voice input, keyboard-only navigation, and tools such as JAWS, NVDA, and VoiceOver. We also applied the methods and techniques from Coforma’s Accessibility Playbook, and the TWE sailed through its Section 508 Audits on the first pass.
