Coople reporting

I started by mapping the questions that Operations and enterprise clients were already answering manually. The pattern was clear: the same five or six questions came up every week — are we over or under on hours, where are shifts going unfilled, how does our internal pool compare to external flex workers? People were exporting raw CSVs and rebuilding charts in Excel because there was no other way. I ran interviews with Operations leads and enterprise clients to rank which recurring reports caused the most friction. That list became the foundation for what we'd build first. It also helped me define four distinct user types who each needed something slightly different from the same data: workforce managers focused on coverage and no-shows, ops managers comparing locations, finance teams tracking spend, and HR looking at reliability trends over time. Writing the PRD at this stage — not after — forced the right conversations early. It meant engineering, ops, and I were aligned on scope before a single screen existed.

Early concepts explored two structures: a dashboard-first surface with drill-downs, and a report-library model where each saved view is a first-class object. Testing with enterprise users favoured the report-library model — it matched how their finance and ops teams already shared work, and made governance of metric definitions explicit rather than implicit.

The design centers on a Reports Hub — an entry page that shows a top-level KPI strip (actual hours, avg time to fill, filled in under 24h, filled by returning workers) alongside preview cards for each report. The goal was to make the hub feel like a daily command center, not a navigation menu. Each report follows the same structure: filters at the top, a KPI strip, charts for trend and pattern recognition, and a drilldown table for the detail work. The Workforce Breakdown table in Labor Overview, for example, lets you drill from venue down to role down to individual worker — so a manager can go from 'we're 12% under plan' to 'here's exactly who and where' without leaving the page. Every metric tile links to a plain-language definition. That was a deliberate design decision, not a tooltip afterthought. For the filter bar and the drilldown table interactions, a static Figma prototype wasn't enough — the behavior was too dependent on real data states to test meaningfully with mocked screens. I built a working version of the reports hub using Claude Code with the actual Coople component library, so what we tested in the final round felt like the real product. That also meant the handoff to engineering was cleaner — the components we tested were already production-aligned, not something that needed to be reinterpreted from a spec.

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.