Data Visualization · SaaS

Designing for a lot of data.

Turning sprawling spreadsheets and databases into clear, decision-ready interfaces — and making sure the right insights surfaced first.

Role Product Designer
Focus Dashboards & Reporting
Timeframe [Year(s)]
Platform Web
The challenge

Take large, messy datasets — from spreadsheets to live databases — and design interfaces that make the *important* information impossible to miss.

My role

Product designer working closely with users, PMs, and analysts to prioritize what to surface, how to structure it, and how to make it act-on-able.

Outcome

Dashboards users actually opened daily — not just at month-end — with the most-used data structured for fast, confident decisions.

The challenge

Every project started the same way: a massive dataset, a team that had been living with it in spreadsheets for years, and a creeping sense that the data was being underused because no one could see it clearly.

The goal wasn't to visualize *more* data. It was to identify which data the user actually depended on — and design interfaces that turned that data into next actions, not just descriptive charts. Doing that well requires staying close to the people who'll use the dashboard every day, not assuming what "looks like a good dashboard" from the outside.

Across these projects, the work spanned operational dashboards, reporting tools, and analytics-style interfaces — different shapes of the same fundamental design problem: making density legible.

How I approached it

Data design lives or dies on the prioritization work that happens *before* anyone touches a chart library.

01 · Listen

User input first

Workshops and interviews with the actual day-to-day users — analysts, ops leads, decision-makers — to surface which fields they actually used, not which ones existed.

02 · Prioritize

Information hierarchy

Mapping the dataset to a visual hierarchy — what shows up in a glance, what's one click away, what stays in detail views. Most of the design work happens here.

03 · Prototype

Real data, real fast

Prototyping with the user's actual numbers — not lorem ipsum — so we could feel how filters, sort order, and drill-ins behaved at real scale.

04 · Refine

Iterate with users

Live walk-throughs with the same users who shaped the brief — refining until the dashboard answered their first three questions without scrolling.

Decisions that mattered

Designing the absence of data, not just its presence

Empty states, zero values, and "no results" views got as much attention as the loaded views. In data tools, those moments are where users lose confidence — so they earned first-class treatment.

One question per screen

The temptation in data design is to show everything. We held the line on focus — each surface answered one primary question, with secondary questions one interaction away.

Filters that match how users think

Default filter sets matched the user's actual mental model (by team, by time, by status), not the database's schema. A small thing visually, a huge thing for adoption.

What changed

Specific impact data is shared in the full case study (request access below). Public-facing highlights:

Daily, not monthly

Tools shifted from "open it at month-end" to part of the daily routine — the truest signal a dashboard is doing its job.

Spreadsheets retired

Teams stopped running parallel spreadsheets to make sense of the data — the dashboards became the source of truth.

Faster decisions

Self-reported time-to-decision dropped meaningfully across the user groups we interviewed post-launch.

Scaled gracefully

The visual system held up as new data sources, new filters, and new user roles got added over time.

What I'd carry forward

Prioritization is the work. Once you know which two or three things the user actually needs to see, the visual design becomes obvious. Without that, no chart library will save you.

Real data exposes everything. Designs that look beautiful with placeholder data fall apart at scale — prototyping against live datasets is the only honest way to design these tools.

Adoption is a design metric. A "successful" dashboard that no one opens is a design failure, full stop. Designing for the daily use case is where the value lives.

Request full case study

Want to see the actual dashboards?

The complete case study — with screens, IA artifacts, and measured outcomes — is available as a password-protected PDF. Drop your details and I'll send it over.

Password-protected & watermarked. Sent within 1 business day; password follows in a separate message.

Something went wrong. Please try again or email blrwelch@gmail.com.

Request received — I'll be in touch shortly.