Self-serve data access at LiveRamp
Eleven ingestion flows became one, and a process that took three days now takes ten minutes.
Role: Principal Product Designer | Team: 1 designer (moi), 5 product partners (more on that later), engineering and architecture | Timeline: 2 years, shipped incrementally | Deliverables: Data model proposal, modular ingestion wizard, file tracking, research program
Six ingestion flows (or eleven, depending on who you asked)
LiveRamp gives clients a powerful set of tools for their data goals: activation, measurement, collaboration, and more. But the offering was fragmented, and the ingestion story even more so. The company’s basic product data-flow diagram showed six different ingestion flows. Interviews with support experts turned up the lesser-known ones and brought the count to eleven. None were self-serve, and customers using multiple products didn't just re-ingest their data, they often had to reformat it too.
Ingesting or connecting data is the third most common user task, with over 56% of users doing it regularly.
The back end was people.
I asked support experts to walk me through connecting a data source and setting up a data asset. The results were a little bit shocking: the bulk of our tech back end was propped up by Supporters (internal users who assist customers) carrying out manual, repetitive tasks for Uploaders (external users trying to get data into the platform). A major case of man-behind-the-curtain, and requests took days to complete.
A heuristic evaluation of the few places we did surface ingestion information found them lacking against accepted standards.
User flow for creating a basic data object starting from data contained in a file.
Users asked for a pizza tracker. And needed transparency.
I parsed every piece of Uploader feedback I could find. The issues fell into four buckets:
Slow: "I was confused that when I wanted to upload a file and create a new audience, I need to submit a [support] ticket."
Unsophisticated: "[The UI] will say [the file] is delivered but it's 4 or 5 days until it shows up. We get our stuff done and we don't see the data in Safe Haven."
Opaque: "Is LiveRamp aware of that data? Is it being ingested? Did it fail? Was the format wrong? We want a pizza tracker and an ETA on what's happening."
Rigid: "Files can get halted for a missing prefix or a misplaced capitalized letter and take days to resolve."
Four bets to fix it.
The user goal (activate or measure with my data) and the business goal (reduce costs, gain efficiency) pointed the same direction: cut the friction and time between clients and their data goals. I formed four hypotheses, most spanning multiple problems:
Integrated product offering: Unify the entry points behind one modular configuration wizard. Simpler for users, cheaper than maintaining duplicative functionality.
End-to-end self-service: Source connection, asset creation, and pipeline visibility without a ticket. Support costs drop, and the support team gets freed up for white-glove premium service, a new revenue stream.
Intent-driven workflows: Let users tell us what they want to do with their data, and show them the right tools for the job.
Efficient dataset management: Store data once and apply transformations dynamically as product features require it, cutting compute costs and ingestion SLAs.
My first pass at a modular, branching workflow. Check out the early discovery deck.
The biggest design decision had no UI
Support had walked me through the technology behind the main ingestion flows: slow, inefficient, and costly to compute. Fixing that meant proposing a new data model to engineering and architecture, at some risk of stepping out of my technical depth. Instead of every product creating bespoke data assets, the system appends metadata based on the user's intent and applies transformations dynamically to create datasets, tables, and segments. Simplifying the underlying system simplifies the UX that represents it.
Ingesting or connecting data is the third most common user task, with over 56% of users doing it regularly.
Validation scaled to risk.
Part of what attracted me to LiveRamp was the maturity of its product development life cycle. I was empowered to run discovery, form hypotheses, influence strategy, and validate all of it. My rule: scale the intensity of validation to the risk of the proposal. This initiative had every risk severity, so it got the full toolkit: surveys, rapid user testing, user interviews, cognitive walkthroughs, and collaborative heuristic evaluations. Watching alpha users click where I didn't expect sparked insights I could not discover on my own.
One wizard, driven by intent.
The flow starts with the user declaring their intended use of their data - not the asset their trying to create. "What are you trying to do?" is a non-intimidating starting point. Then the flow only shows modules and components relevant to the answer. It's the same question that anchored my Partner Marketplace sprint. An easy-mode template version covers most users, and an open schema gives power users the full flexibility to customize based on their needs.
"Where's my data?" shouldn't require a support ticket.
The Pizza Tracker shows each file's step in the pipeline, what that step means, and an ETA.
Users loved it. But don't just take my word for it.
Critical feedback shaped the structure and refined the interactions. The positive feedback validated the initiative as a whole:
Usability: 92% ingestion task success rate in testing, with zero direct failures.
File tracking: "This is cool to see what step [my data is] in and what it means."
Structural clarity: "[Data Sources are] the origin point for getting the data into LiveRamp."
Self-service: "Good! This will allow clients to QA their files" and "This is nice that it did it for me."
Five product partners, a moving North Star, and the elusive phase two.
Over two years I partnered with five different product partners, with momentum hits at each handoff (the last one stuck, and she was instrumental in carrying this forward). Company North Star strategy changed quarterly, which taught my partners and I to build a narrative foundational to anything the company was trying to do, which ended up influencing org structure to secure resources necessary for foundational work. And priority for iteration had to be re-sold each cycle by tying enhancements and expansion to cross-functional initiatives.
These challenges helped grow my ability to disagree and commit. Sometimes it’s more important to be happy than right, though building a track record as a good decision maker and collaborator while navigating organizational ambiguity is what separates a good designer from an effective one.
The results.
90% reduction in ingestion times
50-75% lower compute and hosting costs, before counting reduced support costs
47% fewer support tickets year-over-year
+16 SUS score after the Pizza Tracker shipped
The success of this engagement wasn’t just good for users, it affected organizational change and strengthened the design team’s position as the go-to for leading cross-team, cross-discipline discovery. And similar to the game publishing work at Microsoft, the framework proved flexible enough to scale to new lines of business.
One more thing… what if it was even faster?
The intent question at the front of the wizard turned out to be more than a friendly starting point. It's training data. What if the system took everything it learns about the most common settings and inferred the rest of a user's intent from their past usage?
That concept became Fast Pass (I named for the Disneyland line-skip). The current (mid-2020s) design reflex is to bolt a chat window onto anything with AI in it. Fast Pass goes the other way: machine learning applied where it's actually strong, predicting structured settings from past behavior, with no conversation required. The user answers a minimal set of questions, most prepopulated with their likely settings, and skips straight to the review screen: confirm the auto-populated selections, jump back only if something needs changing. The wizard's minutes become seconds. And the hard part is already tractable: our proof of concept mapped fields at over 98% accuracy with a basic model, no exotic tuning required.
Step 1: The user answers a very minimal set of questions, most of which prepopulate with common settings.
Step 2: We then skip the flow straight to the review screen, where the user can confirm the auto-populated selections and jump to a specific screen if they need to change something.