Context
**This project was completed in 2024–2025, before AI tools became common in enterprise design. All work was done manually.
Cisco Meraki's MX device ships with five separate firewalls — inbound, outbound L3, outbound cellular, outbound VPN, and outbound L7. In practice, this created a sprawl problem: network administrators were duplicating the same rules across multiple tables, managing fragmented policies with no unified view, and struggling to find rules on a page that scaled poorly beyond a handful of entries.
I owned the end-to-end design process: facilitating the requirements workshop, driving the design strategy across two competing architectural directions, leading the usability research, and making the final recommendation on which direction to pursue and why.
Role
Role Lead Designer
Duration 3 months
Team 5 members
( 1 Designer, 1 Product Manager, 1 Technical Marketing Engg, 2 Design Reviewers)
Contribution
Interaction Design - 100%,
Visual Design - 20%,
Research - 50%
Design Process
1. Framing the problem with the PM team
Before sketching a single screen, I partnered with the PM to make sure we were solving the right problem. We ran a requirements workshop in Miro to map existing customer pain points, align on near-term release scope, and define the longer-horizon Northstar — the version of firewall management we were ultimately building toward.
This dual-track framing became the foundation for everything that followed: incremental improvements the team could ship quickly, and a bolder unified vision that would guide design decisions over subsequent releases.
Requirement Workshop
Product Requirement Document
2. Analyzing the current firewall page
The existing firewall page had compounding usability problems — multiple redundant tables serving the same function, poor findability at scale, and a layout that broke down completely for customers managing more than a few dozen rules.
I created a "magnetized" version of the current page as a baseline: updating all components to Cisco Meraki's Magnetic Design System while keeping the underlying architecture intact. This wasn't just a visual refresh — it gave the team a shared, up-to-date reference point and surfaced exactly which structural problems the component update couldn't fix on its own.
The key finding: magnetization improved visual consistency but exposed the underlying information architecture as the core problem. Better components on a broken structure still produced a broken page.
Current Firewall Page
Magnetized Firewall Page
3. Two directions, one question
With the diagnosis in hand, I designed two distinct firewall architectures to test with real customers:
Direction A — Separate layer firewall
L3 and L7 rules in separate tables, preserving the mental model most Meraki users already had. Added net-new features: pre/post rule support and site-to-site VPN rule visibility. Familiar structure with meaningful enhancements.
Direction B — Combined layer firewall
L3 and L7 rules unified into a single table with inbound and outbound as tab-separated views. A fundamentally different information architecture — significantly more optimized, but a bigger departure from the status quo.
My hypothesis going into testing: the combined view would win on clarity, but the split inbound/outbound treatment would be critical to getting there.
Separate Layer UI design
Combined Layer Firewall
Separate Layer UI design
Combined Layer UI design
5. Usability testing — letting the data decide
We tested both directions with 10 customers in April 2024 — 6 existing Meraki users and 4 who had never used the platform. Three findings shaped the final design:
Finding 1 —
Combined layer won, but inbound/outbound separation was non-negotiable
5 of 10 participants preferred the combined view. 3 preferred separate. 2 were split. Participants valued unified layers but were clear: inbound and outbound rules needed to remain visually distinct, not merged into one list.
Finding 2 —
Long pages create findability failure at scale
Participants raised consistent concerns about what the UI would look like with 100+ rules. Scrolling, scanning, and locating specific rules were all friction points — a strong signal that the final design needed progressive disclosure or filtering built in from the start.
Finding 3 —
Port and protocol belong together
Users expected to select the port immediately after choosing a protocol. The current form layout separated these fields, creating a subtle but recurring moment of confusion in every "create rule" task.
Usability test plan
Usability test report
6. Applying usability feedback on the designs
I synthesized the usability findings into a prioritized action list and worked through each with the team. The three structural changes that shaped the final design:
1. Adopted the combined layer architecture with tabs separating inbound and outbound — respecting what users expected while delivering the consolidation they needed
2. Redesigned the rule creation flow to place port and protocol fields adjacent, reducing form completion errors
3. Reduced visible information density through tighter table layout and a read/edit mode toggle — directly addressing the findability concern for high-volume rule sets
Usability test analysis
Final Design
The final design is created in Figma using Cisco’s Magnetic design system library.
It covers four core user flows:
1. Tab navigation between inbound and outbound rules
2. Creating a new inbound rule
3. Creating a new outbound rule
4. Navigating to the org-wide rules page
The design represents the Northstar direction: a unified firewall experience that eliminates the five-table sprawl, cuts page length by 75%, and scales cleanly for customers managing hundreds of rules. It has been reviewed with PM and is currently in dev handoff for phased release.
(Click on the individual pages to see them full screen)
What shipped:
The unified firewall design was in active dev handoff, with incremental features releasing in parallel with the Northstar build.
What shipped:
The usability test surfaced the findability concern late — after both directions were already fully designed. Earlier, lower-fidelity testing on information density alone would have let us pressure-test the "combined" architecture's scalability before committing to high-fidelity screens.
If I were running this project today, I'd lean on AI much earlier and more deliberately across four moments:
Rapid prototyping —
instead of building two fully realized directions before any user contact, I'd use AI-assisted prototyping to generate and stress-test structural concepts at low fidelity in hours, not days.
The goal isn't polish — it's getting something in front of users before the design has hardened.
Proto-persona validation —
before recruiting for usability testing, I'd use AI to synthesize available signals
(support tickets, NPS comments, product analytics) into proto-personas that represent the range of firewall management contexts — the small business IT admin, the enterprise network engineer, the MSP managing dozens of clients. Testing against a sharper persona set earlier would have surfaced the "100+ rules" scalability concern much sooner.
Research synthesis —
the usability test generated rich qualitative data across 10 sessions. I processed that manually, which meant prioritization was partly intuitive. AI-assisted synthesis would have let me pattern-match across sessions faster and with less risk of confirmation bias shaping which findings rose to the top.
Strategic release planning —
the dual-track delivery (incremental + Northstar) was defined early but evolved through informal PM alignment. I'd now use AI to model release sequencing more rigorously — mapping feature dependencies, identifying the minimum viable slice that proves the unified architecture's value to customers, and pressure-testing the release order against real-world adoption risk.