Coople reporting

I kicked off discovery with competitor research, using Claude to identify the strongest workforce management tools with reporting features — then investigated each product myself to understand what reports they offered and how detailed they were.

That research also helped me prepare for sessions with our ops team — the people who were manually building and delivering these reports to clients. Rather than scheduling a meeting cold, I set up a dedicated Slack channel first, asking them to share which reports they thought we should prioritize and why. It gave people time to think, and meant the session itself was already warm.

From there I pulled everything into a Miro board — their ideas, my findings from competitor research, and insights from earlier interviews. We walked through it together, discussed, and voted. By the end we had a clear, shared picture of what the first version of reporting needed to cover.

A round of task-based testing with Operations and two enterprise clients validated the IA before lock. Refinements focused on the filter bar (sticky on scroll, with active filters always visible) and on the empty states for newly created reports, which testers consistently misread as broken queries.

The hardest design problem wasn't the layout — it was metric governance. Every team at Coople had a slightly different definition of fill rate. Operations calculated it one way, finance another, enterprise clients a third. We couldn't just pick one and move on; we had to surface the canonical definition next to each metric so users could trust what they were looking at. That ended up being more valuable than the charts themselves. For a reporting product, the metric dictionary is the product. If users don't trust the number, they go back to Excel. Using Claude Code to prototype with real components also changed how I caught problems. The empty state issue and the sticky filter bar — both of which came up in final testing — were things I'd already seen and fixed once during the build phase, precisely because I was working in a live environment rather than a Figma frame. It compressed the feedback loop in a way that static design tools can't. Running this project as both PM and designer taught me something about scope. Having full ownership made decision-making fast — no handoffs, no misalignments between the PRD and the design. But it also meant I had to be more disciplined about what didn't make it into V1. The roadmap beyond V1 only stayed out of scope because I'd written the rationale for it myself.

The immediate next phase is report subscriptions — so customers can receive a report on a schedule instead of opening it manually. After that, the same component set extends to worker-side reporting once the metric definitions stabilize across teams. Longer term, the permissions layer needs to be designed carefully: cost data, wage factors, and PII have different visibility rules depending on whether you're an ops user or an enterprise client. That's the problem I'd want to solve before expanding reporting depth further.