Firewall Policies & Rules
TL;DR
View the fully-functional prototype I built using Claude Code and the Figma MCP server.
While employed at Infoblox, a SaaS IT administration company, I designed from end-to-end a next-generation firewall service for edge routers within a larger SASE product, enabling IT admins to control network traffic via policies that block inappropriate content (e.g., streaming services) or malicious servers. I collaborated with product management and internal SMEs, like IT staff and a technical advisory board, quickly learning networking basics despite limited research time due to ongoing engineering. Working within Infoblox's existing UI patterns, I defined UX requirements and validated designs through stakeholder reviews and unmoderated usablity tests on UserTesting.com.
Skip to the mockups
Introduction
The first product I worked on at Infoblox was designing a SASE (Secure Access Service Edge) product that runs on edge routers, the routers that operate at the edge of a corporate network and connect directly to an internet service provider. One of the many features of this product was a next generation firewall service. With this service installed on an Infoblox appliance, the customer could monitor and control all network traffic between their local network and the internet. The controlling of the traffic was done through firewall policies, which allow administrators to block specific types of traffic based on a set of rules. Some common use cases for firewall policies are:
- Blocking inappropriate content — Example: Per company policy employees are not allowed to watch Netflix, Hulu or other streaming services on the company network.
- Blocking malicious servers — Example: Blocking internet traffic both to and from IP addresses that are known to be associated with malware or spyware.
The next generation firewall service was part of a larger product (a SASE product to be specific) that I worked on for a year and a half, but unfortunately was canceled when new management came into the company and decided it was in a market Infoblox did not want to compete in.
My Role
I started working as the designer for the product this next generation firewall feature was a part of the first week I was employed at Infoblox. I had only a basic understanding of networking, but I learned fast. This new product was being developed as a startup within Infoblox — and, because I have a lot of experience working at startups, I was able to hit the ground running.
The product manager had never worked with a designer before. He and I worked together to define the UX requirements for the firewall feature and other features of the product, such as the configuration of port forwarding, routing protocols and site-to-site VPN connections.
Research
Since software engineering work was already underway, there was little time to conduct any formal research. I relied heavily on internal company knowledge. I met with several groups within Infoblox to gather information and review design concepts.
- Product Management — The product manager for this new product had worked as a network engineer for many years and had extensive experience configuring firewalls.
- Infoblox's own IT staff — I met repeatedly with members of Infoblox's IT staff who configured firewalls as part of their job.
- Technical Advisory Board — The product manager and I reviewed the overall approach of using policies and rules with a technical advisory board that comprised IT admins from several of Infoblox's customers.
- Competitive Reviews — I reviewed competing products to get an understanding of what the existing UX conventions were for this type of administration software.
Problem Statements
- In competing products, typically firewall rules require the user know a lot of information up front, i.e. source and/or destination IP, port and protocol.
- IT administrators at small to medium size companies may not have a lot of experience or training setting up firewall rules.
- Applying rules to many edge routers can be tedious and repetitive.
Project Goals
- Firewall rules should be grouped into Firewall Policies, for easier management.
- A Firewall Policy should be deployable to many Infoblox Appliances (create once, deploy everywhere).
- The UX should be easy to use for IT administrators without much experience creating firewall rules.
- Infoblox should aid the user by providing lists of common destinations to allow or deny, but still provide more expert settings.
Wireframes
In order to maintain the confidentiality of the work, the designs shown here are not the actual mockups created for this project. What's presented here are wireframes that demonstrate a similar approach to solving the same problems.
Design Process
Infoblox has a UI pattern and component system that all their products are based on and I was required to stay within those existing patterns and components. On the one hand, this meant I could go straight to designing high fidelity mockups, using the UX team's Adobe XD UI kit. On the other hand, it meant that updating or creating new components was out of scope. One exception was a stepped process pattern that I was able to update to allow users to create firewall rules within a firewall policy (creating a nested object inside another object).
I sought feedback on my design work in several ways. I reviewed my designs with internal stakeholders including many of the same people I talked to when conducting my research, product managers, engineering managers and internal IT staff. I also conducted an unmoderated user test on UserTesting.com of the new stepped process UX pattern, which the design successfully passed.