Microsoft Purview

Onboarding and recommendations framework

Challenge

Security solutions required admins to complete several setup steps before they deliver any value. Nothing told them which steps mattered, what order to do them in, whether they had permission to complete them, or what came next.

Solution

A content and design system for setup and post-setup recommendations. Five recommendation types, three modes of action, decision trees for placement, and one anatomy every task follows. Built with UX design, product, and engineering. Documented so other teams could adopt it.

How I contributed

  • Diagnosed the pattern from years of customer support cases and requests

  • Defined the recommendation types, modes of action, and placement logic

  • Wrote the content guidelines, component anatomy, and accessibility annotations

  • Partnered with UX design, product, and engineering to ship it

Team: Microsoft Purview, Security Content Design

Setup tasks on a solution overview page.

The bulletin board problem

Every team added their own tasks. Nobody coordinated.

Solution landing pages looked like a coffee shop bulletin board. Notices shouting at the same volume, some stale, some contradicting each other.

  • Message bars, promo cards, banners, and callouts piled up on solution pages over years. Each came from a different squad. Each claimed to be the important next step. None knew about the others, so nothing could be ordered, prioritized, or tracked.

  • Admins setting up a solution couldn’t tell what mattered, what was already done, or what would break if they picked wrong.

  • Worse, many never went away. A completed task kept sitting there, so the page couldn’t be trusted as a record of anything.

Before state based on a real solution page. Numbered issues appear below the page.

Nothing before its time

Progressive disclosure, applied to setup

The page above is from a new tenant. Day 0. No policies, no onboarded devices, no activity. Most of what it showed couldn’t be acted on yet. Policy health needed a policy. Device data needed onboarded devices.

Progressive disclosure has been a design tenet since 1995. 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. First, the few tasks that unblock everything else. Examples include:

  • Assigning permissions

  • Creating the first policy or label

  • Onboarding devices

  • Turning on analytics and auditing

Then the secondary setup tasks. Then recommendations, once there’s enough data to base one on.

The page stopped being a list of everything and became a sequence.

What I had to know first

Acting as the customer across three solutions

Deciding what a product should recommend meant 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 other 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 three Microsoft Purview solutions: Information Protection, Insider Risk Management, and Communication Compliance. Then pressure-tested them with product managers, designers, and engineers.

Before it was a system

I’d been shipping pieces of this for years

  • 2016. One-click activation tiles, so admins could turn a capability on without leaving the page. Auditing opt-ins rose more than 80 percent.

  • 2017. Help bubbles (aka infotips), after I got engineering to support them. Used over a thousand times a day.

  • 2018. Insight-based recommendations, which I wrote, designed, and coded.

  • 2019. Guidelines for Setup and Recommendation patterns in the Microsoft 365 admin center.

None of it was a system. I was one content designer attaching guidance wherever it fit. It became a system after I had a UX design partner and product management behind me. The pattern work I’d done alone turned out to be the spec.

The decision layer

The types were only half of it

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.

So I defined five recommendation types:

  • Setup tasks

  • Solution-wide

  • Feature-specific

  • Contextual

  • Spotlight

Then three modes of action, based on how much work the admin has to do: one-click, hybrid, and manual.

The types came from years of support cases and customer requests, worked out with product management, engineering, and research. Making the choice between them repeatable was the other half of the job. Four decision trees make the call:

  • Which of the five card types fits

  • Which mode of action it needs

  • Setup task, recommendation, or nothing at all

  • Recommendation or report

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 associated panel structure 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 do it themselves

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 two ways out:

  • Email admins who are assigned the correct permission roles

  • Directly assign the task to one or more of them.

Either completes the task for the admin, but not the whole org.

They can also just mark it complete, for the times they walked down the hall instead. A tooltip on that button says the same thing, so nobody assumes they’ve cleared it for the team.

Same task, opened by an admin without the permissions to do it.

Setup is the beginning

Stable, current, secure, robust

Getting a solution running is the start. Keeping it healthy is the job. After setup, new recommendations keep it:

  • Stable. Fix policy errors, triage unreviewed alerts.

  • Current. Surface new capabilities the admin doesn’t know about.

  • Secure. Flag detected risks, with a path to remediate.

  • Robust. Pull in data and activity from unconnected sources.

Tasks are grouped into solution-specific themes (like setup, investigation, and detection), tracking progress the whole way.

All recommendations, grouped into themes. An admin can see what’s completed and what needs to be done without opening anything.

What shipped

The framework runs in production across Insider Risk Management, Information Protection, and Communication Compliance: setup checklists, task detail panels, an All recommendations page, and progress tracking.

Other solution teams picked up the components and guidelines, including the security trial experiences.

My manager called it an example of strategic content design and took it to leadership. She expected the pattern to outlive the solution it started in. It did.

What I’d improve next

  • Let admins control what they see. Recommendations should narrow to the threats an org actually worries about and the regulations it has to meet. A bank and a hospital shouldn’t get the same list.

  • Measure by task type. We tracked completion, but not which tasks admins abandoned. That tells you where setup really breaks, instead of where you assume it does.

  • Automate the pipeline. Feed a solution's support case load into the framework so we can identify new tasks that head off common issues before customers hit them.

  • Apply guidelines with AI. Check new tasks against the content design guidelines as they're coded, and update the content automatically so quality holds without a human reviewing every string.