A Name and a Place
Making it official: We give our design system a (working) title and a hub.
It may almost seem too obvious—but giving our design system a name and allocating space to it as soon as, well, today, could very well get the ball rolling and introduce more structure to our undertaking. Oftentimes, teams already have processes and components in place that could theoretically become part of a larger design system, but due to the fact that they were not conceived with a system in mind, their scalability potentials evaporate. A working title and a dedicated space, as simple as it may sound, may help us tie together what we already have and catalyze the conversation around future efforts.
A Name
When it comes to naming our design system, there’s no reason to be overly cautious or too prosaic. We should feel free to be playful and imaginative and incorporate attributes that characterize our team or describe our vision.
A working title will immediately simplify our discussions, as it's much easier to address something that has a name than an abstract concept. It will also help to make clear distinctions between aspects we consider to be related to the design system and those which are not. And perhaps, we can come up with something more inspiring than [Insert company name here] Design System. (A dedicated, independent title is especially well suited for software platforms addressing larger development communities or white-label product ecosystems.) When it comes to naming our design system, there’s no reason to be overly cautious or too prosaic. We should feel free to be playful and imaginative and incorporate attributes that characterize our team or describe our vision. Material, for instance, encapsulates the core structural and visual ideas of Google's design system in one short word, without being too narrow or restricting.
In the 2020 Design Systems Survey conducted by Sparkbox, almost a third of all participants stated that their design system doesn't have a name.
A Place
To further establish our design system, we dedicate spaces to it right away. Depending on the nature of the first elements we want to organize, these might include a shared folder, a Git repository, a cloud spreadsheet, or a collaborative UI Kit (built and maintained in Adobe XD or Figma, for example). Steady Flow of Truth proposes a circular approach in which every explorative effort and every project we work on continuously fills our repositories with new elements. Minimum Viable Design System suggests to set up a lightweight knowledge center (this could be a wiki, a GitBook, or just a shared spreadsheet) where we reference all internal building blocks, as well as 3rd party resources we agreed to integrate into our system (see also: A Living Handbook). To identify already existing elements and those we want to tackle next, it can be helpful to create a map with categories and subcategories (see fig. 1). Such a map can serve as a model for our (lightweight) reference documentation and guide our efforts. We can (and should) regularly revisit this map in the context of informal, cross-functional workshops to make sure we're all on the same page.
In summary, giving our design system a working title and dedicating spaces to it (even during the first stages of planning and before fully committing to its development) can make an otherwise abstract concept more tangible and easier to discuss. Moreover, it comes at basically no cost.
Where this tactic fits in
Minimum Viable Design System provides a helpful frame of reference for establishing our system repositories.
Design Tokens, UI Kit, and A Living Handbook all describe forms of design system repositories we can use as starting points.
Authors and contributors
D. Kurfess
Last updated
