• Industry
  • Project
    Website Application
  • Tools
  • Team

    Project Owner, UX Researcher, Content Designer, Engineering

  • Role
    Product Designer

Project Brief

The application, Microsoft 365 Defender, provides protection against spam, phishing, malware, Safe Links, and Safe Attachment threats by administering a compilation of settings in the Preset Security Policies (Policies) templates.

Additionally, impersonation protection was added to the Preset Security Policy settings. Impersonation is where the sender or the sender’s email domain in a message looks similar to a real sender or domain:

  • An example of domain impersonation is or
  • User impersonation is the combination of the attacker’s display name and email address. For example, might be displayed as Bill Gates, in the recipient’s inbox.
  • What problem are we solving?

    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 within 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” within Preset Security Policies. As a result, customers then have to disable Presets and use Custom Policies to apply impersonation…defeating our goal to promote/drive Preset Policy adoption.

  • What value are we providing our customers?

    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 (a combination of all sub-policies: anti-phish, anti-spam, anti-malware, Safe Attachments, Safe Links in a single, unified experience).


I started by analyzing each step in the current impersonation protection configuration workflow. This process allowed me to highlight discrepancies within key phrases that were used to inform and direct users.

The next step involved reviewing the current Preset Security Policies environment to prepare for the integration of impersonation protection. This uncovered various problems within the existing workflows: the value of Presets wasn’t clearly defined for the customer and we were using a wizard to configure and manage settings which did not provide the best experience. Nor did it match UX patterns in other areas of the product.

NDA Project
Impersonation Protection


As a designer, I wanted to meet the goal of the project by seamlessly integrating impersonation into Presets; however, I felt that I would be doing a disservice if I did not attempt to tackle the issues that were uncovered.

Due to the amount of issues that were uncovered, engineering constraints prevented me from providing a separate management experience and tackling some of the other issues; nonetheless, I added a way for users to easily configure and manage impersonation settings with the use of tables that provided the ability to view all entries along with search and delete functions. This also satisfied the design requirements.

User Testing

I didn’t allow the engineering constraints prevent me from continuing to push for all of the issues to be addressed. I utilized an experience review to further highlight the issues.

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.

The Solution

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.

The user testing results provided the Project Manager and other stakeholders with qualitative data that reinforced the need for continued enhancements.

Since its July 2022 release:

  • 64% increase in Preset adoption (66,176 to 108,823)
  • 114% increase in unique recipient count (22,313,501 to 47,818,501)

Powered by Google Forms

© 2007-2023 JxnGraphix