The Client
This project was for Rackspace, a company that provided web hosting services. My stakeholders were the firewall manager team. The end user was a system administrator responsible for infrastructure changes.
The Problem
The firewall team wanted customers to be able to manage more features on their firewall to reduce the number of support tickets coming in. Since this required replacing back end systems, they also wished to bring the interface in–line with our new design system.
I saw this as an opportunity to do more than just update the components and started on a journey to re–imagine the user experience.
My Role
I was the sole UX designer. I worked with colleagues to plan generative and evaluative research. I constructed the mockups, wireframes, and high-fidelity prototypes.
The firewall manager team consisted of a product owner, a product manager, technical experts, plus front end and back end developers.
Timeframe
2014–2016 while also working on other projects
Understanding The Problem
What is a firewall?
At the start of the project, I didn't know how firewalls worked. I had only a basic understanding that they helped filter out unwanted web traffic. I spoke with network security engineers at Rackspace to learn how firewalls work, and how the new functionality I was adding fit in with what was already there.
I created a visual model (Photo 1) that allowed me to communicate effectively with engineers and quickly brief designers before asking for feedback. When speaking with users, this research allowed me to compare users' mental models to reality.
How do other companies solve this problem?
At the same time, I investigated how other companies handled firewall management. I explored how they handled the features I was adding and what terminology they used. Surprisingly, I found that a standard terminology and design patterns were lacking. (Photo 2)
Understanding the User
After getting a handle on how firewalls worked, it was time to understand the people who used the firewall manager. I planned 3 separate rounds of research using a variety of techniques including 1-on-1 interviews and usability testing. To avoid confirmation bias, I did not moderate this research. Additionally, I worked with our developers to mine the support chat logs to find common issues. Here are some of the most important questions we answered:
Who is the target user?
The initial round of user interviews uncovered a surprise. The project manager believed the primary user of the tool was network security specialists with complex infrastructure setups. Instead, we found general system administrators with very basic setups.
When do they use it and why?
We found that the majority of our users were system administrators who used our tool to add new users to the company's infrastructure.
For example, if a developer was hired for a certain project, the system administrator would need to give them access to all the web servers that pertained to that particular project but not others.
What is their mental model?
One of the new features would expose customers with complex infrastructure to the way that their networks were set up.
I was curious to learn if these customers knew how their networks were actually configured, or would their understanding match the setup they were currently presented in the control panel?
When asked to describe their configurations, users' explanations matched what they saw in the control panel, not reality. I knew would need to be careful to explain these new concepts.
Designing for a Less Technical User
Now that I understood our users, it was time to get to work re-imagining the interface for a less technical user that made them feel confident and supported. While this project focused on every aspect of the firewall management workflow, in this portfolio I will focus on improvements to the rule creation process because adding and deleting rules from the rule list were the most important and frequent tasks our users did.
“If our customers don’t know what they’re doing, they shouldn’t be using this tool in the first place.”
I often heard this in response to some of the improvements I had planned to better accommodate less technical users.
To overcome this, I tied these improvements to our brand values and business model and it helped my teammates understand why it was important to design for different ability levels. At the time, Rackspace's differentiator wasn't cost or technology, it was providing the best expertise and guidance to our customers. My teammates were much more receptive to things put in this context.
Problems with the old interface
The previous rule creation workflow was "sparse" and "intimidating" and offered no guidance. I replaced the old rule creation popup with a step-by step process so that users could focus on each step of the process and make sure they had the right information at the right time.
3. I found in usability testing that users often didn't know what protocol to choose. There was no guidance.
4. You could search for the IP of a Rackspace device, but because it was displayed after you clicked on the field, users would often go look up the IP address in a new window in usability testing. Also user–generated device nicknames were not prominent.
5. Users did not understand what the numbers in this drop–down meant. (It is a way of writing down ranges of IP addresses in a computer shorthand called CIDR notation.)
Improvements to the new interface
The interface was broken down into a step–by step workflow, which allowed users to focus on the input at hand but also see a summary of their work at the end so they could double check what they had entered.
I also changed the order users entered the information to match the order they used when describing rules to us.
6. Guidance was added on when to choose each protocol.
7. I added a CIDR notation converter to make it easier for users to handle this challenging binary notation.
8. Search shows up automatically and displays users' device nicknames which they said was more meaningful than system generated names
Safeguarding against errors
Rackspace engineers and users both wanted safeguards in place to prevent dangerous firewall rules. (Photo 9)
Together we ensured it was not possible for users to add rules that would make their firewalls completely ineffective. Sometimes that meant giving a stern warning and sometimes preventing them from creating a certain rule.
I made sure that the warning icons I used had different shapes as well as colors in order to accommodate colorblind users.
Creating new design patterns
As I built the new app in the new design system, I encountered new interaction patterns.
I worked with my fellow UX designers to make sure that the interaction patterns I created filled gaps in our design system and could be reused in other application contexts.
I created interactive prototypes and tested the experience with users to make sure that the new design patterns were user–friendly.
9. Annotated wireframes for handoff to developers
11. A clickable prototype in Axure for Usability Testing
12. An early wireframe in Balsamiq
Key Takeaways
While I left Rackspace before the Firewall Manager was implemented, I am still extremely proud of the improvements I was able to make to the interface. I enjoyed designing for a complicated system, understanding technical users' behavior, and designing for them. I appreciated becoming a subject matter expert and look forward to applying this love of learning in other categories.
This was my first project where I had ownership over the whole process from beginning to end and I learned a lot. I discovered how to identify and include key business partners early in the process. I experienced designing, testing, and building a new user experience from scratch.
Because one of the business goals was to reduce the number of support tickets for firewall rule changes, I recommended the team keep an eye on firewall questions for support. By tracking how things changed in both the type and volume of questions after the new firewall manager was implemented, the team could validate that the experience improvements had the intended effect.