Consent Audit Report

The Consent Audit Report's position within the platform — its place in the sidebar navigation, alongside other compliance modules — was already established from earlier versions. For V3, this existing structure served as the starting point for the redesign.

These additions reduced friction for users who needed quick access — and set the stage for a more significant workflow change still to come. The platform's existing personas also provided context for who relies on this report most, and their differing needs mapped closely to the three priority gaps.

• ✦The Security Engineer: responsible for investigating and acting on unauthorized vendors — needed a structured way to do so within the report itself, shaping the actionable insights workflow detailed later in this case.
• ✦The Compliance Analyst: focused on generating audit-ready reports without digging into technical detail, needed a clear, unified summary and quicker access, reflected in these navigation shortcuts.

The biggest design challenge in V3 was the "actionable insights" gap: giving users a way to resolve a violation without duplicating logic that already existed elsewhere in the platform, or introducing risk of inconsistent data. That "elsewhere" mainly meant two configurations: Policies and Data Sources. Policies in the platform aren't scoped to a single project. This meant any action that modified a policy could ripple beyond the report the user was currently looking at.

Why this matters

Customers can apply the same policy across multiple projects to simplify maintenance of an otherwise complex configuration — so a change made in one place isn't isolated.

Data Sources — a separate but closely related configuration, defined back in V1 and V2 with no changes in this iteration — added another layer to this complexity, determining which URLs and consent scenarios a given audit would actually run against.

• Early discovery considered redirecting users to the existing policy page, but after reviewing the technical impact with development, we moved the resolution flow directly into the report instead — reducing engineering risk while saving users an extra step.
• Making violations actionable also required a new business rule: previously, a failed check had no formal status. V3 introduced a clear distinction between passed checks and violations, with a dedicated overview summarizing how many of each existed.

This reclassification was what made resolution possible in the first place — once a failed check was formally a violation, it could be tracked, acted on, and resolved. Each violation type still required a different resolution path, depending on whether a permanent fix was technically possible yet:

• ✦Unauthorized vendors could be resolved in two ways: adding the vendor to the policy's "strictly necessary" list — a change that would affect every project using that policy — or resolving the violation without modifying the policy, a scoped, one-off fix.
• ✦Banner visibility and custom check violations didn't yet have an equivalent policy-level mechanism to resolve their root cause. For these, I designed a "Resolve until next occurrence" action — a deliberately temporary fix, scoped only to the current report, that unblocked users immediately while a more complete resolution path was planned for a future release.

In both cases, resolving a violation removed it from the open count — giving users a clear, immediate sense of progress as issues were addressed.

Exploring the solution space

Before settling on the scoped resolution flow above, I used Claude and Figma Make to quickly explore a more ambitious version of the Consent Audit report — including a dedicated Issues view with severity scoring, suggested fixes, and assignee tracking.

These explorations showed both the ceiling of what this gap could become, and how far that was from what this release could support — which shaped the scoped resolution flow that shipped in V3.

Reaching the Consent Audit Report used to require navigating through several steps — login, project selection, dashboard, and finally the report itself. For V3, we added a direct shortcut from the Dashboard, giving users who already knew what they needed a faster path to the report.

We also introduced an email notification, alerting users as soon as a new report was ready — removing the need to check the platform manually to know when a scan had finished.

Of the three gaps, this was the least resolved in V3. Fully solving it meant giving users a complete picture of a violation (what happened, why, and how to remediate it) without leaving the Consent Audit report. But some of that information already existed elsewhere in the platform, spread across other reports, and connecting it properly meant touching parts of the product beyond the scope of this project.

• ⚡ Given the amount of work already planned for development in this release, the team — together with product — decided to deprioritize this gap in favor of the two with higher impact.

One idea discussed was adding a "Web Consent Audit" tag to vendor entries in this existing report, helping users quickly identify vendors surfaced through this data source — a small, clear-benefit change that still meant modifying a report outside this project's scope, so it stayed a future consideration.

Also addressed as part of this gap was the Audit Trail tab on the Consent Audit report. It gives users a persistent, unified record of what had happened on the report and when.

While this case focused on V3, every version of this report — from its first release to this final iteration — was designed by me. At the time I left the company, V3 was with the development team, including:

• ✦Violations classification
• ✦Unauthorized vendors resolution flow
• ✦Audit trail tab
• ✦Dashboard shortcut
• ✦Email notification

The banner visibility and custom check resolution were treated as an initial, temporary solution, with more complete options planned for a future iteration. The connection with other reports — like the proposed vendor tagging — also remained an open item for future iterations.

🎥 Watch the video, including the full flows for:

• ✦Policies configuration flow behind Consent Audit
• ✦Data sources configuration for the project
• ✦Consent Audit report and details page
• ✦The Dashboard shortcut to Consent Audit

Working on this report reinforced how much complexity a single interface can carry without the user ever seeing it. Behind every violation and resolution button was a web of policies, data sources, and configurations — and much of the design work was about finding the clearest way to represent that complexity, not adding to it. It also reinforced that improving a product is rarely linear. Every version meant designing, testing, and iterating again — as fast as we reasonably could, since sales teams were waiting to bring these improvements to customers. That pace meant real trade-offs: shipping temporary fixes, deprioritizing smaller wins to protect bigger ones, deciding what could wait. None of these were compromises I made alone, but learning to recognize when a trade-off is the right call — not a failure to get it right the first time — is something I carry with me now.