01.
THE SUMMARY
Backstory
In mid-2017, Citrix rolled out a Cloud-based Web Application Firewall as a part of Networking Solution. WAF as an offering protects web applications and infrastructure from cyber-attacks using advanced security tools.
Through offerings like these Citrix wants to tap a growing market of Small businesses with less dependency on Customer support. This could be seen as a tectonic shift in the business model. Looking at multiple big and small competitors, Citrix wanted to make sure that the solution is as simple as possible. And the process of deployment should not go for weeks; instead should be done in hours after placing companies data into any cloud they wanted.
Being a part of this team which delivered the project on time gives me immense pride and motivates me a lot.
Let's try and understand the context in bit detail through this story.
So, How does WAF work?
Sometimes it becomes overwhelming to hear complicated terminologies. To explain WAF in layman’s term, I would like to compare it with “rules” setup of any popular Email Client. It will give you a clear picture of how does the system work.
02.
THE OVERVIEW
Project Basics
A. Role, Deliverable and Team Structure
Worked as a Product Designer and contributed in end-to-end product development, from immersion to delivery. My main focus was on Interaction design and facilitating small design research exercises.
Here’s the structure of the team in which I worked:
B. Business & Usability Objectives
I. Business Objectives
■ Pure cloud: Create a Web Application Firewall which should be a pure cloud solution that will help customers manage their application security.
■ Users Acquisition: Create solutions based on small business customers in mind. Their resources and time play a huge role in framing the designs.
■ Easy setup: If possible allow users to set up a Firewall with just few mouse clicks without taking him to cumbersome walkthroughs.
■ Understandable: The flows are filled with technical jargons which again create a bit of friction with the users. Try and avoid these phrases.
II. Usability Objectives
■ Design Alignment: Align Web Application Firewall to the family of Cloud Offerings so that they look like a part of a common ecosystem.
■ 15% Reduce Error: Provide user-centric information upfront and hide redundant info for the users so that human error reduces by 10-15%.
■ 50% Time reduce: Work on Experience which is joyous and drop-dead simple to use so that the time taken to complete the task reduces by 50%.
■ User Retention: Increase users’ retention by adopting languages which are simple to use with coach marks if required.
C. Product Challenges
I. Business Challenges
■ Overcoming the perception of complicated product image (Especially On-Prem).
■ Availability of less Engineering resources and less scope or reinventing the wheel.
II. UX Challenges
■ There was no existing WAF solution for Cloud (by Citrix) to benchmark and improvise onto it.
■ There was no research done till yet to see what users’ like and what users’ don’t.
■ WAF on-premises had to be re-thought again to cater to Cloud Users.
D. Top Constraints
I. Product Constraints
■ Timeline of 1 month including research.
■ A limited resource to test the designs in the middle and at the final stage.
II. Design Constraints
■ Follow ongoing design guidelines of Citrix Cloud
■ To reduce engineering efforts, stick to the existing pattern library.
III. Engineering Constraints
■ No rich database of components in existing design pattern repository (e.g. buttons, tables, filters etc.).
03.
THE IMPACT
Success Metrics
■ WAF has become $50 M/Year business in just 1 year of launch (2019).
■ Few key factors for the win was considered to be Experience, Price, Scalability & Integration.
■ WAF Cloud overtook three biggest competitors which are F5, AVI Networks and A10 Networks in a very short time.
■ The product was one among 7 other cloud offerings which helped organisation to get 444 new businesses in Q1 2019.
04.
CUSTOMER INPUTS
Research Process
To get started with the exercise we listed down list of Concerns and what could be a probable approach to get answers for the same. This process helped us frame research exercises which at the end helped us in getting the desired result.
A. Concerns and Clarifications
I. Concerns
■ Whom are we designing for?
■ What is their day-to-day work process? Whom do they interact with?
■ What do we know about WAF On-Premises flow?
■ Can we take any inputs from WAF flow on On-Premises?
■ Do we have any problem/ loopholes in the existing configuration?
■ What data/ configuration settings of On-Premises configuration is relevant to Web Users?
■ How are competitors solving WAF problems?
II. Approach to Validate these concerns
■ Get details about the users from the Research Team.
■ Study of Information Architecture of WAF On-Premises & map steps & pain-points taken to achieve a task
■ Analyse competitive landscape and see how market players are solving the problem.
■ Create a list of features and align them as per their importance after talking to the users. (Card sorting).
■ Prioritise these findings (2x2 matrix) and align them to common product goal.
■ Document key findings.
■ Define few user personas
B. Whom are we solving the Problems for?
The main user of Web Application Firewall is an Application Security Engineer of any organisation.
On a day-to-day basis, they understand and analyse applications, create policies, take emergency response actions, and even help security analysts investigate security incidents. Most of them have a background around Application Security.
C. Information Architecture Study
To start with internal analysis, we looked at existing on-premises offering by Citrix. The core intent was to take out elements which might work for Cloud. One thing which was pretty evident about the On-Premises users was, they held a huge pie of Citrix business, and because of that Citrix has explicit customer support for them to facilitate their problems.
But for Cloud, the business model was slightly changed where we were targeting Small and Medium scale businesses. To support all of them the only way left was good user experience powered by efficient customer support. The idea was to reduce hand holding and empower the users to do the task by themselves.
I. Flow for setting up a Firewall Policy on On-Prem
To set up a fresh Firewall Policy on On-Premises a user takes 5-6 steps which are pretty straight forward. The only trick is once the policy is set up, one has to bind it to get them working. Binding is like assigning priorities which policy should take effect first and which last. (Higher the number lower the priority. And the number can go from 1000 to 0). The chart below explains the process of creating a policy.
II. The process of Policy Binding
Once the policy is set up, to Bind a fresh policy on On-Prem User needs to go through 22 steps process within 6 pages. On an average user will require at least 16-20 step even if he has Firewall Policy setup already.
III. Removing a policy on On-premises device
And the system becomes even more complicated when a user wants to manage a policy set up with small changes or wants to delete a policy. He has to really know the flow in and out. For a trained user as well the process becomes pretty challenging. And because of this, Users don’t modify existing setup and prefer creating a fresh policy.
D. Competition study
After taking pointers from the IA flow we started looking at Competitive Landscape. To empower the Business Choices and Design Decisions, an analysis of the services of leading Competitors was done. There were many UI patterns and Interaction models which were listed. These set of models were further stacked against Citrix to see where we are lacking.
E. Preferred Attributes
Talking to the users can easily uncover usability problems and expectations one does not know existed. To drive that we gathered 5 sets if System Admins internally (Because of lack of time) and asked them if they were to design a new WAF tool:
■ What features would they want to have in it?
■ How would they be different?
After our brainstorming, we gathered as a team and started aligning the inputs in order to improve the User Experience in the expected time. Through Affinity mapping and later prioritising them in 2x2 matrix gave us a clear picture, about what exactly should we pick up for the MVP that we are working on.
05.
KEY INFORMATION & OPPORTUNITIES
Research Findings
After the alignment of User opinions, Needs, Insights and Design issues in the grid and validating through business. We broke the patterns collected into small features and conducted Open card sort exercise with a different set of users to see how many of them make sense. These were further concluded as key findings from the project:
■ The process of building a Policy in App firewall could be a complicated process and will result in drop-offs.
■ Information architecture studies reflect that the path to make a policy work is very cumbersome for the users. This has to be streamlined with a reduction in the number of steps and pages.
■ Reiterating and edition of a policy should be easy.
■ Looking at the competition a few things which we should focus on are:
■ One step addition of site with less technical jargons for all kinds of users.
■ Site status (Active / Non-Active).
■ Quick actions related to these sites and application at the time of the attack
■ A security level adjuster should also be given priority along with the visual references for better understanding and quick decision making.
■ To have an edge over the completion we should have a mechanism to fasten the process of policy addition even further by adding a bit of templatization.
■ For the details page, we should have a dashboard which can show micro-level details to a bird’s eye view with few clicks.
■ And last but not least, the offering should be visually delightful and simple to use with an easy learning curve.
User Archetypes
To understand users’ motivation and requirements based on the research done internally, 2 hypothetical archetypes were developed. This helped us identify different needs and expectation of different user set.
Major differences between these two archetypes are:
■ The first one talks about an Engineer who has exposure towards Citrix product ecosystem (which includes Xen Desktop, Xen Mobile, NetScaler etc. along with some other cloud products). These users have a basic understanding of UI and Interaction patterns associated with the Application. And hence the friction in using the product could be lesser.
■ The second one is about Engineer who is out of the Citrix product ecosystem and planning to use the Citrix cloud Web Access Firewall. These are a new set of users does not have any exposure towards Citrix Cloud offerings.
06.
BRINGING IT ALL TOGETHER
Final Outcome
While there were numerous sketches and visual changes (+110 Sketch Mockups and +15 Flinto Interactions to be precise) to come up with the final direction. The focus was to come up as many as directions as quickly as possible so that we can run them through various stakeholders and get them validated. After getting to a good level on Sketch, I would turn to Flinto to create walkthroughs for better understanding of interactions associated.
A. Important Directions
I. Addition of a Domain
Redesigned onboarding experience with emphasis given on Visual & Informational Hierarchy.
II. Missing interim state
The state of error handling is totally overlooked in the older interface when the user adds a domain.
III. No visual clue & increased cognitive load
More visual approach towards the domain card design. Addition of less and precise list of affordances for the reduction of cognitive load.
IV. Adding a new application to domain
Enhanced process of adding an application to a Domain with extra details about security profiles enabled for them.
V. Refining addition of Policy
Fixing content and the interactional hierarchy of Policy Addition. Giving more visual appeal and breathing space.
B. Design Complications
Keeping MVP & Time in Mind
A few disconnects between Engineering, Product and Design which resulted in tweaking of User Experiences in the Final Flow. These tweaks were done keeping time factor and MVP in mind.
C. Final Design
07.
LAST THOUGHTS
Roadblocks & Takeaways
Key Blockers
■ Card sort exercise exposure - The feedback which we got from the first card sort exercise was - “ We are not used to this please show us Visual Designs and do A/B testing instead.
■ Product Management trust issue - Convincing the product managers about the insights gathered was difficult. To overcome that, we started inviting the PMs in free research processes and insights gathering sessions.
■ Non-Availability of User Personas and time crunch - There was zero intent in focusing on persons and the pressure of time were mounted on the Design team.
■ RDX framework and iterations - Most of the design were rejected because of constraints of RDX. Had to turn to quick prototyping mode and involved Engineering at every stage to solve them.
■ Visualisation and Wireframes - Discussing wireframes were difficult with the stakeholders as they were not able to relate to it. Walkthroughs were the only solution.
Key Takeaways
■ Hanging out with developers can often solve problems which are complicated. But can become over-powering if involved during the initial incubation stage.
■ Hatred towards the legacy design system and related constraints can only eat up your time. Instead carefully modifying them can also give you satisfying results.
■ Involvement of Product Management in every stage is very critical. They can help us in buying time, enabling talks with customers and also iterating on last minute changes. If not involved there could be a change where the outcome may differ from the business want.
■ Interactive prototypes work pretty well to explain the concepts to the stakeholders.
