Project Owner, UX Research, Content Designer, Engineering
The application, Microsoft 365 Defender, provides protection against spam, phishing, malware, Safe Links, and Safe Attachments threats by administering a compilation of settings in the Preset Security Policies templates.
Additionally, impersonation protection was added to the policy settings. Impersonation is where the sender or the sender’s email domain in a message looks similar to a real sender or domain:
The UX research team conducted a study on the barriers to Preset Security Policy adoption. One of the key barriers was the inability to configure users and domains to protect for the impersonation security controls in the Preset Security Policies.
Today, if a customer enables presets, impersonation is included in the preset but doesn’t actually get applied. That’s because security admins cannot specify “users to protect” and “domains to protect” for preset security policies. As a result, customers then have to disable presets and use custom policies to actually apply impersonation…defeating our goal to promote/drive preset policy adoption.
Customers are able to better understand their use of presets today so that we can further improve experience and increase adoption. This moves us closer to a unified policies concept (combination of all sub-policies: anti-phish, anti-spam, anti-malware, Safe Attachments, Safe Links in a single, unified experience).
Analyzing each step in the impersonation protection configuration workflow and uncovering discrepancies within the key phrases used to inform and direct users.
Understanding the framework of impersonation protection, the entities involved, how it works and its configuration within MDO.
Reviewing the Preset security policies environment to prepare for the integration of impersonation protection emphasized various problems within the existing workflows.
A cross-functional team of 10 people gathered for 90 minutes to watch a pre-recorded participant attempt four core tasks in the Preset security policies UI.
The group voted on the craftsmanship of each task. The scores reflect how polished the team felt the experience was (in behavior and appearance) and how proud they were of it.
Additionally, the group participated in a silent brainstorm of solutions for the issues discovered in each task flow.
I updated the copy to provide a better description of the benefits of Presets security policies. I went against the initial requirement of a separate flow and combined impersonation within the current Presets wizard. It felt like a more cohesive protection feature and experience. In addition, the impersonation fields could remain optional for the user which still satisfied part of the requirements.