Case study
AXIOM Data Visualization
AXIOM Data Visualization
A visualization system for making complex financial data consistent, accessible, and easy to read.
Senior UX designer · Edward Jones
Role
Senior UX designer
Timeline
2021
Scope
Chart families, interaction states, accessibility, docs
Outcome
Adopted across products
Role
Senior UX designer
Scope
Chart families, interaction states, accessibility, docs
Timeline
2021
Outcome
Adopted across products
The challenge
Across the platform, every team was building charts their own way. The result was visual drift, inconsistent interactions, and constant rework, and for the people reading the data, more effort than the numbers warranted. Financial data is dense and varied, from single KPI tiles to multi-series comparisons, and it served two audiences at once: advisors who need detail and clients who need a quick, confident read. The work was to give all of it one consistent, accessible visual language.
Across the platform, every team was building charts their own way. The result was visual drift, inconsistent interactions, and constant rework, and for the people reading the data, more effort than the numbers warranted. Financial data is dense and varied, from single KPI tiles to multi-series comparisons, and it served two audiences at once: advisors who need detail and clients who need a quick, confident read. The work was to give all of it one consistent, accessible visual language.
What I inherited
Charts scattered across more than forty screens, almost none of them agreeing. Labels, legends, scales, and interactions varied team by team, with no shared rules and no tokens underneath to enforce consistency. Accessibility was uneven, and color was often doing work it shouldn't, carrying meaning on its own. There was real range to account for too: long labels, multiple currencies, negative values, tight spaces, and dark mode. The raw material was a pile of one-offs that needed to become a system.
Charts scattered across more than forty screens, almost none of them agreeing. Labels, legends, scales, and interactions varied team by team, with no shared rules and no tokens underneath to enforce consistency. Accessibility was uneven, and color was often doing work it shouldn't, carrying meaning on its own. There was real range to account for too: long labels, multiple currencies, negative values, tight spaces, and dark mode. The raw material was a pile of one-offs that needed to become a system.
My role
I led the unification effort end to end. I audited the existing charts, named the handful of jobs they actually needed to do, and defined the rules underneath them: labels, legends, scales, color roles, tick density, tooltips, and keyboard and screen-reader behavior. I built the chart families into the design system as token-based components, paired with engineers on implementation, piloted them on real screens, and wrote the guidance teams would build from. The aim was a library flexible enough to carry advisor-grade density and client-facing legibility from the same primitives.
I led the unification effort end to end. I audited the existing charts, named the handful of jobs they actually needed to do, and defined the rules underneath them: labels, legends, scales, color roles, tick density, tooltips, and keyboard and screen-reader behavior. I built the chart families into the design system as token-based components, paired with engineers on implementation, piloted them on real screens, and wrote the guidance teams would build from. The aim was a library flexible enough to carry advisor-grade density and client-facing legibility from the same primitives.
Key decisions
Decision
Reduce every chart to a few core jobs and build primitives for those, not a chart per request.
Reduce every chart to a few core jobs and build primitives for those, not a chart per request.
Reasoning
Auditing the screens showed the charts were really doing only a handful of things: trend, comparison, part-to-whole, rank, spread. Designing for those jobs meant consistency came from the structure rather than from policing each new chart.
Auditing the screens showed the charts were really doing only a handful of things: trend, comparison, part-to-whole, rank, spread. Designing for those jobs meant consistency came from the structure rather than from policing each new chart.
Tradeoff
It required building the system before any single chart shipped, and it left less room for bespoke one-off visuals.
It required building the system before any single chart shipped, and it left less room for bespoke one-off visuals.
Decision
Serve advisors and clients from the same components, with density and legibility as settings.
Serve advisors and clients from the same components, with density and legibility as settings.
Reasoning
It was the same underlying data read two ways. One system tuned by setting avoided two diverging libraries and the double maintenance that comes with them.
It was the same underlying data read two ways. One system tuned by setting avoided two diverging libraries and the double maintenance that comes with them.
Tradeoff
Every component had to hold both extremes at once, which is harder than designing for a single audience.
Every component had to hold both extremes at once, which is harder than designing for a single audience.
Decision
Build accessibility and the empty, loading, and error states into the primitives, not a later pass.
Build accessibility and the empty, loading, and error states into the primitives, not a later pass.
Reasoning
Those were exactly where the ad hoc charts broke. Making contrast, color-independence, keyboard order, and defined states part of the component meant teams got them by default.
Those were exactly where the ad hoc charts broke. Making contrast, color-independence, keyboard order, and defined states part of the component meant teams got them by default.
Tradeoff
It constrained the palette and added scope, since every chart now had to specify its edge behavior, not just its happy path.
It constrained the palette and added scope, since every chart now had to specify its edge behavior, not just its happy path.
Selected artifacts
A few pieces of the system, and what they were built to solve.
Chart specimens: frames, scales, legends, and keys defined once so every team draws from the same vocabulary. The point was rules, not pictures.
Guidelines and components: the handoff layer. Tokens and specs are what let engineering build the charts without reinterpreting them.
Outcome
The library replaced a sprawl of one-off charts with a cohesive system built from a common set of components. Builds got faster and review cycles got shorter, because visuals and behavior were now predictable, and the data itself got easier to read once labels, legends, and states were consistent. Engineering handoffs ran on tokens and specs instead of reinterpretation. New visualizations could be assembled in nearly half the time, since teams composed from shared primitives rather than reinventing chart logic each build. The system was built so new chart types slot into the same rules as they are needed.
The library replaced a sprawl of one-off charts with a cohesive system built from a common set of components. Builds got faster and review cycles got shorter, because visuals and behavior were now predictable, and the data itself got easier to read once labels, legends, and states were consistent. Engineering handoffs ran on tokens and specs instead of reinterpretation. New visualizations could be assembled in nearly half the time, since teams composed from shared primitives rather than reinventing chart logic each build. The system was built so new chart types slot into the same rules as they are needed.
A chart is a decision aid before it is a visual artifact. The work was making complex data read consistently, whether the audience was an advisor looking for detail or a client looking for confidence.
© 2026 Arman Musaji
Email: