Reducing weekly complaints by 42% by unifying a fragmented dashboard
A project on redesigning an internal tool for a financial call center, and extending its design system along the way.
Team
1 Designer
3 Developer
1 Product manager
My role
Product designer
Type
Dashboard
Fintech
Timeline
2 Month
01- Context
As the product designer on this project, I...
Led the redesign of the dashboard, working inside the product team
Partnered with the design system team to build new components made for dense dashboard data.
Worked in phases, over the time I was at the company, moving outside of the team to all internal tools toward one unified system.
Looked over the screens. Part of the problem was teams working in silos, not the UI itself. I set up joint meetings between teams to fix that piece outside of Figma
02- The problem
End users were filing weekly complaints about slow response times
Response time matters in any call center. It doesn't just cost the business. It shapes how the end user feels while they wait.
End user problem

Internal problem

03- Understanding the problem
Understanding what caused this problem, and the frustration behind it, meant stepping into the agent's shoes.
I did this through direct observation, a day working as an agent myself, interviews, and field work. Here's what came out of it.
Agents had to switch dashboards mid-call
To confirm one piece of information, agents had to jump between different internal dashboards while the customer waited on the line.
04- Approach
Before designing anything, I looked at what I was working with and around…
Benchmarked similar tools
I looked at other internal dashboards and admin panels, to find patterns agents wouldn't need to relearn.

The design system was brand new and need improvment
It had just launched, and wasn't built for dense, data-heavy screens like this one.
Dev speed mattered for production
Engineering needed to ship fast with the component libraries they already had, not wait for something built from scratch.
05- Frame the solution
Three problems, three decisions
to cover 1 issue!
Design decision 01
All customer info, one screen
Solves: switching dashboards mid-call
Agents now search by national ID and see everything about that customer on one screen. No more jumping between tools to confirm one detail while the customer waits.
Design decision 02
Components built for dense data
Solves: the same data looking different across tools
The new design system had buttons and basic form fields. It didn't have anything for a screen full of financial records. I built a data table, filter chips, table states, and pagination, then handed them to the design system team as new patterns, not one-off pieces for this panel alone.
Design decision 03
Three clear sections instead of one long page
Solves: key information buried in nested pages
I split the panel into three parts: the main customer view, action and input forms for things like updating a record, and a supporting section for less common views. An agent lands on what they need first. Everything else is one click away, not five.
07- Impact
Key outcomes
The new panel didn't just look different. It changed how fast an agent could answer a real customer question, and how many complaints followed slow response times.
Time to answer one customer question dropped from 2 minutes to 1 minute 15 seconds.
Complaints about slow response dropped from 19 to 14 a week.
Agents used to open four tools for one question. Now it's one screen.
08- Looking back ( In 2026 )
With AI, I'd add one more layer.
A chatbot could resolve simple, well-defined customer issues on its own, before they ever reached an agent by phone. Anything uncertain would still go to a human. That keeps the choice with the customer, not the AI. It also means agents spend their time on the harder calls, and respond to those faster too.
I'd also build every prototype straight from our design system tokens, not placeholder styles.
That makes usability testing faster to run, and handoff to developers faster too. It also lowers the cost for other teams to adopt the same components. The long-term goal was one unified system across the company's internal tools. Real tokens from day one would have made that progress visible to managers, not just something happening quietly in the background.









