Reading and structure
Document reading sequence, headings and meaningful content relationships.
USAA · Design systems · Accessibility · Design QA
I connected reusable patterns, accessible handoffs and defect analysis to help my team improve the work, then brought the approach to the wider design organization.
My team, within six months of the new QA strategy, compared with the previous reporting.
Team outcome reported internally, reflecting the combined QA strategy and accessibility work.
The problem
USAA’s Reveille Design System provided a common foundation. Applying it consistently across responsive web experiences required more than selecting a component: teams needed to agree on its intended use, accessibility behavior and the member journey around it.
As my team’s appointed QA Advocate, I met with other advocates one to two times per month to discuss Foundation Review defects, including incorrect component usage and accessibility markup. One reporting cycle raised a question: did the defect totals accurately describe the quality of what designers handed off?
01 · Investigate, pilot, influence
I started with my team’s defect data. Using data analytics, AI and Excel, I investigated reporting inconsistencies and performed root-cause analysis. That work helped me propose a clearer definition of a defect within the scope of the design handoff.
Use the team’s reported defects to identify inconsistencies and root causes.
Define defects against the intended design handoff and apply accessibility expertise.
Test the QA strategy and track Foundation Review results over six months.
Present findings to QA and Design System directors and other stakeholders.
Explanatory reconstruction of the process, based on my account. This is not a reproduction of an internal reporting dashboard.
The pilot and my accessibility work helped my team reduce Foundation Review defects by 50% within six months. My presentation secured buy-in for implementation across the design organization. The wider organization also saw a substantial decrease in reported defects.
02 · Accessibility in the design handoff
In disputes, I used accessibility markup to communicate how members should understand and navigate the experience. QA and development had access to screen readers and other testing tools, and we consulted with the EOA team.
Document reading sequence, headings and meaningful content relationships.
Distinguish keyboard focus order from reading order; describe behavior as the flow changes.
Make labels, instructions, status and error messages understandable beyond their visual treatment.
Illustrative handoff categories. An annotated disputes screen will provide the next supporting artifact.
I bring accessibility into early design decisions, carry it through the handoff and help teams understand the rationale. My aim is to design beyond minimum requirements and to include people with disabilities in research and evaluation wherever possible.
03 · Contribute for reuse
I worked regularly with the Design System team to understand the core concepts behind Reveille, improve my team’s QA and contribute when our feature work exposed a missing pattern or component. Research, testing and consultation with other designers helped establish whether a solution could serve multiple experiences.
Pattern alignment
My first contribution examined confirmation screens across responsive web experiences. Teams differed in how they communicated success, task completion and what happened next. I researched and contributed to the shared patterns and component blocks.
Component delivery
A badge was already in the system backlog, but my feature needed it during the sprint. I consulted teams with similar needs, designed the initial concept and worked with Design System designers and developers to implement the badge for production use.
Reusable guidance
Before members entered the disputes flow, I built a reusable component explaining the tasks ahead. It set expectations for the next screens and the path to confirmation.
Other work included data-table enhancements, messaging, data visualization and member task flows. Across these contributions, I balanced an immediate delivery need with the system’s value to other teams.
What changed
The lesson: a quality metric is only useful when teams understand what it measures. Challenging the reporting model constructively, testing a change within my team and communicating the evidence gave the organization a stronger basis for action.
Explore the disputes experience →