Company
Ericsson
Timeline
2024–2025
Role
Lead designer
Team
Product owner, engineering, UX team
Platform
Internal web application
Status
Shipped
Case study
Shipped
By guiding newer requesters, giving each role its own home, and showing where every request is.
Every connection between two network zones at Ericsson starts as a request in Firewall Manager. A requester asks for access, and the zone owners on each side approve or reject it. When a request is vague it bounces, and the questions land on support: about 500 ticketsReported by the business before the redesign: support tickets and direct questions about how to write a request. asked how to write one.
I led the design across three roles (requesters, approvers and firewall technicians) and three releases, from the first heuristic review to the last round of focus groups. To know more, please reach outsaoumya_mandhar@berkeley.eduClick to write an email.
~500
support tickets asking how to write a request
44%
of tasks finished without a blocker
↓ 50%
support tickets after the redesign
01 · Overview
Problem
Vague requests bounced between requesters and approvers. Approvals slowed down, and support answered the same questions about how to write a request.
What I did
A heuristic review and a study with 16 users, then a redesign for requesters, approvers and firewall technicians, improved over three releases.
Status
Shipped in phases, each observed for months. Support tickets fell by about half after the redesign, as reported by the Firewall Manager team.
Before a zone owner approves a request, they need to know
1
Where the traffic comes from
2
Where it is going
3
Who owns and uses the access
4
Which services and ports it opens
5
What it is for, and who asked for it
02 · The hypothesis
A vague request fails at the approver
How a request gets approved
A requester raises a request between two network zonesA zone is a segment of Ericsson’s network with its own owners. Traffic from one zone to another needs a firewall rule.. The request creates a zone pair policyOne firewall rule for traffic between one source zone and one destination zone. A request creates one for each pair, and each zone’s administrators approve their part. for each pair of zones, and the administrators on each side approve their part at the same time. A vague request doesn’t fail where it is written. It fails at the approver, who can’t tell what it is for and has to chase the requester, or approves on trust, which in a firewall is a security risk.
If a request carries what the approver needs, guides newer requesters without slowing experts, and shows where it is, approvals stop bouncing and support demand drops.
The brief named one role: “Improve the UI for the requester, specifically ad-hoc requesters. The approvers and admins know what to do.” But a vague request costs the approver, and the questions about it reach support. Fixing the form alone would move the problem downstream, not remove it.
1
Who pays for an unclear request?
2
How do we guide newer requesters without slowing experts?
3
What does an approver need to read first?
4
How does each role see what needs them, and where a request is?
03 · How we researched
Five rounds of research, two releases
The work ran in phases. Each release was observed for months before the next round of changes, so every decision below has a source.
Usability study
Seven research goals, three measures.
Before the sessions we wrote down what we needed to learn, such as how to cut the steps to find and place a request, whether the information hierarchy matched what people expected, and where they had to recall information instead of recognising it. Each session was one to one, remote and screen-shared. Participants thought aloud through tasks for their own role, then rated how complex each task felt. We scored the sessions on the three usability measures in ISO 9241-11 (effectiveness, efficiency and satisfaction).
04 · What we found
The cost wasn’t where the brief said
The brief asked for a better form for ad-hoc requesters. The research found the cost of an unclear request landing on approvers, firewall technicians and support, and a gap set more by skill than by role.
Assumed
“This is a requester UI problem.”
Found: approvers paid for unclear requests. They lost time on requests that didn’t follow naming conventions and had no history in the new tool.
Assumed
“The other roles know the flow.”
Found: experienced users ran on workarounds. They copied old requests as templates and re-added the same people every time.
Assumed
“Fix it locally, sprint by sprint.”
Found: each hot fix answered whoever asked loudest, and the interface filled up with features nobody had placed. The confusion ran across the whole workflow.
Heuristic review
Scrolling to submit was the only severity-4 issue.
Four of us reviewed the requester, approver, technician and home flows against ten usability heuristics and scored each issue from 1 to 4. For the worst one we proposed a step-by-step form. Information without hierarchy and actions hidden off-screen came next.
Usability study
Most tasks finished; few without a struggle.
86% of tasks were completed, but only 44% without a blocker. Raising a request took 2 min 45 s on average and felt the most complex of the three jobs, rated 5 on a scale where 7 is the most complex. Approving was rated 4 and implementing 3.
Across roles
An unclear request costs more at every hand-off.
We followed requests from the requester to the approver to the firewall technician who implements them. Each role inherited the gaps of the one before, so a missing detail at the start became an investigation for the approver and a risk for the technician.
Skill, not role
Experts and novices needed different things.
Daily users and people who raise a request a few times a year asked different things of the same screen. That split is why the guided request in 05 can be switched off.
Requester journey
Most of a request happens outside the tool.
We mapped the requester’s journey from the email that starts a request to the screenshots that close it. Email, Jira and Teams carried what the tool didn’t, such as the business reason, the status and the hand-over.
UX debt
The biggest debts were in how the tool was built.
We sorted what we heard into an affinity map, and the UX team scored each theme from 1 to 7 for UX debt. The three highest were about how features had been added and maintained.
In their words
What people told us, and what it led to.
Quotes from the sessions and focus groups, lightly edited and attributed by role.
“I miss the tooltip feature in the old system, where hovering over a zone ID revealed its name. Now I have to click on the ID to see the zone’s details.”
“I can solve these issues easily, but I think we are talking about convenience.”
“I rated 5 because there is some missing information I don’t know about.”
“If I have placed the request, and I am the approver, it should have provision of getting auto approved.”
“The process is not complex for me, and the reason is because I’m working daily on it.”
“It’s like a ticket system. If someone asked me, do we have a firewall opening from this source to this destination, I can’t find that.”
“With the new system I could fetch all of the policies, 37,000 policies in two hours for the big firewalls. It’s a huge difference.”
05 · Guided request
Four steps, one toggle
Guide newer requesters without slowing experts.
I designed a four-step wizard (Source, Destination, Access controlsWho owns, administers, uses and can view the policy the request creates., Network servicesThe ports and protocols the connection needs, such as TCP 443.) with a toggle to the full form. Request details stay visible at every step, and owners can be saved as favourites so repeat requesters stop re-adding the same people.
The decision
Offer the guide; never force it.
The heuristic review pointed to a step-by-step form; experts in the study wanted the opposite. Step by step and Full form sit one click apart, and the tool remembers each person’s choice. Six months in, 65% of requesters surveyed preferred the full form and 35% the wizard: the toggle earned its place.
06 · Request panel
What approvers read first
Ask the requester for what the approver needs, on the screen where the request is written.
The richer panel shipped in response. It asks for the purpose, whether the request is internal or customer, the requester’s team, related Jira or ServiceNow tickets, and a detailed reason. Requesters fill in more fields so approvers investigate less.
The decision
Move the questions upstream.
Every detail an approver used to chase by email is asked once, when the request is written. The panel stays visible at every step, so requesters see what they are committing to.
07 · Two homes
A home for each role
Same tool, different first question.
I merged Home and Dashboard into one home per role. Requesters see their own requests and drafts with status. Approvers see pending approvals and recertificationsA regular check where approvers confirm that an existing policy is still needed, or remove it., with filters and a lock to claim a request.
The decision
Build each home around its first question.
Requesters ask where their request is; approvers ask what is waiting on them. The approvals table leads with source, destination and service, the zone tooltip from the old tool came back, and a lock claims a request against the approver’s signumAn Ericsson employee’s personal user ID. so two approvers don’t act on it. People who do both get a My requests tab inside the approver home.
08 · Progress
Progress in the row
Show where a request is, in the table people already scan.
Expanding a row in the approvals table shows each stage: zone pair policyOne firewall rule for traffic between one source zone and one destination zone. A request creates one for each pair, and each zone’s administrators approve their part. created, source zone approved, destination zone approved, firewall policy implemented. Implementation happens outside the tool and is recorded here. Each stage has a date, and the open step shows when it is expected.
The decision
Put progress where the request already lives.
The timeline opens inside the row people already scan, not on a separate page. 90% of requesters surveyed called it useful, mostly for finding who was holding a request; approvers asked for agreed service levels on each step.
09 · After release
Listening after release
Six months after release 1 we ran a survey. After the next round of improvements we ran focus groups. Both shaped release 2 and a set of recommendations.
Survey
Most found it easy; requesters split on the form.
27 people answered 24 questions, most of them experienced requesters and approvers, so the numbers are self-reported and lean towards experts. Because requesters split on the form, both modes stayed.
Focus groups
Some needs were in the interface, some beyond it.
We ran themed sessions with requesters and approvers on the improved release and grouped what we heard into nine challenge areas. Two changes shipped in release 2. The rest became recommendations, some for the interface and some for process and data.
About these screens. This is work I did as the lead designer on Firewall Manager at Ericsson. The screens, data and videos are rebuilt for this portfolio to share the essence of that work, with confidential details changed or left out. They are not an exact record of the product as it exists at Ericsson.