AdType
A single client report took a week to create. Data was scattered, inconsistent, and needed constant cleaning. I was asked to design a solution, but it quickly became a product problem.
Data visualization
B2B
4 months
2018
At a glance
Designed a data product that automated reporting and enabled campaign insights without analyst support.
Used by Sales, Analysts, Engineering, and leadership.
Made a key product decision not to replicate spreadsheets, prioritising structured, decision-oriented views.
Led cross-functional alignment across sales, analysts, and engineering to define scope and make clear trade-offs.
Expanded beyond design to define scope, translate ambiguous requirements, and stabilize delivery.
Team setup
Sole designer working directly with CPO, Head of Sales, analysts, and a team of 6 engineers.
I was responsible for product design, stakeholder alignment, and defining requirements for implementation.
The project expanded from design execution into broader product ownership around data trust and scalability.
Time and spreadsheets as bottlenecks
AdType, a digital marketing agency, relied on analysts to manually build client reports for sales and onboarding. Each report took up to a week, pulling data from multiple systems, cleaning and restructuring it in spreadsheets, and turning it into a client narrative.
This process worked, but it didn’t scale. Insights were fragmented, and valuable analyst time was spent on repetitive work instead of analysis.
I was brought in to design a system that could pull data automatically, generate reports, and turn this into a product clients could use directly.
Conflicting needs define the product
I spoke with analysts, sales, engineers, and clients. It was clear that everyone agreed on a reliable way to work with data and insights, but each meant something different by it.
Clients needed to use the data without relying on analysts.
Sales wanted full visibility and flexibility, close to how they work with spreadsheets.
Analysts needed accurate data, but worked with inconsistent inputs that required constant cleaning.
Engineering had to standardize fragmented data sources with different formats and structures.
The challenge was deciding what to prioritise with the long-term goal of building a product the agency could offer as a service.
Requirements were spread across spreadsheets, documents, and hand-drawn sketches. New requests came in constantly, often undefined or undocumented, which made it clear there was no shared definition of what we were building.
I consolidated requirements into a single, structured source of truth and brought together representatives from each team to review them. We separated confirmed needs from assumptions, removed requests that didn’t support the first release, and surfaced disagreements early.
With the CPO and lead engineer, we defined a clear boundary around what was in scope for the first version and removed uncertainty for engineering.
Designing for understanding, not spreadsheets
Most marketing tools prioritize flexibility over usability. They expose raw data but do little to help interpret it, which is why the work often falls back to agencies.
As I explored how to present the data, Sales pushed for a spreadsheet-like interface with rows and columns they could sort, manipulate, and use for calculations.
They already used Excel. Recreating it would keep the same problems: dependence on experts and limited self-serve for clients. I chose not to support this because formulas and graphs can be built into the system.
Instead, I structured the product around question-driven views, prioritizing what users needed to understand over exposing raw data. Each client case was unique, but fully personalized reports didn’t scale. Standardization was necessary to make the system work.
I worked one section at a time, pairing metrics with explanations. Sales initially resisted, but saw that data was not lost, just structured differently.
Highlight
The goal wasn’t to replace Excel, but to make the data usable beyond expert users. Working this way let me get feedback early and build trust.
Wireframes first reports
New system, new constraints
As the first versions of the product took shape, teams began requesting changes directly from engineers based on what they saw.
This is where data accuracy issues became visible. The growth modeller was the first report we built, and its projections didn’t match what was in spreadsheets and source systems.
The lead engineer flagged that the input data was inconsistent and required significant cleaning and correction, which started to derail prioritized work.
I introduced a tighter way of working. Before development, requirements and calculations were reviewed and agreed across teams, then scoped with engineering before any work started. Engineers redirected new or unscoped requests back to me.
Highlight
This reduced rework and made it clearer which outputs could be trusted.
Turning data into decisions
The challenge was turning raw data into something people could actually use to make decisions.
The growth modeller started as a request for a comparison table. Instead, I designed it as a visual model that reflected how marketers already reasoned about the data. Projections allowed exploring different scenarios without breaking the underlying data.
For trend reporting, the initial direction was to mirror Excel. I chose to include explanations alongside metrics so the data could be understood beyond experienced analysts.
For lifecycle analysis, I focused on transitions between customer states: Prospect, Enquirer, Customer, Lapsing, Lapsed, Reactivated. This showed how customers progressed, where they dropped off, and contributed to revenue over time.
For consent management, I showed how segments changed over time, making it clear when re-engagement was needed before consent lapsed.
Each view constrained what users could do, but made the output clearer and more actionable. This was the trade-off required to move from flexible analysis to a product that could scale.
Data accuracy impacts adoption
Early signs were positive. Clients who adopted the system could independently track campaign performance and better understand their data, improving how the service was perceived.
Internally, analysts spent less time creating reports and more time working with engineering to improve data reliability. Marketers could access up-to-date insights without searching for the right files.
Adoption slowed as data accuracy issues surfaced. Inconsistent input data meant the outputs couldn’t always be trusted, so we paused further onboarding.
Reflections
What started as a design project quickly became a broader product problem. I aligned stakeholders, defined scope, and worked closely with engineering to ensure the system produced numbers people could trust.
It reinforced a simple principle: in data products, usability matters, but trust determines whether the product gets used.