policy
The journey of a policy re-design.
Problem: The current policy system in Stealthwatch consists of over 20 pages and widgets in which policy parameters can be created, read, updated, and deleted (CRUD). These policy elements will conflict with each other, and having full visibility into your system and what it is actually configured to do is near impossible. The biggest issue among customers was noise. The ability to use policy to tune out the noise is difficult at best. While it can be used with surgical precision, it is often used by trial and error.
Task: Redesign the policy system in order for user to gain greater insight into their system and provide them with the ability to easily and intuitively tune out the noise in the system. Allow the users to see what they want to see, and hide the rest.
Click on the image below to see the HUGE journey map (opens a new window/tab)
policy
Click here to see the HUGE journey map (opens a new window/tab)
Examining the current policy model
Deconstructing the current policy model
Step 1
Policies were confusing. There were upwards of 4 per host group. Some users had 20,000 groups. This was unsustainable. Customer were confused and could not accomplish their goals with the product. FOr some it was infinitely flexible, for other it was completely unusable. Either way it was a mess of screens and contradictions and overlaps.
Step 2
Research started with untangling the twisted web that was policy and developing a real understanding of the underlying architecture and its failings. We had to diagram out typical workflows and policy realtionships such as how do hosts relate to policies and rules, and how do policies relate to hosts and groups and rules and how do alarms relate to all of those components
Initial prototype (retaining the current policy engine)
Step 3
The first stab involved a tabbed interface that allowed the user, from one page and not 20+, to see the current policies from a host or group point of view, a policy rule POV, and see them across all 4 policy types.
In addition, based upon user input, it proposed a new method for policy deployment
Revamping and simplifying the user workflows
Step 4
It quickly became clear that the approach of simply building a new UI around the current, broken system was not the right solution for the long- term. We developed a new policy system from scratch that would accomplish the same goals, but in an intuitive, simple, and friendly manner.
It was determined that to move forward, we needed to design 2 approaches: an approach using a brand new architecture that was forward-looking, flexible, and simple, and an approach utilizing the current architecture as a fallback plan for the realities of the release and development cycles and to account for shifting priorities and other time constraints.
More iterations, and a new UI prototype
Step 5
The fallback approach was designed and tested with user input and resulted in a much improved interface built to handle the unweildy policy engine.
20+ screens were distilled down to ~5.
It was still the same faulty policy model, but it was also a vast improvement over the previous UI scheme. The feedback was mixed. Some were glad to see any improvement, and some were upset that it was still the old policy model underneath it all.
Iterate prototypes based on a policy re-architecture
Step 6
The second approach was deisnged which required a new policy model in order to execute. However, it tool all of the previous models functionality and distilled it down to 3 screens: a master rule list page, only 1 type of rule instead of 4 or 5, and a unified visual rule editor that was an order of magnitude improvement over the current policy model. It was future looking, flexible, and removed the confusing and conflicting hierarchical model and utilized tagging instead. It was far more flexible than the old system as well.
Many iterations later: Re-architecting approach
Step 7a
The later refinements of the new policy model approach, due to inputs from much user research was almost a home run. The improved visual editor was met with even more praise, and very complex rules allowing for surgical precision were possible, and yet were still easier to build and understand than the most simple rules in the current system. It tested well and was met with enthusiastic response from our users who almost all asked “when can I have this?” or “I want this now. This will save me so much time.”
Many iterations later: current policy model approach
Step 7b
The fallback approach remains fairly similar to previous attempts, and is met with similar responses. The main rules list page receives a graphic facelift and sorting and filtering options are tweaked, but the concepts and layouts all remain the same. The rules editor is slightly streamlined.
Users like that it is far easier than the current policy method, but also understand that the underlying policy model remains the same and that this is simply a facelift. For many that is much of an improvement already. For others, it still doesn’t help them accomplish their goals.