Conditional Notifications @ Expel

UX + UI

This project highlights—

User testing

Stakeholder management

Design principles and UX strategy

UI prototyping in Figma

Testing and releasing

Role:

UX Designer

Main Collaborators:

Product Manager

Two Backend Engineers

Front-end Engineer

QA Engineer

Tools:

Figma

Lucidchart

Gainsight

Confluence + Jira

What is Expel?

Expel is a cybersecurity SaaS helping enterprise customers with managed detection & response.

As the UX Designer on the Notifications team, I was focused on designing ways for customers to react quickly to critical threats and increase visibility into their environment to improve their security posture.

My first objective was to understand the problem before taking over the project.

Here was my take… ⤵

Background

For my first journey at Expel, I took over for the design lead who had been working on a new, more configurable notification experience with the product team for over two years.

This project was a huge undertaking as it required a large amount of engineering effort to design a whole new notifications system. But once it was completed, we would have a much more flexible way to add new notification types, and evolve to the next stage of the notification experience: conditional notifications.

As the new design lead, my first goal was to take in as much information as possible by:

  • ramping up on all things cybersecurity,

  • doing a deep knowledge transfer,

  • refining and building UI prototypes in Figma for testing and implementation,

  • and working with the team to launch conditional notifications for customers.

What exactly are conditional notifications?

A condition is a property (type + value) that is added to a notification rule to allow for more granularity in what you are getting notified on.

Conditions allow a notification to become more specific for when it is triggered so that you can customize what types of notifications you want to receive and where they are sent.

Problem Space 🚨

In B2B cybersecurity, each customer has their own unique preferences and workflows. In the legacy design of notifications, customers only have a limited set of options (checkboxes) for what they can get notified on. This means that adding new conditions takes a lot of time and backend resources.

If customers need to get notifications on more specific types of events, they have to make a request to their Engagement Manager (customer support) to get a feature flag set up to receive specific notifications the way they want to.

Personas 👥

As a designer, I wanted to hone in on who would be the main users of this feature to better understand their behaviors, preferences, problems, and needs.

  • Internal (Expel)

    • Engagement Managers 

      • Motivation: support customers every step of the way, and might perform tasks on the platform on behalf of the customer.

  • External (Customers)

    • Security Analyst

      • Motivation: monitor notifications and respond timely and accurately.

    • Cybersecurity Manager

      • Motivation: optimize my teams workflows so they can be as efficient as possible and we maintain excellent service metrics.

PROJECT KICKOFF 🚀

I created a one-pager in Confluence to anchor the why, what, and how of this project.

Defining our stakeholders made sure we defined how to involve others what kind of communication they need throughout the project.

IMPACT 📈

How can conditions benefit our users?

The benefit of adding a condition to a notification rule is that you are able to:

  • decrease notification noise so that you are optimizing your workflows, and

  • increase visibility into triggered events from Workbench that you want to be aware of.

How can conditions benefit our business?

Conditional Notifications is a critical feature to help us provide next level notifications customization for our customers.

This feature can help us:

  • retain our existing customers (NRR) by making our service more sticky.

  • increase gross margin (GM) by allowing customers to configure their own notification preferences, as well as freeing up engineering to be able to add more event and condition types in a much more flexible system.

How can we measure success?

  • Adoption rate [# of conditions added to a notification]

    • How many customers are adding conditions to their notifications without needing any customer support?

  • Decrease in feature requests for new condition types

    • How many one-off requests were the Notifications Team receiving over one month before we launched versus after?

Now that I had synthesized my understanding, the next steps were to focus on the next iteration of the design process…

REFINING THE DESIGNS

Usability Tests 🧪

I designed a high-fidelity prototype in Figma which had three distinct task flows.

I then ran a series of usability tests, gathered insights, and synthesized in Condens, which you can view in more detail 👀.

  • Benchmarking was a tactic to measure improvements in usability overtime.

From these insights, I updated the UI designs to incorporate the feedback.

WHERE TO BEGIN…

Quantitative survey 📊

In order to understand on what types of conditions would have the most impact on our users, I ran a survey to gather quantitative data.

SETTING MILESTONES

Staying in Scope 🎯

In collaboration with the Engineering Lead, we defined the milestones for the project to keep the initial release in scope.

I created a visual living artifact (some images removed for security pursoses) which helped:

  1. maintain alignment with my product team,

  2. hold efficient feedback sessions with stakeholders, and

  3. track future iterations that could make the most impact on our users.

DESIGN PRINCIPLES 📐

To stay aligned with my team on why design choices are being made and the impact it has on the user, I created conditional notification design principles.

This artifact especially supported the team through the development phase because we all understood the expected behavior and design without doubt or confusion (a.k.a. constant back and forth or swirl).

TESTING AND REFINING 🔧

I worked closely with my QA Engineer to refine the expected behavior, uncover some other use cases that we hadn’t discovered earlier in the process, and make sure we are accounting for all error states.

  • A facilitated review session with my engineering team got us all aligned on how the feature should behave.

RELEASE 🕊

How can we introduce this new feature to the world?

Internally at Expel:

  • I worked with the Product Manager to develop internal communication on the release of the product.

  • Making sure we maintained consistent communication on the upcoming release of this feature kept our stakeholders aligned and excited to share with customers.

Externally to our customers:

  • I collaborated with the Principal Content Strategist to create and update documentation in the knowledge base.

  • I built a quick feature announcement in the platform using Gainsight, which targeted users on specific, non-critical pages to call attention to this new feature.

MEASURING RESULTS 📏

We were able to increase gross margin by decreasing requests for one-off solutions related to conditional notifications by 94%!

This meant far less bottle-necking, Engineers with more capacity to work on other high priority issues, and happier employees who can serve more customers.

NEXT STEPS ⏭

From this first release, we prioritized the next milestones based on user research which included:

  • more condition types based on user needs [+ customizability]

  • the ability to select ANY or ALL conditions within a notification [+ granularity]

  • and the ability to select IS or IS NOT [+ simplicity]

Next

Conversion @ HelloAva