Skip to Content

The Design System Between Us

Design systems by default entrench existing workflows rather than changing them.

But in my ex­pe­ri­ence, de­sign sys­tems haven’t brought this kind of rich, cross-func­tional col­lab­o­ra­tion to most or­ga­ni­za­tions. Instead, the ex­ist­ing di­vi­sions be­tween de­sign and im­ple­men­ta­tion have be­come en­trenched, and mas­sively so.

Marcotte has ob­served that de­sign sys­tems so­lid­ify, cod­ify, and re­in­force ex­ist­ing di­vi­sions be­tween the si­los of engineering’ and designing’. He iden­ti­fies that there has not been any tool­ing that’s emerged to work in the space be­tween de­sign­ing and de­vel­op­ing, and our tools to­day are still one-or-the-other. Marcotte also ref­er­ences oth­ers like Tom MacWright and Tim Kadlec in iden­ti­fy­ing that the con­tem­po­rary com­plex­ity and weight of the front end makes it harder for de­sign­ers to be in­te­grated into those sys­tems.

Marcotte also sug­gests that a met­ric for de­sign sys­tem health can be found in iden­ti­fy­ing the process of a de­signer chang­ing pro­duc­tion css: how does that hap­pen? How long does that take? Who is in­volved?

For many or­ga­ni­za­tions, the tech­ni­cal bar­ri­ers to cross-func­tional col­lab­o­ra­tion can be un­ac­cept­ably high … More of­ten than not, your de­sign sys­tem be­comes a mir­ror of the way your team al­ready works

Marcotte calls out the im­por­tance of a de­sign sys­tem is in ar­tic­u­lat­ing how a team works, and that the re­la­tion­ship be­tween de­sign­ing and de­vel­op­ing is one of the core re­la­tion­ships that a de­sign sys­tem has to con­tend with.