Introducing data visualization to fund comparison
Investors already had every number they needed. Reading them was the hard part. In a regulated product you can't remove the complexity, so I changed how it was shown: the same data, in a format people could actually compare.
The comparison table held a lot of financial data for users who needed all of it. The problem was not access, it was that reading it was harder than finding it. The business wanted charts. I worked out where a chart genuinely helped, what format it should be, and how to make it readable without relying on colour.
I turned a one-line brief into the first data visualization the comparison tool ever had, and led the Sketch to Figma migration while doing it. Short moderated rounds on UserTesting.com, the flows and the analysis myself, the chart formats defined with engineering, and the specifications they built from. Compliance reviewed everything.
Three things happening at once
None of the three were negotiable, and all three shaped every decision I made.
Compliance
Financial products are legally required to display certain figures, disclaimers, and risk indicators. Nothing could be hidden or summarised away.
Accessibility
WCAG was a requirement, not a nice to have. Contrast, type sizes, focus order, and never letting colour be the only thing carrying meaning in a chart.
A system mid-migration
The team was moving from Sketch to Figma while this shipped. I led that migration, so every component I designed had to work as a decision for the whole library.
The brief was "add data visualization". I decided what that meant.
It came in as a business idea, not a specification: charts would make the comparison tool better. Nobody had said which data, in which format, or where a chart would actually help. That was the work.
These are technical users. They know what they are looking for and they need every figure on the page, so "show less" was never the answer. The real question was narrower and more useful: where does a chart earn its place, and where is it just decoration? I ran short rounds on UserTesting.com to find out which sections of the table benefited from a visual comparison. The answer was: not all of them.
Start where the company was looking
Sustainable funds were a firm-wide priority, and it was the right call on the merits too: their indicators genuinely reward being compared side by side.
Bars, not pie charts
Pie charts looked richer and answered a question nobody was asking. Comparing several funds on one indicator is what bars do best. I tested it instead of assuming.
The numbers never leave
The chart sits with the figures, it never replaces them. Compliance needs the number, the investor needs the pattern, and both stay on screen.
The comparison had to work for everyone
Four funds, four colours, and colour was the only thing telling you which bar was which. That leaves out anyone with a colour vision deficiency, and it stops working the moment the page is printed in black and white. Contrast ratios do not fix it, because the problem is not legibility, it is identification.
So the bars carry a second signal: fill patterns, one per fund, matching the legend, that a user can turn on. Colour still does the fast, comfortable work for everyone who can use it, and it stops being the only thing that does.
An example of how the chart looked with the accessibility setting switched on.
The standard I took from BlackRock
Most of what follows was the BlackRock standard, not my invention. It is a company with a lot of rules and real design maturity, especially around accessibility, and this was simply how work got handed over. Being held to that bar is what taught me what a good delivery looks like.
What was mine was the migration from Sketch to Figma, which I was responsible for inside iShares, on our product rather than across the company. Rebuilding every component was the chance to update things that had not been touched in years, and to make accessibility part of what "migrated" meant instead of a separate request nobody had time for.
The other half was working with engineering, and it is the part I am most proud of. The specifications got good because they told me which questions kept coming up while building, and I started answering those before they were asked. Designing the chart formats with them, rather than handing over a picture of a chart, is what made them buildable.
I would not hand a team this exact file now. Most of this contract lives in Storybook, and BlackRock had one too. But there was still a Figma master where the specifications were kept: you changed it there, and it flowed down into the library. I took that idea with me. The checkout and upsell library I built at Jimdo works the same way, on a team that did not have the practice before.
Every breakpoint, in every market
Mobile, tablet and desktop at every resolution, drawn separately for the UK, German and US sites, with real funds and real string lengths.
Behaviour, not just appearance
How each component behaves and how it looks in each state, written down rather than left to whoever builds it.
One fund, three funds, four, or none
Every combination drawn, because a comparison tool spends most of its life part-filled.
Accessibility as its own page
The criteria the build had to meet, each one written out and shown with an example.
Redlines, down to the pixel
Spacing, sizes and distances marked directly on the screen.
What the migration changed
- Sketch library, inconsistent between teams
- Type and spacing decided per screen
- Contrast failures shipping unnoticed
- Handoff as a static file plus a conversation
- Figma library other teams could build from
- One type scale and spacing system
- Contrast checked as part of the component definition
- Specs with states, focus order, and edge cases
Results after launch
increase in engagement with comparison tables on desktop
A Figma library other teams built on, migrated from Sketch during the project
Contrast and type fixed as part of the component definition, not as a later pass
The first chart is the expensive one. Not to design, to argue for: it is the one that has to win the case that a visualization belongs on that page at all. Mine was the first the comparison tool ever had. That exact view is gone now, the product has been rebuilt since and I had nothing to do with what replaced it, but visualizations are standard across iShares today. Making the case the first time is the part I would do again.
We shipped mobile comparison without testing the premise
We knew comparing several funds on a phone might not be worth much, and we built it anyway. The reasoning was not careless: our users were overwhelmingly on desktop, that is where every round of testing ran, and parity across breakpoints was already the plan. Given what we knew at the time, shipping it was a defensible call.
What I would change is that we never spent one round finding out. We were slow to revisit it, and when we finally did, the answer matched the doubt we had started with. It was deprecated after I left.
The lesson is about which question gets tested, not how much testing there is. A doubt the team keeps repeating out loud is already a research question, and usually the cheapest one on the list. Testing the design and not the premise is how a team ends up with a well-made thing nobody needed.
Hola, I'm Lu. Senior Product Designer, 8+ years across different industries. I start with the real problem, make complexity understandable, and stay close to the outcome.
More about me →