Report Management Tool: One Clear Path to Consistent Reports
Overview
A redesign of a 15-year-old report tool used by umbrella companies like Hilton and Porsche, whose procurement and finance teams track usage and budget across every subsidiary. What started as a 1-sprint UI refresh became a 3-sprint rethink of how reports get made.
Role
Product Designer
Pushed to rescope the project from 1 to 3 sprints, then led research, flow redesign, prototyping, user testing, and UI. Mentored a new designer on the team along the way.
Keywords
System Design
SaaS
Digital Transformation
Timeline
3 sprints (rescoped from 1)
Impact
4 → 1
entry points to get a report
↑12%
increase in tool usage
+1,200
more reports than the previous year
🏆
Business impact
Helped win Marriott
For an umbrella company, consistent reports across subsidiaries is the whole point. The redesigned tool became part of the pitch, and all of Marriott's subsidiaries now purchase through our platform.
What is the Report Management Tool?
The Report Management Tool is a self-service analytics platform that empowers businesses to track software and hardware expenses. It streamlines budget management and financial oversight for both individual customers and parent companies.
Why we redesign the 15-year-old system?
Originally a 15-year-old internal tool, the system became unsustainable as the business scaled. To cut costs and improve efficiency, it was transitioned to a customer self-service model. However, poor usability necessitated a full redesign to ensure the platform was intuitive, accessible, and ready for future growth.
Problem
While powerful, the legacy system was too complex for customers to navigate independently. Difficulty in finding and managing reports led to a heavy reliance on support teams, creating operational bottlenecks and reducing efficiency.
Challenge
User roles and needs were undefined, making it hard to design with clarity and purpose.
Customers lacked confidence in using the tool, often relying on support
01 · The ask
A 1-sprint UI refresh. At least, that's how it started.
Product brought me a 15-year-old report management tool with a simple brief: update the UI and ship it in one sprint. For years, our marketing team generated reports for customers. Now customers would do it themselves.
I spent my first days clicking through the system to learn it. Very little of it made sense.
02 · Discovery
Even the experts couldn't make a report the same way twice.
I asked the marketing team, the people who had been generating reports for customers, to demo the tool. They couldn't walk me through it either. So I interviewed internal and external users, and watched them build real reports.
Everyone had invented their own way to get a report, and nobody knew which way was right.
What we heard in interviews
📜 Endless scrolling
Long, unorganized report lists made it hard to find anything.
🏢 Unclear account ownership
Users struggled to tie reports to the right subsidiary account.
🔁 Template confusion
Confusing templates led to repetitive manual work.
📅 Rigid scheduled reports
No way to edit or delete a schedule, so users created duplicates.
🧩 Inconsistent formats
Reports came out in different structures, so parents couldn't compare them.
👀 Cluttered interface
Poor visual hierarchy made navigation slow and error-prone.
03 · Who we design for
Our customers are umbrella companies. One parent, many subsidiaries.
Clients like Hilton and Porsche control their subsidiaries from the top. Procurement and finance teams at the parent track every subsidiary's software and hardware usage and budget, so they need reports in one consistent format to review them side by side.
💼 Procurement (parent)
Tracks what every subsidiary buys and uses.
📊 Finance (parent)
Reviews budgets across subsidiaries and needs comparable numbers.
🏨 Report owners (subsidiary)
Build the reports, following training from the parent.
How a report travels through an umbrella company
🏢
Step 01
Parent sets rules
Procurement and finance decide what every subsidiary report should contain.
🎓
Root cause
Step 02
Parent training
Each trainer teaches the path they personally use, so every one learns a different one.
🏨
Step 03
Subsidiaries build
Different paths produce different formats, and sometimes the wrong report.
🔍
Step 04
Parent audits
Reports can't be compared side by side, so review turns into rework.
Inconsistent tool usage at the top became inconsistent reports at the bottom.
04 · Rescoping
I asked for 3 sprints instead of 1.
I brought what I found to the product team. A new UI on top of a flow nobody understood would only make wrong reports look nicer. We agreed to extend the project from 1 sprint to 3, so we could fix the flow, not just the pixels.
🔑 Key decision
UI refresh → Flow redesign
Two extra sprints were cheaper than shipping a tool customers still couldn't use on their own, and still calling support for.
Sprint 1
Understand
Demos, interviews, and mapping every path users took to a report.
Sprint 2
Explore and test
Two design directions, put in front of real users.
Sprint 3
Design and deliver
One simplified flow, a refreshed accessible UI, and reusable components.
05 · UX strategy
If everyone takes the same path, every report matches.
With the extra sprints, I turned the research into one north star and three design principles. Every decision after this had to serve at least one of them, which also gave me a clear way to explain trade-offs to the product owners.
North star
Anyone at any subsidiary can get the right report, the same way, without calling support.
Principle 01
One way in
What we saw
Four entry points, and every trainer taught a different one.
What we did
One entry point and a unified top bar. Duplicate paths removed.
Proof
4 → 1 entry points
Principle 02
Right report, first try
What we saw
Hundreds of reports in long lists. Users sometimes ran the wrong one.
What we did
Reports grouped by category, each with an inline explanation.
Proof
Won the usability test
Principle 03
Set it up once
What we saw
No way to edit a schedule, so users rebuilt them and called support.
What we did
Templates get their own tab, and schedules can be edited or deleted.
Proof
+1,200 reports year over year
I mapped the principles onto the customer's journey so every stage has one clear feature doing the work.
Stage 01
Find it
Reporting has one home in the top bar, so there is no door to guess.
One way in
Stage 02
Choose it
Reports are grouped by category, and each one explains itself inline.
Right report, first try
Stage 03
Reuse it
Templates live in their own tab, with Run and Edit in clear columns.
Set it up once
Stage 04
Schedule it
Schedules can be edited and deleted, so nobody builds duplicates.
Set it up once
06 · Mapping the flow
Four doors led to the same reports. I closed three of them.
My first step was drawing the flow that existed. Users could reach the same report catalogue through four different routes, with no signal for which one was right. Some routes ended in the wrong report. I rebuilt it as one straightforward path, where the next step is always obvious.
4
→
1
Entry points into reporting
4
→
1
Routes into the same report catalogue
9
→
6
Navigation items to scan
07 · Two directions
The easier build, or the real fix? We let users decide.
I designed two directions. The product owners preferred Idea 2 because it was easier to build, but it kept the old structure and never simplified the flow at its root. I pushed for Idea 1, which did. Instead of debating it, we ran a comparative usability test with both prototypes.
Idea 1 · Simplified flow
IDEA 2 · EASIER TO BUILD
✅ Users preferred Idea 1
A cleaner layout, better readability, and a more modern visual design.
⚠️ Concerns with Idea 2
Too much scrolling, specific reports were hard to find among hundreds, and long descriptions were hard to scan.
08 · The redesign
One path, a clearer UI, and patterns the team can reuse.
With the flow settled, I rebuilt the interface around it: a unified top bar, reports grouped by category, higher contrast and clearer labels for accessibility, and shared components so every page behaves the same way.
BEFORE
After
📂 New report system
One top bar with clear tabs and reports grouped by category. An inline dropdown explains each report, so users no longer switch pages to understand it. Duplicate paths and clutter are gone.
BEFORE
After
🧾 Report templates
Templates moved to their own tab to cut clutter. "Run" and "Edit" got their own column so they're easy to find, and the layout scales to show more templates at once. For parent companies, shared templates are what keep subsidiary reports consistent.
BEFORE
After
📅 Scheduled reports
Aligned with the rest of the experience, with a clear empty state and a prominent "Schedule report" button so users know exactly how to start. Schedules can now be edited and deleted, ending duplicates.
BEFORE
After
🧱 Reusable components
Standardized confirmation modals and success toasts give clear feedback after every action, and give developers one pattern to reuse across the tool.
What's next
🔜 Report generation
The report generation detail page was postponed due to team capacity. Next: bring it in line with the new design, unify styles across the platform, and validate the full experience with A/B testing.
BEFORE
Proposed
09 · Outcome
Customers run reports on their own, and one path made training simple.
Usage grew 12%, customers generated 1,200 more reports than the previous year, and every report now starts from the same entry point.
🏆
Business impact
Helped win Marriott
For an umbrella company, consistent reports across subsidiaries is the whole point. The redesigned tool became part of the pitch, and all of Marriott's subsidiaries now purchase through our platform.
★ North star
10 · Reflection
The brief is where you start, not the scope.
The request was a UI refresh. The real problem was that nobody could produce the same report twice. Asking for a demo, and noticing that even the experts couldn't give one, changed the whole project.
I also learned to let users settle design debates. Testing both directions turned a disagreement with the product owners into a decision we all trusted.