Designing Prismforce's reporting experience — and the design system that followed

Prismforce is an AI-powered SaaS platform for the tech-services talent supply chain. Operations and delivery teams at large enterprises rely on it daily to track staffing, utilization, and resourcing across large workforces.

One of the platform's most-used surfaces is reporting — users can download reports with filters already applied. The problem was that those filters were fixed. If someone needed to slice the data differently, the workaround was always the same: download the report, drop it into Excel, filter it manually, then export it again. A native feature was quietly being replaced by a spreadsheet every day.

Watching how people actually used the reports made the gap obvious:

• →
  The filters were static. A report might have ten columns, but users could only work with whatever filters had already been built in — nothing dynamic, nothing per-column.
• →
  Excel was the real filtering tool. Users were downloading reports, importing them into Excel, filtering the data there, and exporting again — every time they needed a view the product didn't offer natively.
• →
  No way to save a view. Even after doing that work once, there was no way to save it — the same manual process repeated the next time they needed the same slice of data.

• 01
  Traced the workaround. The Excel round-trip was the real signal — it meant the filtering people actually needed had nothing to do with the filters we'd pre-built. The design had to start from "any column, any value," not from guessing which filters mattered most.
• 02
  Designed for runtime, not setup. Instead of a fixed filter list, users pick which column to filter on at the moment they're building the report, then choose the values for it — freehand, on any of the report's columns, not a pre-selected subset.
• 03
  Layered on top of existing defaults. Some filters stay pre-applied as sensible defaults; users add their own dynamic filters on top rather than starting from a blank state every time.
• 04
  Built for reuse. Once a user builds a filter combination that works for them, they can save it for next time, or review everything currently applied before they download.

The core of the solution was turning filtering from a fixed, pre-built list into something dynamic and reusable:

• →
  Column-level dynamic filtering. Any column on any report can be filtered at runtime — not a fixed set of pre-built options. Users choose the column, then the values, freehand.
• →
  Defaults, layered. Sensible filters stay applied out of the box; users add their own dynamic filters on top instead of starting from a blank state.
• →
  Saving filters for reusability. A filter combination that works can be saved and reapplied next time — no need to rebuild it from scratch on every download.
• →
  Full visibility before download. Users can review everything currently applied — defaults and custom filters together — before generating the report.

Together, this replaced the Excel round-trip entirely: what used to mean downloading, filtering manually in a spreadsheet, and re-exporting is now a single step inside the product.

A few other shipped projects from this year, at a glance:

• →
  Demand management (PMS–RMS). Gave users more granular control over positions within a demand. Live for enterprise clients with strong initial adoption.
• →
  Rule engine for skills endorsement. Designed end to end, in partnership with another product designer — one of the more complex requirement sets I've worked through. Recently shipped for an enterprise client.
• →
  Design documentation. Wrote a full design PRD covering how the system works end to end, now referenced directly by engineering, QA, and product — the first time documentation like this existed outside Figma.
• →
  Drill-down reporting. Multi-level metrics can be expanded in place, with results pinned or shared as a link — turning a static report into something closer to a working dashboard.
• →
  Approval rule engine workflow. Redesigned end to end: rule authoring, documentation-driven setup, and a pre-launch simulation step so admins could see how a rule would behave before it went live.
• →
  Design system. Patterns like tokens, filter components, and table configurations kept recurring across other parts of the product. That repetition is what led to a ground-up refresh of Prismforce's design system — the first in a long time — which I rebuilt from scratch into a scalable, atomic component library. That project is complete now and in maintenance mode. Since then, I've started building some of its components directly in Angular, working alongside another product designer as the team's grown.

The hardest part of this project wasn't the interface — it was resisting the urge to solve flexibility with more options. Every added filter or column type made the builder more powerful and slightly harder to learn. Layering dynamic filters on top of sensible defaults ended up being the right constraint: flexible enough for power users, structured enough that it didn't become its own support burden.

It's also the project that made the case for a design system internally — not as a nice-to-have, but as the thing that would stop us rebuilding the same filter and table patterns every time a new report type came up.