Lead Product Designer/2022/Security & Compliance
Replacing a dense compliance list view with a scannable Kanban board
I led the redesign of a security and compliance platform used by internal audit, IT, and operations teams to track the document request lists (DRLs) behind SOC, ISO, and similar engagements. The existing tool laid the work out as rows in a dense table. The redesign rebuilt it as a status board — so teams could see where every requirement stood, who owned it, and what was blocking it without reading the screen line by line.
Compliance work was getting buried in a table
Security and compliance teams at the platform’s clients were running dozens of document request lists at a time — open items, in-progress items, items waiting on the audit team, items waiting on the client, blockers, approvals. The existing interface laid all of them out as rows in a dense list view with status as one column among many. To understand where the work stood, an operator had to read row-by-row and reconstruct progress from sorted filters and saved views.
The cost was less in time-per-task and more in the shape of the workday. Teams spent more energy maintaining their understanding of the work than doing the work itself. Priorities weren’t visually distinguishable. Blockers required scanning. New team members had no fast way to learn what mattered. The interface had become an obstacle between the team and the picture they needed to operate from.
The problem wasn’t the data, it was the shape of it
I sat with operators as they ran through their daily review and watched where the table broke down. The friction wasn’t in the underlying data — every column held something they needed. It was that the format hid the one piece of information they needed first: status. Status was buried in a column, and progress was a thing you reconstructed from filtering. The interface was describing the work, not surfacing it.
That reframe pushed the redesign past the obvious move — better filters, sticky headers, a more usable table — toward replacing the table entirely. A list view assumes you’re reading record-by-record. A status board assumes you’re reading the whole pipeline at a glance. The work was a pipeline. The interface needed to match.
Status became spatial
I redesigned the DRL view into a Kanban board with workflow stages as columns: Open, In Progress, Ready for Audit Team, Comment for Audit Team, Comment for Client, Completed. Every item now exists in a column that names its state, and progress is something you can see from across a room. Color-coded headers reinforce status at a glance — gray for open, blue for in progress, orange for ready, yellow and red for the comment states, green for completed.
Each card carries the information operators were previously pulling from the table: control ID, requirement description, assigned reviewers, comment count, file attachments. The cards are scannable as glanceable units, and the action of moving an item between stages — drag-and-drop — is the action of updating its status. Updating no longer requires opening a record and editing a field. The thing the user already wants to do (move the work forward) is the thing the interface lets them do directly.
The structural shift mattered more than any single component. Filters and sorting still exist, but they’re secondary now. Operators don’t reach for them in normal use because the spatial arrangement already does the work that filtering used to. The interface lets the team operate from a pipeline view, not a record view.
Workflows shape behavior more than features do
This project reinforced something I keep finding in operations-heavy software: how information is organized has more effect on how people work than which features they have. Operators didn’t need more functionality. They needed a structure that matched how the work actually flowed. Once it did, the team’s prioritization, throughput, and alignment all shifted naturally. Nothing about the underlying data changed.
The lesson worth keeping is that workflows are a kind of design surface, not just a settings page. When you change how a team sees their work, you change how the team works. A Kanban board isn’t a feature — it’s a claim about how work moves. Replacing the table was, in the end, about making that claim out loud.