My design director gave me a challenge: get our design team collaborating and cross-pollinating.
On paper, we’re a team of around 20 designers. In practice, we’re 20 people working alone, each on our own product, fully remote, scattered across North America. We rarely see each other’s work and because of that, we’re mostly blind to the patterns we share: the overlapping feature sets, the near-identical workflows, the same problems being solved over and over in parallel.
From a design systems lens, that disconnect is expensive. More collaboration means more consistency. It means not designing the same feature twice. If one of us has already cracked the best pattern for something, everyone should know about it and we should have actually discussed it, as a team, in depth.
Until now, none of that was happening. That’s where I came in as I’ve been at EverCommerce for over three and a half years, long enough to see exactly where the gaps and the disconnects are. This felt like the perfect chance to start filling them.
Why I didn’t reach for a rigid design system
The obvious move here is to build a strict, shared component library and push everyone onto it. I didn’t do that on purpose.
Our products each have their own separate user base. It’s rare for a single customer to be subscribed to more than one product in our portfolio. So visual and interaction consistency across products would mostly go unnoticed by the people actually using them. The external payoff just isn’t there.
The real benefit of a design system for an org like ours is internal. It’s about not reinventing the wheel. Once a problem is solved, we capture the solution and reuse it wherever it fits saving time and resources. Organizing our scattered features into general, shared patterns does something else valuable: it simplifies how we understand each product and strips out unnecessary complexity.
Trying to force distant, remote product teams onto identical components and libraries is often arbitrary and an uphill battle, at least short-term. There are much bigger wins to be had from building something more abstract. A shared way of thinking about our products, not a shared stack of components.
How I structured it
So instead of mandating a system, I ran the team through a sequence of exercises designed to surface what we already had in common.
A safe space to vent and reflect. I started by giving designers a place to share the pain points, wins, questions, and struggles of working in their own silos, laid out on a birds-eye-view geographical fantasy map so everyone could see and develop empathy for each designer’s perspective.
Products in a nutshell. Next, I asked everyone to summarize their product using a highlight “bento-box-style” diagram. The goal was simple: let anyone on the team understand any product in the portfolio at a glance.
Bucketing the patterns. With that shared context, we came together as a group to organize our products’ features into general buckets, a collective sorting exercise to find and classify the patterns hiding in plain sight.
Spotting the overlap. From there, reflecting on everything we’d mapped, the team could finally see the unnecessary complexities and inconsistencies running across our product line, the things ripe for simplification.
Going deep where it mattered. We picked the highest-priority inconsistencies to dig into, the ones that traced straight back to the pain points raised in that very first session.
Stay tuned for the results
That’s the setup. The exercises are done, the patterns are on the table, and we’ve chosen where to focus.
I’ll get into what we actually found, and what changed once a team of strangers-in-silos finally started comparing notes.
Results coming soon.