Let's find our way by analyzing our UX sketches before digging into the details and building anything.
The scope of the next two modules will be to design, prep, generate, and modify generated code for about ten "elements," or more basic components. Our approach will be to go from "low fidelity" and broad strokes to the increasingly clear and detail-oriented aspects.
In the end, we will have created a few complex components, like this
ProductCard, composed of many simpler elements. Both the simpler and complex components will be created in Figma and documented before we turn them into code.
But first, we will start by understanding our needs and laying out a rough direction.
Working from component to tokens, or from tokens to component...?#
With a significant risk of sounding completely milquetoast, there is really no right or wrong way to work with components or tokens or anything in between.
For me, it tends to make sense to put a small foundation of values in place, like a painter preparing some basic colors to start with, and use these to mix into richer variations as the work progresses. Also, consider that not all change is created equal: certain aspects will definitely make deeper imprints than others. For example, your grid system will probably have a bigger impact and more cascading effects if that's changed later than if you were to just change a color. With that said, I think a "back and forth" or "zoom in, zoom out" approach is generally good, meaning you'd make the small foundation in the beginning, then build and rehash, adding on whatever you need over time. Similarly, you'd happily remove values (or tokens or any other work) with that same light touch.
Those who object to design systems—yes, there are such people!—rarely seem to take this to heart, letting the apparent rigor of the design system constrain them already early on.
Let me very briefly tell you about a popular creative model called "the double diamond," created by Design Council.
In this model, you begin by "diverging," exploring lots of alternatives, then "converging" to a small set of options, and then you do the diverge-converge phases again based on the previous work. What this does is create a model for how change can manifest itself—do we allow bigger changes now or just the smaller incremental ones? Remember, the bigger the context, the more collateral a change has. This again goes back to how wide-ranging changes need to be at least somewhat controlled. The double diamond gives us one way to allow cyclic, iterative improvement to be part of what we do.
Quick note: In no way does all creative or design work follow a model as clean-cut as this (nor should it!), but I will demonstrate how we can effectively use this method in a design system context when creating a single component.