The platform had been growing for ten years. The security technology was solid — it protected homes, small businesses, and ISPs — but a decade of adding features without revisiting the underlying structure had left the interface in a difficult state. Simple tasks required navigating menus that had been organized around technical logic rather than user workflow. User roles overlapped in ways that confused both administrators and end users. The mobile experience was effectively unusable. In 2025, the business needed to add significant new capabilities based on client demand and market pressure — which meant the existing complexity problem couldn't be deferred any longer. Adding to a broken foundation would have made everything worse.
A decade on the same product is a specific kind of advantage. I knew which parts of the interface users had learned to work around, which role boundaries were causing real confusion, and where the navigation had drifted furthest from how people actually worked. That context shaped every prioritization decision before any design work started. I was also working with a global team — designers, researchers, business analysts, and sales in different locations and time zones — which meant every design decision needed to be documented clearly enough to survive a twelve-hour gap between the person who made the call and the person who would build it. That constraint improved the quality of the design system considerably.
We rebuilt the entire user structure around four distinct roles — home users, business admins, support teams, and a sales portal — each with its own tailored dashboard. The previous version had treated every user type the same, which meant everyone saw everything and nobody's experience was optimized. The risk was building four experiences instead of one. The outcome was that each user type now reaches their most common action in one step rather than three.
We went mobile-first despite the platform's history as a desktop product. Most users check security status on their phones. The old platform required a desktop to do anything meaningful. Redesigning for mobile first forced better hierarchy decisions — if something couldn't be made to work clearly on a small screen, that was a signal the information architecture was wrong, not that mobile was the wrong target.
We chose to evolve rather than replace. Long-term users had built real workflows around the existing system — imperfect workflows, but functional ones. A complete replacement would have disrupted users who were depending on the platform daily for security management. Every change was weighed against that disruption cost. This made the design process slower and more constrained, but the alternative — breaking trust with existing users to ship something cleaner — was the wrong trade.
I led the frontend implementation alongside the design direction rather than separating the two. For a platform this complex, with a global team and a component library serving four distinct user roles, the design system and the code had to be developed in close coordination. Components designed without build constraints create implementation problems. Components built without design oversight create consistency problems. Keeping both under the same leadership avoided both.
role-based interfaces replacing a single one-size-fits-none experience
The design and UX work is complete. Four role-based interfaces have replaced the single undifferentiated experience that was serving nobody particularly well. The design system and component library are built and documented for developer handoff. The frontend team is now building the admin portal against those specifications. The mobile-first approach is implemented across all user types. For a platform with a decade of accumulated complexity, the significant outcome at this stage is structural — the foundation the new features are being built on is sound in a way the previous one wasn't. Results from live usage will follow the development phase.
Ten years of context is valuable, but it can also make you slower to question decisions that should have been revisited earlier. I knew the platform's problems intimately, which was an advantage. It also meant I'd been living with some of those problems long enough that they started to feel normal. I'd build in more structured challenge points earlier — moments where someone without that institutional context reviews the direction specifically to surface assumptions the team has stopped questioning.