Turning fragmented operational reporting into a traceable view
I led end-user discovery and initial product design for a banking operations dashboard intended to replace spreadsheet-dependent reporting with a clearer view of business activity and anomalies.
Status: Validated concept — not implemented during the engagement
- Client
- Confidential financial institution
- Duration
- Approximately six months
- My role
- Primary product designer
- Team
- Product designer and product manager
- Responsibilities
- Led end-user discovery sessions, synthesized findings, partnered with the PM on product stories and screen structure, designed prototypes, and reviewed them with users
- Areas explored
- Home overview, fraud, and customer-service call logs
- Status
- Discovery and initial ideation completed; the concept was not implemented during the engagement
On this page
Overview
Business operations teams monitored activity through a combination of existing tools, downloaded data, spreadsheet templates, and manually assembled reports. The process could reveal the metrics they cared about, but understanding where an unusual pattern originated required looking across multiple places and coordinating with technology operations.
As the primary designer, I led discovery sessions with end users and translated what we learned into early product structures and prototypes. I partnered closely with a product manager, who helped turn the work into stories for the technology team and served as my main design-critique partner.
The six-month engagement focused on discovery and initial ideation. The product did not reach implementation while I was on the project.
The central design question
How might we help operations teams move from seeing an unusual metric to understanding where it came from without manually rebuilding the story across spreadsheets and disconnected systems?
The design principle that followed: an anomaly is useful only if a user can trace it to the relevant business area, underlying data, and next conversation or investigation.
Learning what users could not easily articulate
During a prototype review, one user told us the concept felt like we were “reading their mind.” They had not been able to describe the desired interface in advance, but the prototype gave them a concrete way to recognize and respond to what they needed.
I treat that as a signal about the prototype, not as usability evidence on its own.
Outcome and status
The prototype helped users recognize a more direct way to monitor operational activity and investigate unusual signals. The engagement ended before implementation, so the work did not produce measured operational outcomes.