Microsoft

  • Industry
    Technology
  • Project
    Website Application
  • Tools
    Figma, Fluent
  • 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 microsoft.com is micros0ft.com or microsoft.net.
  • User impersonation is the combination of the attacker’s display name and email address. For example, attacker@cyberbully.com might be displayed as Bill Gates, billgates@microsoft.com 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).

Research

I began by understanding each of the users and roles involed in protecting organizations against cyber threats. I partnered with the UX Research team to gain a better understanding of MDO’s users and the issues they experienced within the product.

For enterprise customers, the IT Security Administrator is our target user, this is also referred to as a Security Operations person or SecOps. But in the case of smaller businesses, the user may wear multiple hats and may not have a security operations background. I needed to provide a solution that would work for all organizations, regardless of their security background.

  • IT Security Admin

    Setup and enable security against cyber threats

  • Security Analyst

    Research and act on organizational threats

  • Cyber Awareness Program Manager

    Increase awareness and improve respones to threats

  • Information Workers

    Grow awareness and respond to threats in my environment

Analysis

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

Design

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.

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.

  • Scores
  • Experience Review

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)

    Let's chat


    © 2007-2024 JxnGraphix