🔐

This one's password protected!

Reach out and I'll happily share the password. I'd love to walk you through this one! Find me on LinkedIn. 💙

← Back to portfolio

📊 ✨ 🚗 💡 📈
📊 UX Research Case Study

When Reporting Breaks,
Customers Walk Away.

Nearly half of the customers who left blamed one thing: reporting. I led the research to figure out what was really going wrong, and helped turn that into a product the team could build.

My Role Research Lead & Strategy
I Worked With Product, Design, Customer Success, Support, Engineering, Data Science, Marketing
Timeline About 4 months
Methods Desk Research · Stakeholder Interviews · Ethnography · Customer Interviews · Usability Testing · Rapid Iteration
44%
of customers who left
blamed reporting
15
customers I
interviewed
400+
reports in the system,
but folks used only 5 to 7
01
Context & Problem

The data said reporting was pushing customers away 📊

The churn numbers pointed to reporting as a top reason customers were leaving. But nobody really knew who was struggling, why, or what "better reporting" would even look like. That's where I came in.

The Business Problem
Customers were taking their data out of the CRM, rebuilding reports by hand in Excel, and running the same report over and over for each of their stores. The CRM just didn't fit the way they actually worked.
📊
The data was there, but nobody trusted it
Customers wanted insights from their CRM, but the reports didn't match each other. So a lot of people kept their own spreadsheets on the side just to double-check what the CRM was telling them.
📂
Too many reports, not enough clarity
There were over 400 reports in the system. Most went ignored. Not because they were useless, but because there was no easy way to find or organize the ones people actually needed.
⚡
A real risk, and a real opportunity
Competitors were winning customers over with cleaner dashboards and easy self-service reporting. Fixing this wasn't just about keeping customers. It was about staying competitive.
♡
The Team

Three humans, one shared goal 💙

Good research doesn't happen alone. This was a real team effort. Research, design, and product worked side by side from the very first question all the way to the pilot.

Kamala Alcantara
Kamala Alcantara
Senior UX Researcher
Research Driver

I led the whole research program, start to finish. That meant talking to stakeholders, interviewing customers, making sense of it all, sharing recommendations, running workshops, and keeping everyone across the company on the same page.

Research StrategyInterviewsSynthesisFacilitationRecommendationsStakeholder Alignment
Leban Hyde
Leban Hyde
Senior UX Designer
Design Lead

Leban turned the research into something real. He led the problem framing, mapped out user flows, and built the wireframes and prototypes all the way to a proof of concept that was ready to test.

Problem FramingUser FlowsWireframingPrototypingPOC Design
Mary Swan
Mary Swan
Product Manager
Product Connector

Mary was the glue between research, design, and engineering. She kept everyone aligned on what mattered most, made sure the right things got built, and championed the customer's voice in every decision.

RoadmapPrioritizationCross-functional AlignmentStakeholder Management
02
Research Process

From first question to real solution 🔍

This project moved through a few clear phases. I grounded everything in data before talking to a single person, dug into how customers really worked, then helped test a solution to make sure it actually fixed the problem.

Phase 1 · Foundation
Desk Research & Talking to the Team
I started with the internal churn reports, usage data from Amplitude, and customer satisfaction signals to understand how big the problem really was. Then I talked to everyone with a stake in it: the Product Manager, Design Manager, Product Marketing, Customer Success Managers, Regional Managers, Sales, Business Managers, and the Director of Engineering and his team. This gave me a full picture of what the company already knew, and where the gaps were. It also made sure every question I asked later was grounded in both the business reality and what users were actually feeling.
Phase 2 · Discovery
Ethnography · 5 Local Dealerships · 20+ Users
I visited local dealerships to watch how they actually used reporting day to day. Mornings, afternoons, and evenings, for two weeks. This was where the real magic happened. You learn so much more from watching people work than from any survey.
Phase 2 · Discovery
Customer Interviews · 8 Dealerships · 15 Users
I ran remote interviews with 15 people across 8 different auto groups, everyone from BDC Managers and Sales Managers to General Managers, Marketing Leaders, and owners. The conversations were structured but relaxed, covering how they use reports, what frustrates them, what workarounds they've built, how much they trust the data, and whether they'd be comfortable doing things themselves. I made sure to include small independent dealers, single-brand shops, and bigger multi-location groups.
Phase 3 · Synthesis
Finding the Patterns & Making Recommendations
I pulled everything together into key insights, three big workaround patterns, journey maps for each type of user, and a prioritized list of opportunities ranked by how much they mattered to the business. Then I shared it all in a clear, engaging deck that I presented to over 150 people across product, design, customer success, sales, and engineering.
Phase 4 · Two Paths
Two Bets: An AI Tool vs. a Research-Backed Design
The research kicked off two different ideas. One engineer built an AI-powered reporting tool based on a suggestion from a customer. At the same time, the design team built a self-service Report Builder based directly on the research. Both got tested. One didn't pan out (yet!), and one worked.
Phase 5 · Validation
Testing the Report Builder & Prepping for Pilot
I ran usability tests on the live Report Builder with some of the same people from the original research, walking through 5 key tasks. Internal testing passed, and the product is now heading to pilot with a group of priority dealerships. That closes the loop from research all the way to real impact.
03
Participants

Real people from real stores 🚗

I recruited people from 8 different dealerships, covering a mix of roles, company sizes, and locations. I focused on Sales Managers, BDC and Internet Managers, General Sales Managers, Marketing Leaders, and CRM Managers.

Name Role Dealership
Participant 01BDC ManagerMulti-Location Auto Group
Participant 02Director, BDC SalesMulti-Location Auto Group
Participant 03BDC Assistant ManagerMulti-Location Auto Group
Participant 04Regional General ManagerSingle-Brand Medium Dealership
Participant 05General Sales ManagerSingle-Brand Medium Dealership
Participant 06Fixed Ops DirectorSingle-Brand Medium Dealership
Participant 07BDC ManagerMulti-Location Auto Group
Participant 08BDC DirectorSmall Independent Dealer Group
Participant 09Ecommerce DirectorMulti-Brand Small Dealer Group
Participant 10Owner / Digital Operations LeadSmall Independent Dealer Group
Participant 11Sales / Digital MarketingMulti-Location Auto Group
Participant 12CRM ManagerMulti-Location Auto Group
Participant 13Sr. Digital Marketing ManagerMulti-Location Auto Group
Participant 14Sales ManagerMulti-Location Auto Group
Participant 15VP of MarketingSmall Independent Dealer Group
Why I Picked These Roles
I focused on three main types of users: Sales & BDC Managers, General Sales Managers & Directors, and Marketing Leaders. Each one uses the same reporting system in a totally different way. Talking to all three helped me catch friction that a one-size-fits-all survey would have missed.
04
Research Questions

Seven questions that guided everything 🧭

I wrote each question so it would lead straight to a real product or design decision.

05
Key Insights

What cut through all the noise 💡

Every insight below came straight from what customers told me, what I watched them do, and patterns I saw show up again and again across different people and roles.

🔧 Top Workarounds
"95% of the time we take your reports, export them, and redo them."
→ What this told me: People wanted flexibility, but inside the product, not in Excel. The clunky interface and limited options pushed them to rebuild everything from scratch.
"I have to pull reports for each store and cut and paste to make a group report."
→ What this told me: There was no way to report across multiple stores. People needed one combined view without all the manual copy-pasting that leads to mistakes.
"We keep our own Google Doc to track monthly leads because the CRM is wrong."
→ What this told me: People were building their own backup systems because they didn't trust the CRM. That's a big red flag, and a clear sign we needed better, more transparent data.
"It takes me 2.5 hours to run a single report across all our stores, just waiting for it to load. And I do this every morning."
→ What this told me: It wasn't just about the design. The reports were painfully slow, and that slowness was eating up people's entire mornings.
💡 Key Insights
📋
People only used 5 to 7 reports
Even with 400+ report templates in the system, everyone leaned on the same small handful. Just 5 to 7 reports did almost all the work.
👥
Duplicate leads broke everything
There was no way to catch duplicate leads automatically, so people spent hours cross-checking by hand. Duplicates threw off the numbers and made it really hard to coach the team accurately.
🎛️
"Customize" didn't mean "build from scratch"
People didn't want complicated tools. They just wanted to tweak templates: filter by store, hide a column, sort by rep. Most just wanted to rearrange a few fields or combine two reports they already had.
⏱️
The real problem was wasted time
You couldn't save, schedule, or quickly refresh a report. Every new date range or location meant starting all over. That's hours lost every week, for every manager.
🏬
Multi-store reporting just didn't exist
Managers who oversaw several stores had no way to see them all together. They wanted simple rollups and region filters, or honestly just one report that covered multiple stores at once.
📉
Trust in the data was really low
People kept asking each other "wait, how did you get this number?" when reports didn't match. Not trusting the data had basically become the normal, everyday way of working.
06
Role-Based Pain Points

Same system, three totally different experiences 🎭

When I mapped out each role's journey, it was clear that reporting felt completely different depending on your job. Each type of user needed its own kind of fix.

Sales & BDC Managers
Top Pain Points
  • No way to sort tasks by type or priority, and leads that hadn't been worked weren't flagged
  • No way to see the quality of outreach (like repeated templates or the mix of emails and calls)
  • Reports needed several exports, and the numbers lived in different formats and places
  • Lead source numbers got skewed without clean filtering
  • No way to report across multiple stores at once
General Sales Managers & Directors
Top Pain Points
  • Slow load times, and no way to combine reports across stores
  • No single view of Set, Show, and Sold, and the numbers didn't always match
  • Monthly wrap-ups meant conflicting data, lots of cleanup, and catching duplicates by hand
  • The interface was clunky for digging into details, with not enough guidance or filters
Marketing Leaders
Top Pain Points
  • No way to see which channels drove leads, and hard to isolate website-only leads
  • Data was scattered across a bunch of different systems
  • Everything was compared by hand, with no multi-store dashboards and no alerts
  • CRM data wasn't ready to present, and you couldn't auto-send reports or add notes
07
UX Recommendations

Turning insights into a clear to-do list 📝

I ranked every recommendation by how much it mattered, based on what I saw: how many people it affected, whether it blocked their main tasks, and whether it was tied to customers leaving.

Opportunity Evidence Impact
Let people run reports across multiple stores at once Folks spent 10 to 15 hours a week running the same report for each store, one at a time Very High
Add simple ways to explain what each number means (like hover tooltips) People kept asking "how did you get this number?" when reports didn't match, which led to mistrust Very High
Add more filter controls (date picker, toggles for lead type, role, and individuals) People wanted to filter things like "February vs. March leads" and cut down on overly busy reports Very High
Support split-deal reporting People were frustrated they couldn't track split deals correctly, which slowed them down Very High
Make customizing easy and familiar (favorites, drag-and-drop columns) Lots of people described wanting a simple "Lego-like" builder, not heavy technical reports High
Let people find and search for reports themselves People said they didn't know what reports existed and had to ask support to turn them on High
Add the option to schedule recurring reports People asked "can I just get this sent to me once a week?" but it wasn't possible Medium
Clean up the report layouts so they're easier to read People called the current look "depressing," cluttered, and hard to read in meetings Medium
08
What Happened Next

The research sparked two paths. One taught us timing, one shipped. 🌱

After I shared the research, the team went after two ideas at the same time, both grounded in real signals. Here's what we learned from each.

⚡ Path A · Failed Fast
An AI-Powered Reporting Tool

Customers are genuinely open to AI, and that came through in the research too. One person floated the idea of an AI assistant that could answer reporting questions in plain language. It was a real question worth exploring: could AI actually cut down the friction we kept seeing?


An engineer ran with it and built a prototype. It was a smart bet to test. What we found is that the foundation wasn't quite ready for it yet. The data wasn't consistent enough, trust was already shaky, and the workflows were complex. So adding AI on top just created more uncertainty. People needed the basics to feel reliable first.


This wasn't a dead end. It was a lesson about timing. The appetite for AI is clearly there. The foundation just needs to catch up first. We set it aside without pouring more into it, and focused on what the rest of the research clearly pointed to.

What we learned: AI in reporting is a "when," not an "if." Customers want it, but they need to trust their data before they'll trust an AI reading it for them. Get the basics right first, then add the smart stuff on top.
✓ Path B · Heading to Pilot
A New Research-Backed Reporting Experience

Built straight from the research, the design team created Report Builder: a simple self-service reporting tool that tackled the five biggest findings head-on.


What shipped: permission-based access, multi-store reporting, base templates, the ability to add, remove, and reorder columns, a data preview, saving and organizing reports, saving your column and filter setups, CSV and Excel export, and scheduled delivery.


Internal testing confirmed the core flows worked. People finished their key tasks on their own, felt more confident in the data, and (the best part) stopped reaching for Excel. The product is now heading to pilot with dealerships from the original research group.

What I learned: when the design maps directly to real, validated needs, it earns people's trust in testing so much faster.
09
Internal Proof of Concept Workshop

Before customers tested it, our own team did 🧪

Before taking Report Builder to customers, I ran an internal usability workshop with our Customer Success and support folks. They're the people closest to customer struggles, so they were perfect for finding problems early.

Why This Step Mattered
Testing internally before going to real customers is a smart way to lower risk. Our team could act out customer scenarios, catch broken flows, and flag confusing wording, all without putting any real customer relationships on the line. It also got the whole team (PM, designer, researcher) on the same page about what "ready" actually meant.
Usability Lab: Report Builder POC Workshop FigJam board
⊕ View Workshop Board
👥
Who joined
Internal Customer Success and senior support folks, people who help customers set up reporting every day. They tested using real dealership accounts to keep things realistic.
🗓️
How the session ran
About 60 minutes: 5 minutes to introduce things, 5 minutes to learn the FigJam board, 35 minutes on the main tasks (filters, columns, save, download, schedule), and 15 minutes to wrap up and reflect.
🔬
What I was looking at
How easy, findable, and learnable the whole Report Builder flow was, with special attention to multi-store filtering, customizing columns, saving and exporting, and scheduling delivery.
The Tasks We Tested
Filters: Start with a base report, change the date range, pull last month's data, and compare a few store locations.

Columns: Add a column you need, remove one you don't, search for a new one, and reorder them to match your preferred layout.

Save: Save your customized report, find it again, and make another round of edits. Try saving over it vs. saving a copy.

Download: Export to Excel or CSV and check that it looks the way you'd expect.

Schedule: Set the report to land in your inbox every week, and see how clear and trustworthy that felt.
How We Captured Feedback
People added sticky notes right onto a shared FigJam board during the session, sorted by task and color-coded by theme. Leban ran the tasks, I managed the FigJam and notes in real time, and Mary observed. That kept everything fast and made the patterns pop out right away, so the whole team saw them together with no lag.
10
From Research to Reality

The artifacts that connected research and product 🔗

Research doesn't stop at a report or a slide deck. Here's what the work looked like as it turned into design decisions, prototypes, and a handoff to engineering.

Personas & Workarounds from dealer interviews
⊕ View
Personas & Workarounds
Journey maps and workaround patterns from the customer interviews. These shaped every design decision that came next.
Value statement and feature considerations
⊕ View
Designer's Discovery Board
The value statement, target users, needs, and feature priorities. This is how the designer turned the research into a clear product direction.
Concept mockups and prototype screens
⊕ View
Concept Mockups
Early screens of the Report Builder. This is where the research recommendations became something you could actually click through and test.
Engineering handoff documentation
⊕ View Full Handoff Doc
Engineering Handoff
The handoff doc that took the research-backed designs to engineering, closing the loop from a user need all the way to a shipped feature.
11
Up Next · Usability Validation Study

The launch team is ready, and so am I! 🎉

The next step is bringing the original research participants back to test the live Report Builder during the pilot. I've already mapped out five key tasks and clear success measures, ready to go the moment the pilot starts.

🔜 Coming in the Pilot Phase
This study is planned and ready to go, but not done yet. The design is heading into pilot with dealerships, and this study will run right alongside it to see whether the solution truly delivered on what the research found.
Five Tasks I'll Test
Task 1 · Start from a base report: Go to Report Builder, find the Set, Show, Sold report, and change the date filter to last month.

Task 2 · Customize columns: Add, remove, and reorder columns to get a clean, presentation-ready view. See how clear the drag-and-drop and column names are.

Task 3 · Multi-store reporting: Build a report comparing all the stores. See how easy it is to pick locations, understand the totals, and trust the combined numbers.

Task 4 · Save and organize: Save the report, name it, and find it again later. See how clear the naming and organizing feels.

Task 5 · Schedule and export: Set the report for weekly delivery and download it as a CSV. See how easy scheduling is to find and how clean the export looks.
📐
Numbers I'll Track
For every session: did they finish the task, how long it took, how many errors, whether they needed help, a System Usability Scale score, and a confidence rating from 1 to 5.
🗣️
Things I'll Listen For
Whether people trust the numbers ("I believe this" vs. "I'd double-check this"), how clear customizing feels, how fast it is, how much brainpower it takes, and any confusing words.
🎯
What Success Looks Like
80% or more finish tasks without help. Multi-store reports done in 3 to 5 minutes. Fewer support tickets because people can do it themselves, and more!
12
Up Next · Outcomes & Impact

Where this is headed 🚀

The pilot research plan is ready. The build is solid. The data science team is setting up tagging so we'll have clear metrics. The pilot is coming soon.

🏁
Current Status
Heading to Pilot
🤝
Teams Aligned
PM + Eng + Design
⚡
Learned Fast On
AI Tool, Not Yet
📋
Deliverables
6 Artifacts
🔜 What I Expect to See in the Pilot
→ People will customize reports on their own, without needing help. The internal workshop gave me confidence, but testing with real customers will be the true test.
→ Multi-store managers will finish cross-store reports way faster than before. The design tackles the 26-export problem head-on. The pilot will show us exactly how much faster.
→ Save and schedule will be a big hit. Every single person I talked to wanted exactly this. I think it'll be the most loved feature in the pilot.
→ Column controls will mean less Excel. That's the whole promise of the product. I'll measure it directly through how people do on tasks and what they say afterward.
What This Project Already Shows
Even before the pilot results are in, this project shows what good, long-term UX research can do when it's treated as something that really matters, not just a box to check before design starts. A 44% churn signal became a research program. That research became a product. And that product is now heading back to the very customers who helped shape it.
🚗