Onboarding and recommendations framework · Microsoft Purview
Turning crowded setup pages into a clear path
Shipped in Insider Risk Management, Information Protection, and Communication Compliance
The challenge
Security solutions deliver nothing until an admin completes several setup steps
Nothing said which steps mattered
No obvious sequence
No way to tell if they had permission
No mention of what came next
Four problems, every time a solution was set up.
“Admin” here means the data security, governance, or compliance admin who sets up and manages Purview solutions.
The solution
A content and design system for setup and post-setup recommendations
Five recommendation types
Three modes of action
Decision trees for placement
One anatomy every task follows
Documented so other teams could adopt it
What I did
Diagnosed the pattern
From years of customer support cases and requests
Defined the system
The recommendation types, modes of action, and placement logic
Wrote the guidelines
Content guidelines, component anatomy, and accessibility annotations
Partnered to ship it
With UX design, product, and engineering
The problem
The bulletin board dilemma
Solution landing pages looked like a coffee shop bulletin board. Notices shouting at the same volume, some stale, some contradicting each other.
Piled up
Message bars, promo cards, banners, and callouts piled up on solution pages over years. Each came from a different squad that didn’t know what the others were shipping. Each claimed to be the important next step.
Unordered
Nothing could be ordered, prioritized, or tracked. Admins couldn’t tell what mattered, what was already done, or what would break if they picked wrong.
Never went away
Worse, many never went away. A completed task kept sitting there, so the page couldn’t be trusted as a record of anything.
What an admin saw
Six problems on one page, and nothing an admin could act on
Before state, based on a real solution page. A new tenant (one customer’s environment), day zero.
The issues
Three message bars from three teams. None ranked against the others, none aware of the others.
Dismissible, no record kept, no call to action. No link to complete the task. Close it and there’s no way to know it existed.
Empty task that can’t be completed. The task can’t be done until a policy is set up first.
Empty state errors with no calls to action. Generic error text from the backend, with no reason and no next step. They can’t be completed until a policy exists or a device is onboarded, so they shouldn’t show yet.
Misleading empty state. Device info can’t be shown because no devices are onboarded to the org yet.
Content too long for the card. Dense, marketing-heavy copy aimed at the wrong reader, and it makes the card scroll. Localization can expand it 25 to 30% in some languages.
Nothing to act on yet
That page above is a new tenant on day zero
No policies, no onboarded devices, no activity. Much of what the page showed couldn’t be acted on yet. Policy health needed a policy. Device data needed onboarded devices.
Needed a policy first.
Needed onboarded devices first.
The fix had to start with deciding what to show first. I’d been working on that question for years.
Working out the fix
I wasn’t starting from scratch
I’d been shipping pieces of this for years
None of it was a system. I was one content designer attaching guidance wherever it fit.
Why none of it carried over
Three portals, three code bases
Each piece was a custom addition. I spec’d it, got product managers and engineers on board, and helped build it. The next portal was a different code base and didn’t support it, so it started over.
Purview was the same story, with one difference: this time I wanted a system, not another set of custom additions.
Nothing before its time
Progressive disclosure, applied to setup
Progressive disclosure has been a design tenet since the 1980s. Show what matters now, defer the rest.
It’s also easy to skip, because deferring means knowing what depends on what, and nobody had written that down.
So I did.
The classic example: a print dialog. Three settings cover almost every job. The rest wait behind one click.
The idea: a sequence, not a list
What I’d put first, and what could wait
The page would stop being a list of everything and become a sequence. Deciding what went where meant knowing the products the way an admin does.
Acting as the customer
Answering the admin’s questions before they asked them
What are the most critical setup tasks?
What depends on what?
Which permissions and prerequisites apply?
Is there impact on end users and admins?
How does an admin know a task worked?
What are next steps when a task is completed (scenario chaining)?
What should we recommend once the solution’s running?
I worked out those answers across Information Protection, Insider Risk Management, and Communication Compliance. I’d worked on all three for years and tested them in my own environments, acting as the admin. Then I pressure-tested the answers with product managers, designers, and engineers.
The pattern work I’d done alone turned out to be the spec.
Building the framework
Five types, three modes of action
A setup task, a nudge about an unused feature, and an urgent alert aren’t the same thing. They’d all been built the same way.
The types came from years of support cases and customer requests, worked out with product management, engineering, and research. The types were only half of it.
Making the choice repeatable
Four decision trees settle where any proposal lands
One of the four trees. It sorts any proposal into one of the five card types, so two people on different teams land on the same answer.
Same anatomy, every time
What a task always tells you
Every task shows a priority label, a time estimate, and a completion state. Open one and the panel always holds:
Overview of task
Required permissions
Prerequisites
Steps
Impact on users and admins
Call to action
Link to learn more
When the system can tell a task is done, it flips to Completed on its own. When it can’t, the admin marks it complete so the rest of the team knows.
A complete setup task panel.
When admins can’t complete it
A permissions gap doesn’t hide the task
If an admin doesn’t have rights to complete a task, we still show it. The task is part of what the solution needs, whoever does it. Hiding it would leave a hole in what the admin understands about setup.
So we call out that they don’t have the right permissions, and offer three ways out:
The same task, without the permissions to do it.
Setup is just the beginning
Next is to keep it running smoothly
Getting a solution running is the start. Keeping it healthy is the job. After setup, new recommendations keep it:
Every recommendation in one place
Tasks are grouped into solution-specific themes, like detection, investigation, and remediation, tracking progress along the way.
All recommendations, grouped into themes. An admin can see what’s completed and what needs to be done without opening anything.
And it knows when to stop
The page the bulletin board never had: an empty one
Recreation of the all-caught-up state. Completed tasks leave the page instead of sitting on it, so the page stays a record an admin can trust.
The outcome
What shipped
Setup checklists, task detail panels, an “All recommendations” page, and progress tracking, live in Insider Risk Management, Information Protection, and Communication Compliance
The same kind of page as the before state, with the framework in place.
What it did
Three things changed once the framework was in place
Highlighted by Microsoft
Kudos
In their words
The collaboration you had with [a senior product design manager] and PM on the [Insider Risk Management (IRM)] onboarding flow will have lasting impact beyond IRM to other solutions, and it was a fantastic example for me to share with leadership on strategic content design.
Principal Content Design Manager
Microsoft
Through your thoughtful guidance, suggestions, and edits the admin experience for customers has continuously improved. Especially when we focused on usability and support, you could tangibly see how simplifying and clarifying the customer facing strings and messaging helped reduce support escalations and customer pain points.
Senior Product Manager
Microsoft