Reporting: turning raw terminal data into decisions merchants act on

THE CHALLENGE

The CRM platform behind our payment terminals had no built-in way to make sense of the data it collected. Merchants, partners and internal teams could see raw transaction and device data. But nothing answered the question they actually had - how is my business doing right now?

I led the design of Reporting: a native way to understand payment activity and terminal performance, built to become a permanent capability of the platform rather than a bolt-on feature.

Role

Leading product designer, Reporting

Worked with

PM, PO, data & engineering

Status

Live, iterating

Three audiences, one dataset, real technical limits.

A merchant wants to know how their business performed today. A partner wants portfolio health across many merchants at once. An internal team wants to catch a failing terminal before it becomes a support ticket. The same underlying data had to answer all three without collapsing into a dashboard that answered none of them well.

Two constraints shaped everything: the flow had to hold together end to end, from first glance through to a saved and exported report. And the whole thing had to extend the existing design system rather than quietly fork it.

PROCESS

I gathered what we already knew (user personas and their needs, customer feedback, technical requirements and limitations) before drawing a screen, so that “actionable” was defined per audience rather than in the abstract.

Identify business needs and pain points

Define the concept with tech and product

Working closely with the PM, PO and technical team. I mapped core user requirements against the data we could realistically deliver, scoping the concept to what the platform could actually support.

Work through flows and patterns

The first iteration focused on differentiating report types clearly enough that people could tell them apart and use them confidently. Including the flows for building, saving and exporting a report. At this stage I used AI for some mockups on the page data structure options for exploration.

Create scalable UI, interactions and prototypes

Everything was built inside the Material UI-based design system so Reporting extended the platform's language instead of introducing a second one. This included an advanced filter pattern for narrowing large, multi-dimensional datasets. Later this component was adopted as a standard across the design system, well beyond Reporting.

Align stakeholders and support delivery

I worked continuously with product, data and engineering to validate feasibility and accuracy, establishing checkpoints that let us confirm assumptions and log pain points to carry into the next research round.

The advanced filter component built here is now used by other teams facing the same underlying problem: giving people control over a large dataset without a wall of controls. It is the piece of work I point to first as evidence of systems-level thinking rather than screen-level design — I designed it for one feature area and it became a platform standard.

A PATTERN THAT OUTGREW ITS FEATURE

FOLLOWING THROUGH AFTER LAUNCH

I did not hand this off at delivery. I initiated the structured user interviews now running to validate the original hypotheses, and I raise changes to underlying data structures directly with solution architects and PMs where they unblock a better experience.

VISIBILITY

Merchants and internal teams monitor payment activity and terminal performance in real time.

BUSINESS

Strengthened the platform's value proposition; used directly in sales demos to prospects.

SYSTEM

The filter pattern became a reusable, design-system-wide standard.

Structured user interviews underway to shape the next iteration.

REFLECTION

Reporting became a genuine differentiator for the platform. Is a proof that complex payment and terminal data can be made intuitive without being dumbed down. I have deliberately kept this honest about stage: it is live, early signal is strong, and validation is still running.

1