Fortinet
FortiClient
Lead Designer
6 Mins
Publicly shipped · 8.0.0
FortiClient is the security agent on 8M+ desktops every day, and it had not been rethought in twenty years. I led the redesign end to end: reframed the problem through research, rebuilt the information architecture around what users actually do, held the direction through stakeholder resistance, and validated every decision before release. It shipped publicly in FortiClient 8.0.0 and is credited with influencing a $100M enterprise deal.
FortiClient had grown for twenty years. Every release added capability; none stepped back to reconsider the whole. By 2024 the agent exposed its full configuration surface to everyone: 8M+ people a day navigating an interface built for the engineers who made it, not the people relying on it.
Leadership assumed incremental cleanup would be enough, with one blunt constraint: improve it, but do not make the product bigger. Before committing to a direction, I ran structured research to answer one question: do users struggle with how the agent looks, or with how it is organised?
Before
I started by auditing the existing agent, mapping its information architecture and sitemap front to back, so I knew exactly what I was redesigning from, not just toward.
Then research with end users and administrators surfaced a structural pattern: people were not failing at security tasks. They were failing to find and understand them. Users ignored features they could not interpret, and admins absorbed the overflow as support tickets.
Across 15+ user interviews, a deeper assumption cracked. FortiClient had been designed as if its users were technical. They are not. The core users are nontechnical employees who open the agent to log in and reach work resources, yet the interface spoke in remote access and telemetry. The product was not underpowered. It was overtechnicalized for the people it actually serves.
60%
of inbound tickets were interface confusion
Not technical failure. Users could not find or interpret what they needed. The interface itself generated the support load.
Wrong persona
the agent assumed technical users
15+ interviews showed the opposite: the core users are nontechnical employees who open the agent to log in and reach work resources.
Organisation
was the gap, not capability
Users were not asking for new features. They could not find, trust, or act on the ones that existed.
Muscle memory
was the risk stakeholders feared most
8M people use this agent daily. Any change had to preserve existing workflows or it could not ship.
The reframe
The agent was built on a persona that did not exist: users fluent in remote access and telemetry. Its real users are nontechnical employees trying to reach work resources. I redesigned the persona first, then the product around it.
Redesigning a 20-year-old flagship met resistance: not to the designs, but to the risk. Stakeholders worried that changing an interface 8M people use every day would break muscle memory and flood support queues.
I took the case to the room myself, presenting the sitemap audit, the research findings, and measured prototype behaviour directly to VP- and director-level stakeholders: the support burden the legacy interface was already generating, and the evidence the redesign reduced it. Buy-in followed the data. We aligned on two commitments:
01
Restructure the agent around users' daily jobs: status first, actions in context, configuration behind progressive disclosure.
02
Modernize without disruption: every existing workflow survives the transition, validated before release.
The constraint sounded like a limitation: do not make the product bigger. I turned it into the design position: if a problem could be solved by adding a surface, it had to be solved by reorganising an existing one instead.
That is why configuration moved behind progressive disclosure rather than earning a redesigned settings hub. It is why the security features consolidated into one home instead of gaining a navigation layer. And it is why the default tab became VPN, the surface most users actually open the agent for, rather than a new dashboard competing for first position.
The product got simpler to use without getting larger to learn. Holding that line, proposal after proposal, is the least visible and most consequential design work in this project.
After 25 positive tests with managers and leads, I tested with the VP of Development, the Senior Director of Development, and my manager. They did not love it. The objection was specific: every feature's icon still sat on the top layer, a holdover from the original plan I had preserved.
The honest read in the room was mine: I was not fully implementing what earlier feedback had already been telling me. I moved the icons off the top layer and into the menu inside the Features section. The product got simpler, the scalability story strengthened, and the buy-in unlocked.
The look itself took a second round. Even after users approved the direction, senior developers still did not like the surface, so I kept iterating: same architecture, refined visual layer, until the room came around. It stretched a one-year rebuild toward two. The reception since has made the case.
Icons on the top layer
Icons inside the Features menu
The honest read
The right call. I would have reached it a cycle earlier by bringing seniors into testing before the first complete prototype, not after.
The redesign shipped publicly in FortiClient 8.0.0. Each surface below answers a finding from the research, and every one of them reorganises rather than adds.
Information architecture · before / after
Clarity of status
Agent Health: one answer to am I protected
A single dashboard resolves the agent's whole state at a glance: green when a feature is healthy, yellow when something needs attention, per feature. From a Critical state, one click lands on the Vulnerability Events view already filtered to the problem. Status stopped being an investigation.
Confidence in action
Scan and patch inside the module
The Vulnerability Scan profile carries its own Scan and Patch actions, with View History alongside. The action lives where the information is. Users no longer needed to understand the system's structure to act on what it found.
Continuity of workflow
One Events page, filterable
Events from every feature consolidated into a single page, filterable by feature type and time window. Notifications became searchable by keyword and time. What used to be a hunt across surfaces became one place with a filter bar.
Progressive disclosure
Configuration steps back
Security features consolidated under a single Features home. Settings and About moved behind the overflow menu. VPN, the daily-use surface, became the default tab. The full power is still there; it just stopped shouting over the daily jobs.
Modernize without disruption
Every legacy workflow survived
Ransomware Protection separated cleanly from Malware Protection instead of hiding inside it. The window became drag-resizable. And every existing workflow was preserved through the transition, validated against the legacy flow before release, not after.
An 8M-user redesign cannot ship on instinct. More than 25 user interviews and prototype A/B tests ran in parallel across the redesign cycle, so stakeholders saw measured behaviour change before development began. After the build, structured usability tests ran against the working product across macOS, Windows, and Linux: a scripted task battery covering every core surface, completion recorded task by task before public release.
User interviews
25+ structured sessions with end users and admins surfaced the workflow friction analytics could not see.
Prototype A/B testing
Each principle was tested as an interactive prototype against the legacy flow, with task completion and time-on-task measured directly.
Post-build usability testing
Scripted sessions against the working product on macOS, Windows, and Linux. Every core surface exercised task by task, with completion and friction recorded per participant before release.
The redesign is publicly shipped: FortiClient 8.0.0 carries the new agent experience end to end, documented in Fortinet's official release notes. It was validated before release, not after: prototype A/B testing against the legacy flow measured an 80% end-user workflow improvement, and admin support tasks dropped as users began self-serving. Customer-facing engineers credit the redesign with influencing a $100M enterprise deal.
End user impact
80%
End-user workflow improvement
Validated through prototype A/B testing against the legacy flow.
75%
Product usability gain
Measured across all core workflows.
Business impact
60%
Drop in admin support tasks
Users now self-serve the core tasks that used to become tickets.
$100M
Enterprise deal influenced
Credited by customer-facing engineers following the public release.
The constraint I resisted most is the one that made the design. Do not make the product bigger forced every improvement through consolidation, and the shipped product is better for it: simpler to use without being larger to learn.
The second lesson was about resistance. Stakeholders were not wrong to fear changing the muscle memory of 8M people; they were wrong that the risk was unmanageable. Measured prototype behaviour, shown early, converted the sceptics faster than any argument, and pre-release validation is why the release held up in public.
If I did it again, I would put the information architecture map on the wall on day one. The debate about visual direction only settled once the organisation gap was visible.