DESIGNING THE SMS POLICY WORKFLOW EXPERIENCE
Introducing a reimagined policy workflow for the TippingPoint Security Management System to simplify policy tuning around Security, Performance, and Visibility.
The following case study walks through the design process focusing on design proposals for augmenting the filters tuning experience.
THE PRODUCT
The TippingPoint Security Management System (SMS) provides central visibility and ease of managememt of IPS security policy and devices.
The SMS JAVA console from 1997 to now. Customers are still using this interface.
The web based SMS UI started with Threat Insights in 2016.
THE PROJECT
In October 2017, I was asked to design the SMS policy tuning experience. I collaborated with the product manager to understand the high level business goals and our customer pain points.

In a nutshell, our business goals were to:

  1. Make it easy to tune security policy.
  2. Offer assistance when balancing between performance and security.
  3. Bring visibility and accountability to other team members in the tuning process.
"Securing the world from evil hackers by making it easier to tune your IPs policy."
Russ Meyers (Product Manager)
THE BACKSTORY
Before diving into the preliminary design, I first focused on the steps our customers are currently experiencing when tuning filters.

I conducted a task analysis to thoroughly understand the current filters reviewing and performance tuning on the current Java console.


FILTERS TUNING IN 14 STEPS, (PERFORMANCE MANAGEMENT CURRENTLY NONEXISTENT)

  1. Read filters release notes in email.
  2. Search filters enabled by default.
  3. Read individual filter description.
  4. Understand recommended settings.
  5. Decide if filter is unique to my environment.
  6. Place filters in trial mode for X weeks.
  7. Monitor filter events for X weeks.
  8. Document changes in spreadsheet.
  9. Send email to team of changes.
  10. Decide on recommended settings.
  11. Enable all filters once decided.
  12. Add dates/comments for auditing.
  13. Deploy new filter policy to production.
  14. Rinse and repeat on weekly basis.
THE DESIGN
I decided it was a great opportunity to rethink the entire filters tuning experience rather than porting over the feature from the Java console to the web. I proposed a workflow to assist customers and eliminate many unnecessary manual tasks – essentially an automated assistance guiding them through the filter tuning process.
Introducing Policy Workflow
In its entirety, the new policy workflow consisted of two interrelated features:


  1. Filters for Review
  2. Central Performance Management
"Really like the concept of flagging a filter for review - I think this is a key concept that would really kick ass"
Russ Meyers (Product Manager)
DESIGN PREREQUISITES
MAPPING THE TERRITORY
I started my design process by creating a map with the goal of understanding the complexity of the SMS system since I've never used it before. I find it helpful to see the big picture and the constraints of the framework.

These were some of the high level questions I wanted to validate:

  1. What are your day-to-day work like?
  2. What information are important and what data do you find useful for filters and performance tuning?
  3. How do you prioritize given a large list of filters?
Mindmap of the SMS
The map captures the complexity of the SMS product.
DESIGN EXPLORATIONS
EXPLORING THE CONCEPTS
By far my favorite part of any design project is exploring different concepts, doing competitive analysis, and connecting the dots between different ideas. It's essentially a blank canvas and feels like I'm channeling my inner Bob Ross.

Below were some early concepts that I explored for the policy workflow – some were refined... others didn't make the cut.
Early designs for a Filters for Review dashboard (from top to bottom): filters by hits, filters by severities, whether it's relevant to customer environment.
Early designs for Filters for Review page. Each filters when expanded shows detail data. Side Context panel show more contextual information.
Early design for Threat News Feed. It shows different threat categories, and helps customer stay on top of the latest threats in the wild.
USER RESEARCH
GETTING FEEDBACK ON STORYBOARDS FROM CUSTOMERS
After sharing my concepts with the team, we decided to start with the filters for review as the foundation of the tuning experience.

I worked on the basic building blocks and created two storyboards based on the early design explorations. In order to get the team to agree that I was heading in the right direction, I partnered with a user researcher to validate the design.

Specifically, I wanted to see:


  1. Are there issues and problems with the designs?
  2. Are there suggestions on improving the designs?
  3. Are the designs useful or too risky and would cause more issues?
FILTERS FOR REVIEW
The "happy path" user flow for the filters tuning experience, starting from the filter perspective instead of from the profile perspective (i.e. a customer reviews the filter and then tune it in the relevant profiles vs. going to each profile and tuning each filter).

This was a fundamental shift in how customers were used to tuning their policy.
The storyboard showing the major flows starting from a banner with a call to action button which when clicked on takes user to the Filters for Review workflow.
CENTRAL PERFORMANCE MANAGEMENT
At the same time, customers complained that there were insufficient performance-related data to help in the filters tuning process. One top-of-mind questions were: will it impact my IPS devices if I turn on these filters.

I storyboarded a "happy path" for this scenario below and will go into a more details as to how I evolved the design later on inte Wireframes/Prototypes section.
Performance tuning also starts from a banner, notifying users of the performance incidents, and to take action and starts the performance tuning workflow.
UX WORKSHOP IN AUSTIN (NOVEMBER 2017)
About
Contact
Resume
LinkedIn
Twitter
MHLStudio © 2021