Design System failures - Going all-in on a dedicated team

18/10/2022 by Benoit Rajalu

This is a short series about failures I've seen or made in the design system space. It is not about self-pity or drama, and it is not reproachful. It is a list of insights (hindsights, even) on two and a half years spent working on design systems, one of which was spent in a dedicated team. Its aim is to help you avoid my mistakes, and to remind me of them later on.

A dedicated design system team gathers designers and developers to work full time on the design system. Their tasks and scope vary from company to company, but they ought to be "guardians of the temple". They are here to help, enforce, promote and guide the effort.

Most successful design systems have a dedicated team. You could believe that any design system with a dedicated team is on the right path. You wouldn't be wrong, but there are two significant catches: scale and adoption.

Adoption is the largest issue. A dedicated team's minimal ownership is the system's documentation and its methodologies. None of those functions have any value to your company if the design system is not used. If it is a little bit used, you are still dedicating personnel to documentation with very little observable implementation and methodologies that are not delivering.

Which brings us to scale: a design system's promise is only fulfilled when it reaches critical mass. Developer-to-designer handoff, UI consistency, increased production speed for front-ends etc... We do paint a pretty picture when we promote systemic design approaches, but most of those benefits only become obvious if adoption is massive (if not unanimous) and if the system provides everything the adopters need.

So don't start your design system by entrusting everything to a dedicated team. They can burn themselves out trying to build everything then implement in the products (which is its own can of interfering worms). Or they might burn themselves building documentation and tools nobody actually uses or wants.

Ensure the customers of the design system are on board, that they are listened to and know that their needs are the driving force behind the project. Ensure they know the dedicated team still requires their contribution and engagement. What if contribution is not an option but engagement is still there? Then staff your dedicated team accordingly: its scope is now exponentially larger.

Takeaways

The short version: you will need a dedicated team, but having one is not enough. You can't build a plane just because you've hired a pilot.

The cost-saving outlook: start by tasking a team with cleaning up your currently-used UI libraries (code and design). When they're done, they'll have built a backdoor to a ubiquitous design system.

The paradox: not investing in a dedicated team will lead to cut corners. You will skip processes or overwork individuals.

Next: getting satisfied with your communication

Illustrations credit: Dlubacz over at Whoooa.