I helped modernize a two-year-old geographic audience builder inside LettrLabs’ automation flow. The ask was to fix map bugs. The deeper problem: customers often needed Customer Success just to create an automation. So I shifted the work from “make the map better” to “help different users build audiences without getting blocked.”
The redesign shipped to production, clearing audited blockers on the primary targeting path and addressing the first phase of tracked map-and-automation tickets. I defined one audience model for five entry points, with CSV upload, saved areas, and exclusions deliberately phased for later releases.
Usage and revenue figures come from internal analytics, rounded.
An old audience builder buried in the automation flow, with one way in: open the map, draw a shape. Think in ZIP codes, already have a CSV, want last month's area again? No entry point. So people called Customer Success or filed a ticket, and the same blockers showed up in both.
I led the audience-builder design end-to-end and changed the brief from "fix the map" to "help different people build an audience without getting stuck." ~20 customer interviews sorted into 4 user mental models; I translated them into one audience model with five entry points. Another designer handled the surrounding automation.
Phase one shipped the map-first workflow and core targeting controls. The full five-entry-point model was defined for phased delivery, so later releases could add CSV upload, saved areas, and exclusions without reopening the interaction model.
It looked like a bug-fix pass on an old map. But the map wasn't the problem—the workflow around it was: setup gates, dead clicks, missing controls, and work people had to redo. So the real job was never the map controls. It was the way people already think about building an audience.
Before betting the redesign on that hunch, I checked it against every source I could get—comparing where people got stuck against where they moved easily:
The strongest signal was not that the UI looked old. It was that the product kept saying “not yet” without helping customers move forward.
Read together, the blockers weren't random—the old flow treated everyone like one user: open the map, draw a shape, continue. But four mental models each expected a different way in, so the fix was to support all of them, then consolidate into one audience.
These personas did not need different products. They needed one audience-building workflow that could adapt to how they already thought about the task.
Operators already comfortable with audience controls and refinement logic. They start from CSV upload, include / exclude rules, and filtering—so import has to be fast, refinement precise, and complex edits reliable enough to hold together.
People who already know the geography they want to target—usually a ZIP, city, county, or state. Geographic selection has to work directly, without forcing drawing tools as the default path.
Customers returning to a workflow they have already configured before. They start from saved, reusable locations, so reuse has to be quick and carry continuity from prior campaigns with minimal rebuild.
People who still need the visual reassurance of the map to orient themselves. They start with map-first exploration, so the product needs clear entry actions, visible guidance, and map feedback that teaches the workflow as they go.
Rebuilt from the audit and behavioral data: phase-one improvements alongside the complete phased model that guided later releases.
Must name the automation before adding any location—a setup gate.
Mild frictionJump straight into building the audience; setup gates removed.
At easeBlank map assumes you'll draw—no path for ZIP, CSV, or saved areas, and the first clicks do nothing.
ConfusedPhase one made map-first search and geographic selection usable; CSV upload and saved areas were specified for later phases.
Clearer startNo include/exclude—trim by deleting addresses one by one.
TediousInclusion controls shipped; exclusion was specified for the later refinement phase.
More controlFiltering was slow enough that the primary path felt broken.
ImpatientFiltering optimized to hold up at scale, so narrowing an audience doesn't stall the flow.
Kept movingOverlapping selections are hard to read—no clear total to check.
UnsureOne consolidated audience—clear reach and cost.
ReassuredSupport becomes part of setup—31 map-related tickets logged.
BlockedA clearer self-serve core reduced setup friction; saved-area reuse was phased for later delivery.
Ready to launchThe fork was task-first—let people pick how to start (search, saved area, upload) before touching the map—versus map-first, the existing, proven behavior. I shipped map-first to keep the launch low-risk on the surface almost every automation depends on, and documented task-first as an A/B hypothesis for a later phase. The version I'd design and the version that's safe to ship aren't always the same one—choosing which goes out, and when, is the job.
My first proposal gave clear entry points before any map interaction—search a place, define an area, reuse a saved area, or upload a CSV—because not everyone arrived ready to draw; the entry point had to match how they already thought about the task.
Why the concept changed
Their research showed customers approached audience creation differently—one rigid map-first path didn't fit the clustered personas.
Multiple entry points could still resolve into one audience model—easier to reason about than separate one-off workflows.
Support was mostly about reaching the audience customers already had in mind, not teaching more map interaction.
The final compromise kept the map prominent, but the product logic shifted. The job stopped being a better map screen and became a shorter, less fragile path to an audience—without giving up the map-led experience the business wanted.
That shift helped me decide what belonged in the experience and what stayed secondary. I specified search or region selection, CSV upload, saved areas, radius, and polygon as paths into the same model—so every entry point converges into one audience and people focus on total reach and cost, not the tool they used to get there.
Prototype walkthroughs show three representative paths through the shipped core and planned refinements.
I made the cost of each decision visible so PM, business, design, and engineering could align faster.
Was ~20 interviews enough to design from?
A confident sample is closer to 50, and PM and Customer Success ran these—so they were customer conversations, not a structured study.
Six weeks left no room for a proper research round, so I treated the interviews as one signal, not the answer. I triangulated them against Hotjar, support tickets, my own audit, and the AI walkthroughs, and only called something a blocker when it showed up in more than one source.
Run a structured round at ~50 participants, with a researcher, before the next phase.
Start with tasks or start with the map?
Task-first was clearer for CSV and saved-area users.
I shipped map-first: it was the proven behavior and the lower-risk choice on a surface almost every automation depends on. Validating task-first before launch would have delayed a release the business needed out, so I documented it as the next experiment instead.
I would still A/B test task-first.
Should clicking the map become the main interaction?
One-click selection was powerful, but folding radius, polygon, and place selection into one control would overload it.
I kept radius and polygon as primary CTAs and made place selection available through clearer map controls.
Test a combined select mode once there is more usage data.
Ship everything at once, or phase it?
A full release would be cleaner, but the scope touched targeting, filtering, saved locations, CSV, exclusions, and QA.
I scoped it so useful improvements shipped inside the window instead of waiting on an all-at-once rollout.
Use faster feedback loops between phases.
I built the first interactive prototype in Codex—AI-assisted, so PM, business, and engineering could click a running product instead of imagining static Figma screens (a first for the team, so I wrote up the workflow for other designers). That's where validation happened: feeling out how it selects and adds places is what made clicking the primary way to build an audience, and it gave engineering something real to pressure-test.
View Initial PrototypeHow prototyping changed the workflow
It also taught me to design with the constraints, not around them. The prototype reframed the map-provider call—this is an overlay-first service-area editor, not a navigation tool, so boundary rendering and visual control mattered more than Google's place familiarity—moving engineering from Google Maps to MapTiler (over Mapbox and MapLibre), with the edge cases and interaction model settled before any production code. My job was to define what had to stay legible—geographic selection, radius, polygon, large-dataset rendering, exclusions—and to hand off the concept and trade-off, not just the screen, so review became a product conversation.
This workflow sat on the critical path for automation, so waiting for a perfect release was not an option. I phased the work instead, so customers got the useful parts earlier and I could collect feedback between phases before investing in later functionality.
I first standardized the Figma system around shared variables and built a checker for outdated layers, then used it as the source for AI-generated clickable flows and component guidance. Later, independently, I extended it into a coded React library with Storybook and machine-readable specs; at work, the immediate payoff was prototypes built from the real system's recipes, states, and copy—not a mock that would drift.
Read the design system case study →Brand personality, when to be brief versus instructive, length limits per surface, grammar rules. Structured, so designers and AI both write copy that already sounds like the product.
Every component documented—shared styling, the CSS where it matters, explicit do's and don'ts—so reuse follows one source of truth, not tribal knowledge.
Patterns, common violations, known deviations. Any new design gets audited against it, so problems come back as rule-breaks instead of opinions.
A map-based tool is exactly where accessibility gets skipped—but because the rules live in that system, it was a constraint from the start. Here's what it held to on the shipped UI. (Ratios sampled from the shipped LettrLabs UI.)
The interaction model brings search or region selection, CSV upload, saved areas, radius, and polygon into one audience-building context. Phase one shipped the map-first path; the remaining entry points are designed for the later phases shown above.
The interactive prototype loads only when you press play.
The win was not a cleaner interface. It was a workflow that matches how customers actually build audiences.
Audit and observed-session evidence showed 6 steps before a single area was drawn, with roughly 3 repeated per additional location. I defined search or region selection, CSV upload, saved area, radius, and polygon as one model; phase one shipped the map-first path and core targeting controls.
Step counts from the UX audit and 20 observed customer sessions.
The redesigned audience builder shipped on the surface behind ~95% of automations and serving the 3 enterprise accounts carrying ~75% of revenue.
4 map providers were evaluated and the interaction model was specified across ~55 states spanning 13 flows, with entry methods, calculation states, and failure cases defined for QA.
The remaining 16 issues were scoped across later releases for CSV upload, saved maps, and exclusions. Ticket deflection and completion are the next measures to validate as those phases ship.
My strongest rejected idea was a task-first entry: pick the map, a CSV, or saved locations up front. It would have helped people who arrive with a clear job—but some customers need the map first to orient and trust the flow.
What I'd do with more time: A/B the task-first entry against the shipped map-first flow, per persona—tracking time to first audience, map CS tickets, completion, filtering abandonment, saved-location reuse, and paid-filter conversion.
Audience creation outside automation. Build an audience once, save it, and reuse it across automations. It didn't fit the first release, but it's the better architecture—it narrows the on-screen job to one thing.
Live insight on the map. A real structure or household count as you select an area. Today that's a separate pass on USDA-backed sources; once the data is self-hosted, the map can show it while you draw.
Paid audience insight. The same audience model could support LettrLabs-owned data, premium filters, and ROI-based recommendations; these are future product directions, not realized revenue.
“I stopped optimizing for map interactions and started optimizing for how people think about building an audience.”