Overview
Sector: internet security
Challenge: Our company (ExpressVPN) was merging with two other VPN companies and we were dealing with multiple branding guidelines and codebases. The goal was to streamline communication between designers and engineers while reducing design and development time by creating a cohesive design system and UI library.
My role as frontend team lead: internal UX research, stakeholder management, team creation and recruitment, presentation, consulting
Identifying the problem
ExpressVPN had been bought out by Kape Technologies a few months earlier and we merged with two other VPN companies. Initially, we continued to operate in our own lanes.
One year into the merger, C-suite decided that our overarching goal for 2023 was consolidation in the name of efficiency. From a frontend perspective, they were hoping to merge frontend engineers across different companies into one chapter.
During the time I took over as frontend lead for the ExpressVPN frontend chapter, the company had decided to shift from functionality-based teaming and project management to project-based teaming and project management.
There were noticeable growing pains with this. The most obvious was that there were not enough engineers to cover the amount of project teams required to cover all the required tasks. Over time, I was able to grow the frontend chapter from 8 to 16 engineers, while also able to start working with the other two VPN companies’ frontend engineers to help move people around teams to cover needs.
There was one noticeable opportunity: a unified design system across all 3 VPN companies that came with a robust UI library system.
Internal UX research
I had a few key questions I wanted to explore with the brand, design, localization, content, engineering, and QA team leads:
What challenges and difficulties were the teams currently facing?
Would a UI library that was fully aligned with the design system be beneficial?
Could we build a UI library that worked seamlessly across both web and native platforms (iOS, Android, Mac, Windows)? And more importantly, would it save time, or would it just become another resource-heavy project?
As I spoke with the different teams, it became clear that while some had specific pain points, others were content with the current setup.
For example, the content team was quite satisfied with their existing processes and didn’t feel a need for change. On the other hand, the localization team expressed a need for better ways to test localized text, and they saw value in having an interactive UI library database. Tools like Zeroheight, Storybook, or Frontify were options we explored that could help them address this gap.
The most surprising insight came from the engineering side. While the idea of a unified component library for all platforms was initially appealing to the Android, Mac, and Windows leads, we quickly realized that the actual cost of migrating to such a system outweighed the potential time-saving benefits. It simply wasn’t worth the effort for them.
In the end, it became clear that only the web engineering teams would truly benefit from a centralized UI library. The others would see more challenges than advantages in making the switch.
Building the team
I started by walking through my UX research with the marketing tech lead, focusing on the time-saving benefits of developing a UI library that would work in tandem with the design system. While we explored the idea of using tools like Zeroheight or Frontify, the costs associated with a full library system were significant. So, we decided to stick with Storybook for testing—it was a practical choice that balanced functionality with budget.
Next, I needed to assemble the right team. I knew we’d need a team lead, a project manager, a designer (in more of a consultant role), and ideally another engineer. For the team lead, I immediately knew who I wanted—one of our front-end engineers who was passionate about CSS frameworks like Tailwind and had been advocating for a more cohesive UX experience for the front-end. His vision aligned perfectly with this project.
For additional support, I had the ideal engineer in mind—a senior team member who was incredibly detail-oriented. I’d seen her in action when we worked on the central stylesheet together, and she was a pro at documenting processes in Confluence. She was also eager to branch out into project management, so this was the perfect opportunity for her to explore that with mentorship from our front-end team’s project manager.
The designer was a given—we only had one web designer, and while she was already deeply involved with the design system, she would sit in on meetings to provide input when necessary. Her role here was more consultative, but it was important that the design and engineering teams worked closely to make informed decisions together.
At the time, I was also lucky to find another engineer within the company who had the bandwidth to support the team, rounding out the group with the expertise we needed to get things rolling.
Launching the team
Upon launching the team, I faced a few challenges:
Problem: confusion around the team’s purpose, roadmap, and ultimate goal. This was brought up to me by a couple of my reports in our 1:1’s.
Solution: I held a meeting with the entire frontend team to explain the big picture roadmap of the team. I understood the transition was tricky because the team had to take on “leftover” frontend tickets that did not belong to any other project team in the company. I broke down the team’s work into 3 distinct phases:
(1) Work on ongoing miscellaneous frontend work while beginning to define the company’s user flow of working with the design system team; map out all existing design components and content blocks in an atomic design-esque structure with clear design tokens; unify the language between the design chapter and frontend chapter of the company.
(2) Begin the official transition from our existing code (Hugo templates, SCSS, and vanilla JS) to React components to build a themable, accessible, and performant UI library.
(3) Continue ongoing maintenance of the design system & UI library while evaluating new requests or edit requests from other project teams.
Ongoing Consulting
In my role as frontend team lead, I took a step back to allow the staff developer to gain valuable experience leading the team and managing the project. My goal was to help him grow his leadership skills, so I provided support and guidance in the background (we had weekly 1:1’s setup already) while he handled the day-to-day management of the UI library initiative. I attended key meetings to offer input when needed, ensuring he felt supported while still allowing him the space to take ownership of the project.
Beyond team development, I continued to serve as a consultant for cross-functional teams across the company. I advised on how to implement the design system and UI library within their projects, collaborating closely with engineering, design, and product teams.
Whether through workshops, one-on-one sessions, or ad-hoc consultations, I remained available to help troubleshoot, clarify processes, and ensure that the transition to our new system went smoothly. This approach not only helped the senior developer grow but also ensured the entire team benefited from ongoing guidance and expertise.