Dataexplorer (DX)
Data Visualisation · Product Design · 0→1 Beta · Lead
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.
DataXplorer is in open beta.
00 / Metadata
2025 – Present
•
led design to the first usable beta.
01 / The Problem
Most of the work happens between the tools.
A program analyst at an NGO needs one chart for a donor report. To get it, she finds a dataset on the World Bank portal, downloads it, opens it in Excel to clean the columns, uploads it to Flourish to make it look decent, then screenshots it into a slide. Five tools. None of them talk to each other. The chart took ten minutes; getting to the chart took two hours.
This is the tax on mission-driven data work. The people doing it aren't data engineers — they're researchers, program managers, and policy staff whose actual job is the decision at the end, not the plumbing in the middle. Every handoff between tools is time taken away from the work that matters, and a new place for something to break.
DX's premise is narrow and testable: if connecting data and visualising it happened in the same place, the two hours collapse. No context switching between finding data and seeing it.
02 / Product overview
One workspace, one continuous flow.
DX is built around a single loop: connect data → build a chart → assemble a story. The whole platform exists to keep a user inside that loop instead of bouncing out of it.
Data Studio is where data comes in: local upload, Google Drive, Microsoft Cloud, or search across 100,000+ datasets from sources like WHO, the World Bank, and the Humanitarian Data Exchange, all importable without leaving the page.
Chart Builder turns a connected dataset into a visual, with 15+ chart types and AI that suggests a sensible starting point based on the data you brought.
Story Editor is the narrative layer — a canvas for turning charts into something a donor or a public audience can actually read.
I'll be straight about where each stands: 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've pushed hardest to keep on the roadmap, because a chart is almost never the end of the job. More on that later.
DX Chart Builder.
DX Data Studio.
DX Story Editor.
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.
09 / 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.
Dataxplorer is in open beta.