Design system: How to successfully collaborate?

[Dear readers, I’ve decided to move my content to a different platform — Manage Frontend if you enjoyed reading my writing, please spare a minute and subscribe to my content on Manage Frontend. Thank you!]

Recently I’ve covered a couple of topics related to design systems — how to build an engineering team, how to build a design system library, and how to efficiently scale development.

This time I want to focus and share the lessons I’ve learned on — How to successfully collaborate between product, design, and engineering?

In product development, there are usually three parts to the equation — product, design, and engineering. The product defines features and requirements, design defines how it should look and feel, and engineering is responsible for actual implementation.

In a small organization collaboration between the three is fairly straightforward — everyone can pitch in, discuss potential issues, find the best solutions and move on. But how do you maintain successful and efficient collaboration in a fast-growing, large organization?

The “usual” way

Let’s take for example an organization with multiple product engineering teams — X, Y, and Z. Each team is responsible for a specific product area and may usually work in a silo formation — people in each team work autonomously without little to no collaboration between other teams.

Some of the most common issues that can usually be observed while working in this setup:

• Wasted resources by “reinventing” new versions of existing components
• Hacking existing implementations to fit “slightly different” requirements requested by product or design
• Wasting resources by doing design research for patterns already used by other teams

And so on…

The “collaborative” way

One of the ways to deal with the problems mentioned above is to encourage teams to collaborate more. Depending on the experience and other factors people from different teams may naturally engage in collaboration between the same discipline.

This can work well until people start disagreeing. Usually, because there is no central authority to resolve such situations people can freely “eject” from collaboration and do things their “preferred” way.

The “design system” way

In my opinion, the best way to establish central authority is to form a dedicated design system team. Depending on the size of the organization this could either be a single team with designers and engineers in the same team or two (or even more) separate teams.

The main idea of DS teams is to fully own everything UI and UX related that is shared between product teams and offload any need for collaboration in that area. However, collaboration still happens — members from product teams have to collaborate with design system teams. This is more efficient because members of DS team are supposed to be aware of the work happening in other product teams and can dedicate time to find the best solution to the problem. In addition, DS teams have full authority to make final decisions as that is their responsibility and that’s what they are accountable for.

Tweaking design system collaboration process

When I was working as a Frontend architect I did spend a lot of time working closely with product teams, had to sync and align with the design team, and also planned work for our design system engineering team.

In the beginning, the process was just shaping up and I noticed quite a few things that we could improve. Initially, when product designers created new designs they were still missing alignment with our design library. This very quickly leads to engineers in product teams implementing overrides or hacks on top of our UI components library.

As a way to solve this problem, we initiated regular product design reviews which were done by our DS: Design team. This allowed us to catch early on any discrepancies and make necessary design corrections before it reaches development.

Another very important part of the process was an ongoing regular collaboration between design system engineering and design teams. Making changes in designs is much easier than doing that in the codebase, hence sometimes design changes that were introduced by designers could be vetoed by the engineering team. Engineering and design teams would look for alternative solutions that would satisfy both design and engineering concerns.

Once the whole design system collaboration process is mature enough, engineers in product teams should be able to expect product designs that do not require implementation of new base components, tweaking of existing ones, or adding any “local” overrides to finish the task.

Final thoughts

You probably can recognize your organization using one of the collaboration ways mentioned above. You might even say that one or the other method works really well for your team or organization. And nobody can really argue with that — different organizations adopt different ways of working and every organization delivers something (those which don’t are probably already out of business).

However, in my opinion, the question should never be whether something is working? — the question should be how efficiently and successfully it is working?

I personally learned that the best results are born out of collaboration. Organizations can hire as many talented people as they can but no individual can make as big an impact as the same individual working in a group. In some cases it might sound counterintuitive — what if that individual is much more experience than the rest of the group and could move at least twice as fast working alone? It might seem that the individual could be slowed down by the rest of the group, but think of the value it adds long-term to the group — knowledge sharing, experience transferring, coaching, and mentoring others until everyone else “catches up” to the same level.

When considering “what works for your organization?” think about how alternative ways of collaboration, specifically the “design system” way could improve your process. Be open to changes