Web Policy rule builder is a rule-based, web-gateway-security configuration app. Web Security Administrators (InfoSec teams) configure rules to control and monitor web traffic between an enterprise boundary and the internet. These rules control and filter web traffic originating from users accessing the web and block or allow, for example, downloads from the web. This ensures protection against web threats such as viruses and other malware, data exfiltration, etc. which can be incurred through uncontrolled web access.
The Problem
The Web Security Administrators are currently provided with a Configuration UI which is mostly switch (on/off or enable/disable) based.
- Limited control via User Interface (mostly switches)
- For complex rules, customers need to learn the product’s proprietary code language OR spend money on PS (professional services) hours.
Proposal
To build a tabular rule-builder that enables Security Administrators to write complex rules via User Interface, without letting go of:
- The existing simple UI works very well for simple Use Cases and is an easy out-of-the-box (plug-configure-play) solution.
- Complex code insertion for complex use cases.
The idea was to find create/build a “Standard” interface where the Users can write complex rules in the comfort of usable UI.
The Trifecta
We worked as a trifecta consisting of UX, PM, and Engineering.
Within the UX team, we had an internal trifecta consisting of a UX Researcher, a UX Designer (Interaction Designer), and the Design System lead. Although I led the UX efforts for this product, I took timely help from UX researchers to conduct research sessions and document findings. And, my collaboration with the Design System lead helped us collaborate on new component requirements, assessing and re-using existing components.
Discovery
Approach Evaluation
We built a high-level wireframe to conduct User Research sessions to understand if this direction was apt for the Users, and also to understand the key issues that they would like to see in the solution.
Research
Separate research sessions with 7 customers (around 23 participants) were conducted with the following goals:
- Feedback on the proposal
- Identifying key pain points
- Prioritizing features
With the outcome of the research sessions, features for MVP was identified by the Product Management and UX together.
Information Design
Dependency
Security Policy (application) is positioned within a suite of other security applications under one platform. There is dependency on Configurations & List repositories which I first needed to understand the working and building of the same.
Structure/Hierarchy
Irrespective of whether we are building a product from scratch or adding features to an existing app, it is important to understand the information design so that we cater to contextual placement of:
- Information
- Actions
- Indicators (/messaging)
Anatomy of a Condition
In this app, a condition is the basic unit that constructs a rule, hence defining all the combinations that make a condition unfold underlying interactions.
Workflows/Interactions
Due to the complex nature of this application, we had to carefully stitch multiple interactions to help users (security administrators) build rules.
Rule Library
Since the current/existing app had pre-defined rules that could be configured, we planned to provide these rules in a library, which could be imported into the policy along with custom-created rules.
Adding Rules
We defined 3 types of rules
- Library Rules
- Custom Rules - via UI
- Custom Rules - via Code
Nested Rulesets
Since the entire security policy works on the basis of filtering/scoping web requests and responses, an interaction to add nested rules was prepared.
Scoping Rules
Scoping was done based on numerous factors like source and destination ports, user-groups, location and many more.
Many more workflows were created as a part of MVP for this app/product to be functional which is not documented in this case study
Prototypes
Multiple Prototypes were created to communicate the interaction flows. This helped the Customer Validation sessions, Front-end Dev team, SME, etc. explain the flows.
Key Views
-
This rule-builder is pretty complex in nature, and the UX efforts went in for 7-8 months along with all the customer validation sessions. I failed to explain everything here, but we could set up a call and would be glad to walk you through the entire process.
Thanks for your time!
Appreciation
Some of the team members I collaborated with voluntarily sent me some appreciation for the approach and ownership I delivered on this project.
Note: The comments shown beside are backed by emails sent to me.
"Appreciate the efforts you have put in collaborating with stakeholders, research, organizing tasks and designing the Std View wireframes."
UI Engineering Lead
"Thanks for coordinating and working with the team on all UX activities for UCE and providing information in a timely manner."
Director, Engineering
"Chetan,I'd like to thank you for your relentless support, guidance, expertise and work. You are an expert in UX and have the ability to listen and transform technical details into high fidelity UX screens and guidance for your engineering counterparts.I do very much appreciate you and all you are doing. Your work, diligence, support and your friendly, calm and professional attitude in our day 2 day interaction but also in difficult situations make a difference - for us as team and for us as business.You are a valued member of our team. Your work makes it is possible for us to advance and growing sky high...and beyond."
- Thanks, Michael
Sr. Director, Product Management
"You are now a pillar of the team"
Director, User Experience
The above comment is special to me as it was from my reporting manager
Let's Talk
+971 509076140 (UAE) OR +91 9379416140 (INDIA - please message on Whatsapp)
chetanshridhar@gmail.com