Lead Product Designer · 2022 · Security & Compliance
Unblocking compliance throughput by making status visible — not by adding more table features
A status board where pipeline health is glanceable — and updating state is the same gesture as moving work forward.
Audit, IT, and ops teams were burning the day reconstructing document-request progress from a dense DRL table — status buried as one column among many across SOC, ISO, and similar engagements. As Lead Product Designer I owned the redesign of how that work was seen and moved. Constraint: same underlying data, strong pressure to “just improve the table.”
01 · The problem
Teams rebuilt the pipeline in their heads every day
Clients ran dozens of document request lists at once across SOC, ISO and similar audits: open, in progress, waiting on audit, waiting on the client, blocked, approved. The list view made operators reconstruct progress from filters and saved views. Priorities weren’t visible, blockers took scanning to find, and new teammates had no fast way to learn what mattered.
Teams spent more energy maintaining a mental model of the work than doing it, and the pressure was to “just improve the table.”
02 · What I found
Every column was useful. The format hid the one that mattered.
Sitting with operators through their daily reviews made the failure clear. Every column held something useful, but the format buried the first thing they needed, which was status. The interface described records. It didn’t show a pipeline.
A list assumes people read record by record. These teams read their work as a pipeline, so the interface had to be one too.
Process
Same data, different shape of work
Status moved from a buried column to the primary spatial axis.
Before
Dense list
Progress reconstructed from filters and saved views
After
Status board
Pipeline readable at a glance; drag updates state
03 · Key decisions
Three calls that made status visible
Decision 1
Replace the table with a status board
Document requests became Kanban stages (Open, In Progress, Ready for Audit Team, comment states, Completed) so status is spatial and readable from across a room.
- Instead of
- Sticky headers, better filters and a denser, more usable list.
- Why
- The work moves as a pipeline. A better table would still make people rebuild that pipeline themselves.
- Trade-off
- A bigger change to defend than the safer ask of another table improvement.
Decision 2
Make moving a card the status update
Dragging a card to a new column updates its status. Cards carry what operators used to dig out of table rows.
- Why
- Updating state should be the same gesture as moving the work forward.
Decision 3
Keep filters, but make them secondary
Filters are still there, but the board already does most of the job filtering used to do.
- Why
- Nobody should need a saved view to answer “where are we blocked?”
04 · Outcome
Same data, a different working day
Nothing about the underlying data changed. What changed was how teams worked: how they prioritized, how they stayed aligned, and how quickly someone could answer “where are we blocked?”
The evidence is behavioral rather than a metric. Prioritization and alignment shifted without a training program, because the structure finally matched how compliance work moves.
05 · Reflection
Workflows are a design surface
A Kanban board isn’t a widget. It’s a claim about how work moves. Operators didn’t need more features; they needed a structure that matched their work.
Replacing the table meant making that claim explicit, and defending it when the safer ask was one more table improvement.