So, you need a design system.
Here’s what I know.
The idea is not exactly new. It’s a vision shared by many dev teams out there. We want to make our designers more productive and let them focus on the “inspiration” while we take care of the execution. What we really need is a system that can help us quickly build websites with reusable components and implement design updates without much hassle. A super fast design to code process. Just like Lego. You’ve got the box, all the pieces, and as long as you snap things together right, it’s gonna look pretty dope.
Yeah! Almost. I appreciate your excitement for building, but to deliver a great result, we have to take the time for planning. You need to consider what platforms you’re going to build for – web page, native app, WPF or QT application (yep, totally valid), smart TV, fridge, car, watch, and so on. And what kind of content you want to display – marketing content, user created content, streaming content, hardware controls maybe? Interactive forms, large data sets, data visualizations. Oof, so many options already.
Now choose what programming languages and frameworks to use, and set up a process to maintain it. A design system grows fast, and the devil will always find you in the details! （ ；￣︶￣） … Oh shut up.
Of course, there is nothing wrong with a team jumping right in, creating and improvising to find unique solutions. I like it that way! But at least come up with a somewhat defined scope before you make that jump.
o . ___---___ .
. .--\ --. . . .
./.;_.\ __/~ \.
/; / `-' __\ . \
. . / ,--' / . .; \ |
| .| / __ | -O- .
|__/ __ | . ; \ | . | |
| / \\_ . ;| \___|
. o | \ .~\\___,--' | .
| | . ; ~~~~\_ __|
| \ \ . . ; \ /_/ .
-O- . \ / . | ~/ .
| . ~\ \ . / /~ o
. ~--___ ; ___--~
. --- .
Don’t skip the bridge.
When working on design systems, I’m usually some sort of connective tissue between the creative design folks and the techies. It is my job to organize and clean up design elements before developers get their hands on them. However, many teams just skip this step. They either strictly divide teams, and designers hand-off their designs for good. Or they mix it all up, hiring front-end-designer-developers or somebody with *ninja in his or her title. This might be subjective but I believe being the bridge is almost a profession of it’s own. This is true for designers who are willing to understand code as well as for developers who are happy to talk about design.
You know, running in creative design mode is different from strategizing for a system. If designers have to cover it all, they have to flip a switch to move from creation to organization. This can feel like a terrible, overwhelming switch to flip. So they simply don’t do it. The design looks great, the project owners are happy – let’s expect the dev team to implement it perfectly.
Now, when a design wasn’t built with the big picture in mind, developers will find it difficult to translate it’s elements into reusable parts. In this case it’s often easier and much faster to build static pages without setting up a system of half-baked components. With this approach you’ll likely create inconsistencies and the product will become difficult to maintain.
So maybe someone could do the terrible, overwhelming task anyways? – And what task exactly do you mean?
Specifying the parts of a design system. It requires experience and the ability to translate visual into functional elements. The tricky part is getting a really good understanding of the full functional scope of a thing. What does it do and why? Ask that even for a button and you might get tangled up between small, medium and large, primary, secondary and ghost buttons – and what to use which type for. Do we even need these variations? Without such questions, we’ll pile a bunch of snowflakes that will make us cry for a new design system after just a few years.