Problem
How we found out
Tickets from the
last 60 days
Understanding the two classifications
When a mismatch happens, the platform resolves the conflict by assigning the higher of the two classifications.
The questions that shaped the design
Working through the flow surfaced four questions the interface had to answer:
Q1. What is the owner supposed to do when a mismatch occurs?
Verify the assigned classification.
Q2. Why does it matter to them?
A sensitive classification can trigger downstream security obligations. An SSP, for example, carries consequences for how the application must be operated.
Q3. What if they disagree with the assigned classification?
They need to give the information that would change it, and that information differs depending on which classification is in play.
Q4. How would they even know there's a mismatch?
Email notification. A passive state change isn’t otherwise surfaced on a page most owners rarely visit.
Beyond the interface
Before
The existing classification page displayed the plan classification alongside every table included in the classification. It was accurate but static — a readout with no reasoning and no action.
The redesign
I started from the flows rather than the layout, mapping what "change this" means in each state.
Below is the redesigned classification page.
Feedback and outcomes
The AI explanation was well received. It was the most positively received element with both compliance and application owners, and it addressed the ticket pattern the PMs had been absorbing.
Follow-on discussion. Once explainability was addressed, discussion shifted to notification design and automating the resolution process.