Designing CHARLIE — Translating Federal Health Data into Community-Ready Insight

Role: UX Design, Product Design & AI Integration (independent, solo build)
Tools: Bubble.io (no-code development), Anthropic Claude API (via Bubble's API Connector), Health Equity Tracker (HET) public API, vanilla JavaScript (ES6), custom D3-based charting components
Timeline: 2025 (built independently over a fixed pre-accelerator program period; development has continued under other contributors since)

Context

CHARLIE — the Community Health Analytics & Responsive Learning Intelligence Engine — is a mobile-first, AI-powered platform built around a simple premise: federal public health data is extensive, but it isn't built for the people who most need to act on it. My work on CHARLIE grows directly out of prior work maintaining the Health Equity Tracker (HET), a public health data platform built in partnership with Google.org, which gave me deep familiarity with the underlying federal datasets, the standardized data pipeline behind them, and the ways that infrastructure had — and hadn't — been designed for non-expert users.
CHARLIE's underlying concept originated with a colleague, who first proposed it — in a more resource-intensive technical form — to an outside AI grant program that ultimately didn't fund it. The version described in this case study is one I designed and built independently, from the ground up, using a completely different technical approach: Bubble's no-code platform and Anthropic's Claude API directly, rather than a custom fine-tuned model and a dedicated cloud AI pipeline. Where the original concept needed institutional infrastructure to exist, I wanted to see how much of that same value I could deliver with a single developer, an existing public API, and an off-the-shelf LLM.
The mission stayed consistent across both versions: build tech that works at the intersection of health, tech, and justice. HET itself has organically broadened well past its original policymaker- and researcher-facing audience over the years I've worked with it. CHARLIE is my attempt to close the remaining gap — to lower the technical and health-literacy barrier enough that someone with no research background can still open the app and understand what the data means for their community.
The Bubble-based version I built was scoped to that fixed program period. Once it wrapped, the ongoing cost of independently hosting and running an unfunded, solo-maintained no-code app grew beyond what made sense for me to keep covering, so I stepped back from active development in Bubble. Since then, the engineers who maintain HET itself have taken the API-integration approach I built and folded it into HET's own infrastructure, continuing that work independently of me. I don't have current visibility into where it stands today, but the fact that the underlying approach outlived my own build is, to me, one of the more meaningful outcomes of the project.

The Problem

Three challenges shaped CHARLIE's design:

1. A literacy gap, not just a data gap. HET's underlying datasets are accurate and comprehensive, but they're written and structured for people who already know how to read them. Making that data useful to a non-expert meant translating it into plain language without flattening its accuracy or undermining its credibility as an official source.
2. An API that assumes you already know what you're looking for. The HET API requires the exact dataset filename up front (healthequitytracker.org/api/dataset?name=[filename].json) rather than supporting exploratory queries — a single URL, a single key-value pair, no room for ambiguity. A user who wants to ask "how does asthma affect Black children in my county compared to the state average" has no way to express that request directly. Something had to sit between what a person means and what the API requires.
3. Trust as a prerequisite for adoption, not a feature of it. In a health equity context, algorithmic bias can determine who gets diagnosed, treated, or overlooked. For a tool meant to serve people who are often on the receiving end of extractive data practices, the choice of AI partner needed to function as a trust signal from the first interaction, not an implementation detail buried in the backend.

Design Process

Choosing a different path to the same idea

Rather than build toward the fine-tuned, infrastructure-heavy version originally proposed, I scoped CHARLIE down to what a single developer could actually ship: a no-code front end on Bubble, calling Claude directly for language generation, and calling HET's existing public API for data — no new model training, no new backend. That constraint shaped almost every decision that followed. It also meant starting broad and narrowing on purpose: HET tracks 62 base health metrics (at the time of this writing), and rather than trying to support all of them at once, I focused the first working version on gun violence data specifically — both because it's an area I'd already done recent work in, and because narrowing the scope let me get a complete, working flow in front of real users faster than trying to generalize across every metric HET supports.

Building a translation layer between plain language and precise data

Because HET's API can't handle exploratory queries, the core of CHARLIE's UX is a multi-step, "MadLib"-style selector: a user picks a health topic, a geography, a demographic group, and a time period in plain language, and the app constructs the precise dataset filename the API actually requires behind the scenes. This wasn't a pattern I invented for CHARLIE — HET already had an early, beta version of this same fill-in-the-blank interaction in one of its charts, and deconstructing that existing feature was the direct starting point for CHARLIE's own selector flow. Once a query resolves, it feeds a prompt to Claude, which returns a structured analysis broken into consistent sections — Key Finding, Location Comparison, Demographic Insights, What This Means, and Recommendations — so the output reads the same way every time, regardless of topic.

Choosing an AI partner as a design decision

Selecting Anthropic's Claude API wasn't just a technical integration choice. In a health equity context, algorithmic bias can quite literally determine who gets diagnosed, who gets treated, and who gets left behind — which made the provider's approach to bias and safety part of the product's own credibility, not a backend detail. I also cared about keeping this sustainable as a solo-built project: the Claude integration itself ran at an estimated cost of well under a dollar a week. The broader cost of independently hosting and running the app turned out to be a separate problem — one that ultimately shaped how long I could sustain the build on my own.

Designing for the seams

I initially planned to build CHARLIE in Bubble's beta mobile builder, but the JavaScript required to parse and clean up Claude's response before displaying it wasn't well supported there, so I moved the build into Bubble's standard web environment (wrapped for mobile) instead. Separately, I ran into Bubble's split execution context — JavaScript actions and native Bubble workflows don't share scope directly — which meant I had to explicitly pass data as parameters between the two rather than assume either side could reach into the other's state. Neither of these was a visual design problem, but both were UX problems in the sense that mattered most: an unreliable render or a silent JavaScript failure is, to the end user, indistinguishable from the app simply not working.

Reflection

Working on CHARLIE independently — after watching a more resourced, institutionally-backed version of the same idea go unfunded — has been a real lesson in scoping ambition to what's actually buildable by one person. I didn't have a fine-tuning pipeline or a dedicated AI governance team; I had a no-code platform, a public API, and an LLM I could call directly. Getting a genuinely useful version of CHARLIE working within those constraints required treating every limitation — the HET API's rigidity, Bubble's execution model, even the mobile builder's gaps — as a design problem to solve rather than a reason to wait for more resources.
It's also sharpened how I think about credibility. Because CHARLIE's target users are people who have reason to be cautious about both government data collection and AI, I've had to treat things like AI-provider selection and output structure as part of the actual user experience, not invisible implementation choices. And because I'm still actively refining the app — the AI-output rendering, in particular, still has rough edges I'm working through — this project has also been a reminder that "working" and "polished" are different milestones, and that being honest about which one I've actually reached is part of representing this work accurately.
Stepping back from the Bubble build once it stopped being sustainable for me to run solo was its own lesson — that a no-code, single-developer architecture has real limits once a project outgrows a structured, time-boxed program, and that knowing when to hand something off is as much a design decision as any of the ones I made while building it. Watching the underlying approach get folded into HET's own infrastructure afterward, by the engineers who maintain that platform full-time, has been a genuinely useful way to see which parts of the work had lasting value independent of the specific tool I built it in.
Beyond CHARLIE's specific features, this project has been a case study in independently carrying a concept from idea to working software: taking something a colleague originated, choosing an entirely different technical path to get there, and being accountable for every design and engineering decision along the way — including the decision about when my part of it was done.