If you’re a long time follower of Design System University, you’re probably know that I’m a big advocate of designers learning more about code, especially on design system teams. 10% of the Design Systems 101 course is focused on changing the process to get designers closer to the codebase. 4 out of the 52 chapters in the Design System in 90 Days workbook are spent on leveling up designers’ proficiency with programming technologies. It‘d be reasonable to assume that I’d support every designer on a team knowing at least a little bit of code.

Reasonable, but incorrect.

Let me be clear: I’m all for the emergence and growing of roles like design engineers, design technologists, creative developers, and the like—people who have the affinity for both design and engineering prowess. (If these are new terms to you and you’re interested in learning more, I suggest starting with Kelly Harrop’s & Adekunle Oduye’s excellent podcast, Code & Pixels.) Without these roles, the stereotypical design + engineer pair often falls to dangerous tropes like designers envisioning things that don’t make much sense in digital environments and engineers’ primary roles being gatekeepers to tell the team what can’t be done.

Design engineers short circuit that vicious cycle by grounding work in reality and being able to build practical solutions that move a team forward in a way that disconnected discussions never can. This is a massive added value for any team. Design engineers know better than most what can and can’t be done, because they’re usually closest to the metal.

Design system teams incentivize practicality through the crushing combination of tight deadlines at the broadest scale possible that promise exponential results. So, most design system teams prioritize the surefire home runs, the ones with the least risk and the highest chance of success. That typically means writing web components or React code, publishing packages, versioning, tagging, etc. With design system work, design engineers end up being closer to engineers than designers. So, together, engineers and design engineers work on shipping components, because we need them to. There’s usually more component work than engineers and design engineers to do it and increasing headcount seems unlikely, so we surmise that, if we could teach the designers to code, they could jump in and help ease the burden, even if in a small way. Because if everyone on a design system team could code, then everyone could help build components.

But we can’t include designers who can’t code, because they make the process less efficient, which flies directly in the face of the efficiency design systems promise. Said differently, on a design system team, designers who can’t code seemingly increase the margin for error.

For English speakers, we understand the word “error” to mean “making a mistake”—something that is wrong. But the Latin origin of the word—errare—has a few other meanings too. It also means to wander, to stray.

In Steven Johnson’s book Where Good Ideas Come From, he writes:

…error is not simply a phase you have to suffer through on the way to genius. Error often creates a path that leads you out of your comfortable assumptions… Being right keeps you in place. Being wrong forces you to explore.

The common argument for designers learning more about code even if they don’t learn to write it themselves is that “it’s good for them to know what’s possible.”

Not always.

One of the best reasons to have designers who can’t code on a design system team is precisely because they don’t know what’s possible.

When everyone on the team is doing practical, reasonable, realistic things, it’s valuable to have others who suggest and/or do “impractical,” “unreasonable,” and “unrealistic” things. Sometimes, these end up being the most valuable things, because it’s born of exploring the fringes of the work.

Johnson continues:

…good ideas are more likely to emerge in environments that contain a certain amount of noise and error. You would think that innovation would be more strongly correlated with the values of accuracy, clarity, and focus. A good idea has to be correct on some basic level, and we value good ideas because they tend to have a high signal-to-noise ratio. But that doesn’t mean you want to cultivate those ideas in noise-free environments, because noise-free environments end up being too sterile and predictable in their output. The best innovation labs are always a little contaminated.

If designers who don’t code aren’t working on components, what else is just as valuable for them to work on? I’ll share details about that in next week’s newsletter, “The Critical Path of Design Systems Work.”