Enterprise Reporting

At a Fortune 100 financial services company, the teams behind an enterprise retirement platform relied on reporting to make daily decisions, but the reporting experience had grown inconsistent across teams. I joined as the business lead and UX partner on a cross-functional effort to rethink how reporting data was structured, surfaced, and understood.

It involved six teams and more than fifty people. Not one of them reported to me. The redesign below is the visible output, but the work that made it possible was holding that group to a single definition of success long enough to build something against it.

Six teams, fifty-plus people, none of them mine

Business leadership, Product, UX, Engineering, business partners, and the end users who lived in these reports daily. Some sat in the same building, most did not. Each group had its own reporting line, its own targets, and a reasonable claim on what the work should be. My authority was entirely borrowed, so every commitment had to be earned rather than assigned.

I ran the program on three cadences, and each one did a job the others could not. Recurring collaboration meetings were the spine: one room where decisions were made in front of everyone, so no team could be surprised later by something it had never agreed to. Standing 1:1s with key people were where the real objections surfaced, because someone will tell you privately what they will not say in a room of thirty. And I organized social activities, which sounds like the soft part and was not: teams split across offices have no reason to extend each other the benefit of the doubt, and every hour spent building that was an hour I did not spend debating a decision again.

Getting UX into discovery

UX was not a standardized practice at this client yet. It was still taking shape, and when it entered a program got decided program by program. I pushed to move UX work into discovery, ahead of the point where requirements harden into a chosen solution. There was no process to appeal to, so the case had to be made person to person and more than once, to the sponsor who could actually grant it. It took persistence rather than one convincing argument.

The research below is what that bought. Stakeholder meetings, user interviews, and the current-state journey map all happened before anyone designed a screen, which is the only reason we found that the six teams held six different definitions of what reporting was for. Entering later would have produced a well-designed answer to a question nobody had agreed on.

Engineering was the hardest team to bring along

Not out of obstruction. The problem was that words were doing too much work. We would leave a meeting agreeing, and discover later we had agreed to different things. So I stopped bringing descriptions and started bringing rapid prototypes: something concrete enough that they could point at a specific part and tell me it was wrong.

Alignment I could verify beat alignment I had to assume. Once Engineering could see exactly what was being asked, the conversation moved from whether we understood each other to what it would take to build.

Two problems, one root cause

The reporting experience was failing the business and its users in parallel, and both traced back to the same missing thing: a shared understanding of what good reporting looked like.

Alignment had to come before redesign

Before touching the interface, I focused discovery on how different teams actually thought about reporting: stakeholder meetings on goals and decision points, user interviews on workflow friction and workarounds, and a map of the current-state reporting journey. The clearest finding: the six teams held six different ideas of what reporting was for.

One row in that map hides the split that mattered most. “End users” was never a single group. It covered the people whose account it was, the people who answered their questions, and the people responsible for the plan overall; three groups who open a report for three different reasons. Anything we built had to answer all three.

A standoff between the people who used the reports and the people who funded them

Most disagreements were resolved in the cadences above. One was not, and it is worth walking through because it shows what the job looked like when the usual mechanisms ran out. The sharpest disagreement was over filtering. Business users wanted far more control over how they could segment report data. Upper management was focused on what that would cost to build. Both positions were defensible, which is what made it hard. Framed as a budget question, it would be settled by whoever held more authority in the room, and I did not hold that authority.

So I turned it into an empirical question: does richer filtering actually change how quickly and how confidently people reach an answer? I built two low-fidelity prototypes, one with the filtering and one without, and put real business users in front of both. The sessions were the argument.

The functionality shipped. Watching users rebuild reports by hand also put a price on the workarounds discovery had surfaced: they were already being paid for, in time, spread invisibly across teams.

The report, rebuilt around a question

The same underlying data, reorganized so the answer comes first and the detail follows. Every report follows one predictable path: summary, then the metric that matters, then filters to refine it, with the full tables one click away instead of on screen by default.

Users could locate key information more quickly and confidently, and the day-to-day conversation shifted from "where is the data?" to "what does the data mean?" Reporting workflows became consistent across teams, which is what made merging multiple reporting systems a realistic next step rather than an aspiration.

The reporting model reached all three of those groups, more than a million users in total. That spread is why consistency was a requirement rather than a nice-to-have: one structure had to answer three different reasons for opening a report, without splintering into three different reports.

What I learned

• Alignment has to be maintained. With borrowed authority, agreement lives with the people who gave it, not in a document. That is why decisions had to be made in the open and re-earned as standing work, rather than treated as signed once.
• Leading without authority is a cadence problem. No single forum did the job. The open meeting made decisions durable, the 1:1 surfaced what the meeting suppressed, and the informal time bought the trust both depended on.
• Clarity matters. Surfacing the right information is more valuable than showing everything.

The project ran to completion. Testing broadened across the remaining reporting workflows, and the model held consistent across all of them.