Dataxplorer (DX)
Data Visualisation · Product Design
An all-in-one workspace that takes mission-driven teams from raw data to a finished chart — and eventually a published story — without leaving the page.
Deataxplorer Beta is live now.
Role
Lead UX/UI Designer
Client
In House (Zimmerman BV)
Location
Netherlands
Timeline
2024
01 / The Problem
Most of the work happens between the tools.
A program analyst at an NGO needs one chart for a donor report. She finds a dataset on the World Bank portal, downloads it, cleans the columns in Excel, uploads it to Flourish, screenshots it into a slide. Five tools, none of them talking to each other. The chart took ten minutes. Getting to the chart took two hours.
The people doing this aren't data engineers. They're researchers, program managers, and policy staff whose job is the decision at the end, not the plumbing in the middle. Every handoff is time away from that, and a new place for something to break.
DX's premise is narrow and testable: if connecting data and visualising it happen in the same place, the two hours collapse.
02 / Product overview
One workspace, one continuous flow.
DX is built around a single loop: connect data → build a chart → assemble a story. The platform exists to keep users inside it instead of bouncing out.
The connect-to-chart loop is the strongest, most reliable part of the product today. The story layer is the most ambitious and the least settled, and the part I pushed hardest to keep on the roadmap. A chart is almost never the end of the job.
DX Data Studio.
DX Data Studio
Data Studio is where data comes in: local upload, Google Drive, Microsoft Cloud, or search across 100,000+ datasets from WHO, the World Bank, and the Humanitarian Data Exchange.
DX Chart Builder
Chart Builder turns a connected dataset into a visual. 15+ chart types, with AI suggesting a starting point based on the data you brought.
DX Chart Builder.
DX Story Editor.
DX Story Editor
Story Editor is the narrative layer: a canvas for turning charts into something a donor or a public audience can read.
03 / Users
Built for the person who isn't a data scientist, but has to act like one.
The primary user is a semi-technical professional in a mission-driven context: an NGO program manager, a government data team member, a researcher, a development analyst. They're sharp and impact-focused, but time-constrained, and they don't write code. They've learned to stitch tools together out of necessity, not preference.
Designing for them meant resisting two opposite temptations: don't dumb the product down into a toy, and don't assume a Tableau-level tolerance for complexity. The brief was to find the mental models that hold for all four segments without building four different products underneath.
04 / Competitive positioning
Powerful enough to matter, simple enough to actually use.
The market splits into three unsatisfying options. High-complexity tools (Tableau, Power BI, Python) are powerful but technical and expensive, with a learning curve most program staff can't justify. Simple chart makers (Canva, Google Charts) are approachable but can't handle real data integration. And the most common option isn't a tool at all: it's a fragmented stack of Excel, Drive, Flourish, and PowerPoint held together by hand.
DX's wedge sits in the gap none of them fill: integrated enough to kill the tool-switching, accessible enough for a semi-technical user, but still able to handle real, messy, mission-driven data.
05 / Ecosystem map
Where DX sits in a mission-driven team's data life.
Before designing screens, I mapped the full system DX plugs into: where the data comes from (open datasets, government databases, research data, user uploads), what happens to it (ingestion, charting, story-building, collaboration), who touches it, and where the outputs go (data stories, dashboards, charts, reports — distributed by web, embed, share, or download).
The map did real design work, not just strategy work. It showed which parts of the journey were already well-served elsewhere — so we knew where not to build — and where the genuine gaps sat: the seam between acquiring data and first visualising it. That seam became the product's centre of gravity.
06 / Key Design Decisions
Where the real
thinking happened.
Chosen
A guided connection wizard.
A three-step flow (connect → prepare → describe & save) with clear progress, so a first-time user always knows where they are.
Alternative Considered
An open, do-anything data workspace.
More flexible, but it reintroduces the blank-canvas paralysis we were trying to remove. Power isn't useful if no one knows where to start.
Chosen
Rebuilding the mapping step around plain language.
Mapping fields to axes is where users were dropping off most. We simplified the language, improved field detection, and let the system do more of the setup automatically.
Alternative Considered
Leaving mapping technical but adding a tutorial.
Documentation papering over a friction point isn't a fix. The friction had to come out of the interaction itself.
Chosen
A small set of reliable chart types first.
Fewer types that work every time, before more types that sometimes don't.
Alternative Considered
Shipping all 15+ at full breadth.
Looks more impressive on a feature list, but a chart that fails silently costs more trust than a missing one.
07 / Designing in beta
Honesty as a
design principle.
DX wears a beta badge on purpose, and that decision runs deeper than a label. It shaped how the whole product talks to its users: clear about what works well today (connecting data and building charts) and what's still evolving (stories, deeper AI, collaboration). No apology, no overclaim.
Designing for a product that's openly unfinished is its own discipline. Error states have to teach, not just block. Feedback has to be invited without nagging. Every screen has to make a user feel the product is being built with them, not sold to them. In a tool meant for people who handle public-interest data, that credibility isn't a nice-to-have — it's the foundation everything else sits on.
08 / Reflections
What I'd carry into the
next project.
01
Focus is a design decision, not just a product one.
With broad ambition and a beta budget, the strongest thing I could do was protect one loop (dataset to chart) and make it genuinely good, rather than spread thin across every layer at once.
02
Trust is the currency of a beta.
Overclaiming on AI would have cost more than it bought. Saying less, and being right, was the better interface.
03
The unfinished part still deserves a designer's argument.
Sequencing the story builder later was the right call. Designing it well now, and keeping it on the table, is how it stays alive long enough to become what it could be.