One design system behind every squad's work
Every design I delivered, for every squad, was built from the same system covering navigation, buttons, tabs, search and filters, the data grid, and metric cards.
Enterprise Customer Portal · Enterprise SaaS · Platform design
Aligning many squads around one customer experience
Enterprise customers used our web portal to run their driver safety programs: managing drivers and devices, reviewing reports, configuring their programs, and resolving support issues.
The portal had grown one team at a time. I was its first dedicated designer, and I owned UI/UX for all of the company's customer portals. My responsibility was making many squads' work feel like one product customers could rely on.
Product areasIoT, Consumer, Claims, Analytics, Support, Fleet
RegionsUS, India, and Budapest
ScopeEvery customer portal, one design direction
ProcessDesign before build, migrated or new
01 · The problem
Product areas, built independently
A customer could move between two areas of the portal and find buttons, font sizes, and colors that didn't match, because each squad styled things its own way. Everything ran on the same framework, but without a shared standard, small differences like that added up.
The portal was where customers ran their programs day to day, and most of its roadmap came straight from customer requests. The company's first portal was engineer-built: powerful, but dense and hard to navigate. A newer portal built for fleet customers was cleaner, and leadership chose it as the single customer portal going forward. A later merger added a third.
Squads were already moving their features into the new portal on their own, each with its own PM, roadmap, deadlines, and time zone. Without shared patterns, the same problems got solved in different ways. The product was starting to fragment.
02 · The approach
One foundation for every squad
With many squad roadmaps moving at once, I focused on the foundation. Every squad got the same building blocks, so their features fit together and engineers could reuse what was already built. Squads kept moving, and my time went to the new problems that needed design.
Cross-squad reviews with PMs
A standing forum that surfaced overlapping needs before teams committed to separate solutions.
Built to be reused
I encouraged engineers to build components straight from the system, and pushed for a shared Storybook library, which started as a hackathon project I encouraged one team to take on.
03 · Workflows
Rethinking each feature as it moved
Every capability moving into the shared portal was rethought with its PM before it was rebuilt. Moving a feature was a chance to make it better. I gathered customer insight through customer requests, support tickets, and conversations with customer success and the internal support team. PMs and customer success managers then put my screens and prototypes in front of customers for feedback and buy-in.
04 · Implementation
Carrying design into working code
I walked PMs and engineers through each design screen by screen, ending with a clickable prototype. My front-end background meant I could answer HTML and CSS questions on the spot.
Then AI-assisted tools changed what a prototype could be. I started building prototypes in my local development environment against staging data, with realistic charts and tables, and I could test both everyday and edge cases.
portal-design-to-code.png · 2320 × 1306
Engineers could take my branch with the UI already in place, review it, and build on top of it. Handoffs got faster, and engineers kept ownership of production integration: data, security, performance, and quality.
05 · Impact
One direction across a distributed organization
One design direction across three portals
Customers moving between product areas met the same navigation, data grid, filters, and buttons.
One system, reused by engineers
Every squad's features were designed from the same system, and engineers began building them as reusable components, backed by a shared Storybook library that grew out of a hackathon.
Design as a standard step
Squads that once built features on their own brought them through design first. Over time, everything added to the portal, migrated or new, went through design before it was built.
Workflows improved as they moved
Support agents could diagnose a missing trip while still on the call, and customer managers could target and preview driver messages before sending.
Closing the loop with customers
Positive feedback came back through customer success and support, most often after we shipped a feature customers had asked for, or improved one they had flagged.
What I took away
Shared foundations work best when their value is easy to see. Setting a few simple measures with PMs from the start, like task completion, component reuse, and support volume, makes that value clear to everyone. The same goes for a shared component library: the earlier it's in place, the faster every squad can move.
Where it was heading
In my last months, I joined weekly planning with PMs and leadership to help shape the portal’s next chapter: self-service features and a move from AI-enabled to AI-native.
Product visuals are recreations with fictional data. Company and customer details have been removed.
Continue the conversation
Let's discuss the details.
I'd be glad to walk through the design decisions, the cross-squad process, and the implementation work.