Project Description

Parallels Browser Isolation runs every web session remotely in the cloud, isolated, contained, and deleted when the session ends. The threat never touches the local machine. The technical reality is straightforward, but the UX reality matters more: the user should not need to know any of that. They should open a browser, get their work done, and go home.

I was responsible for the end-to-end UX and UI for both PBI and Parallels DaaS: information architecture, interaction design, design system, and implementation support. The team was deliberately lean, one designer per product, with full accountability and minimal overhead. That is the kind of structure I work best in.

The Decision: Two Audiences, One Budget

The competitive analysis made the problem clear. Every RBI tool was making the same tradeoff: they loaded complexity onto both audiences. IT admins faced sprawling configuration panels. End users felt the latency, the extra steps, the friction of a product that was doing a lot of things they couldn’t see. Nobody had solved the right problem for either group.

On a five-month MVP timeline, I had to choose where to focus design investment. The product had two fundamentally different audiences with different definitions of success:

IT admins needed confidence. They needed to know the environment was correctly configured, policies were enforced, and they had visibility into what was happening. For them, success meant control without complexity: the ability to manage a zero-trust environment without needing a security engineering background.

End users needed the product to be invisible. Security is not their job. If they are thinking about the security product, the security product has already failed. For them, success was launching ‘Work’ and being ready to go.

The judgment call was to invest the MVP design capital in the admin experience, not to build every feature but to make it opinionated. Smart defaults, progressive disclosure, and policy templates that let an admin configure enterprise-grade security in minutes. Get the admin experience right and the end-user experience follows naturally, because every admin decision becomes a decision made with the end user’s cognitive load in mind.

We built exactly that, and it shipped in five months from kickoff to production.

Technologies Used

Technology choices followed the UX decisions, not the other way around. PrimeVue and PrimeOne Figma gave us a scalable design system foundation that we could extend without rebuilding from scratch, which was the only realistic way to stay ahead of the timeline while building two products in parallel.

• Design & Prototyping: Figma + Make, Sketch, Adobe XD, Adobe CC

• Design System: PBI: PrimeVue + PrimeOne Figma, BrowserFence: Preline + Preline for Figma

• AI Enhanced Design & Prototyping: Figma + Make

• Development & Project Management: Storybook (for component alignment), Jira (for tracking user stories, tasks, and bugs), and Confluence (for documentation).

What Actually Happened

• Making the admin UI opinionated, not feature-complete. The instinct on enterprise security products is to expose every control. Give admins everything. Let them tune anything. The result is products that only security engineers can operate. I pushed back on that instinct throughout the project. Every policy configuration, every settings panel, every onboarding step was designed around a question: does an IT generalist need to make this decision manually, or can we set a sensible default and surface the override only when it's actually needed? We cut significant UI complexity from the MVP by answering that question honestly.

• Designing in live sessions, and why it worked. With no time for traditional feedback cycles, I ran design reviews live with PM, engineering, and QA in the same session. Figma became the meeting. That approach compressed the loop between 'here's the problem' and 'here's the design response' from days to hours. It also meant decisions were made with the people who had to build them in the room, which removed a whole category of rework.

• Building the design system as we went. We committed to PrimeVue and PrimeOne from the start, which was a bet that paid off. Rather than designing bespoke components for every new screen, we extended the system, which kept visual consistency across PBI and DaaS without the overhead of maintaining two separate component sets. It also meant design-to-dev handoff was precise, because the tokens and component names matched between Figma and the codebase.

• 40% reduction in design rework from the system-first approach. Decisions made once applied everywhere.

The Coda: What It Could Have Been

The PBI project shipped in five months. What the timeline does not show is what it cost to get there, not in hours but in vision.

Enterprise software projects accumulate constraints. Parallels had developers who had been with the company for 15+ years, with deep opinions about architecture and what was technically feasible. The product had a PM who pushed back hard on new directions. And PrimeVue, which was supposed to give us production-ready components we could build on top of, turned out to require rebuilding almost from scratch, component by component, dev sprint by dev sprint. What should have been a design system accelerator became a manual process.

I made the MVP work within those constraints, but I knew what I would have built without them.

After PBI shipped, I went back to the admin interface (the part of the product where the real design work lived) and re-visioned it from scratch. There was no committee, no inherited decisions, and no organizational constraints: just the problem, my knowledge of the domain, and Figma Make.

BrowserFence is not an end-user app or a full product redesign. It is a re-envisioning of what the PBI admin experience could be when the only constraint is the quality of the thinking: a single Security Dashboard where policy management, credential visibility, and environment health all live in one place, designed for the IT generalist who should not need a security engineering background to run a zero-trust environment.

I built it in 13 days: 400+ prompts, a markdown-based requirements system to prevent regressions, a workflow that went from two structured artboards to 30+ interactive screens. The 3.2x iteration speed was not the primary outcome. The real question was what becomes possible when design is no longer slowed down by committee friction, and that is what I wanted to demonstrate.

Detailed Case Study      BrowserFence Live Prototype