Recognizing a design system
There is no single, right way to build a design system, but there are some key things that differentiates a design system from other large-scale design endeavors.
First, a note on why there is some confusion
I think people love the phrase “design system”. It holds within it a tacit nod to the complexity, investment, and effort involved in making a system. My theory is that there are three primary reasons behind why the term is being co-opted:
- Acknowledgement — people see the term, recognize the investment of time, complexity, and effort, and leap to the conclusion that what they leverage is a system without digging into what a design system is.
- Sexy growth — it looks better to leadership, board, stakeholder, marketing, and the public that a team has spent so much time on a design system rather than branding or visual language. It has the tacit sharpness of a brand-spanking-new-productivity to flaunt.
- Protectiveness — I think there is a deep enculturation of diminishing or pshawing effort as a way to control expenses and expedite timelines. It’s harder to diminish a system. The very word implies a complex edifice with complicated interactions that need to be teased into balance.
So, there are multiple cultural factors (and more than I’ve detailed here) that I think is impacting the use of design system taxonomy beyond it’s originating form, and in the process muddying expectations and delivery. My understanding is that the combination of design and system was to acknowledge the more complex operational substrate of the coding. Think of it along the lines of systems administration, modernized and nuanced by the defining design.
Want some of the intent? Check out Ethan Marcotte, Atomic Design and patternlab.io. As with any truly game-changing idea, the unpacked meaning has shifted over time, but the fundamental ideas are still true and help to explain why the different taxonomy was devised.
Basics of visual language
To build a visual language takes hundreds of hours of time, especially if support libraries are also being built. To build all the nuance of a visual language around complex button use, including hover and click states, can be time consuming in an of itself; add all the other reusable components, and the hours investment compounds. We do it because it keeps the output consistent and speeds up design of new peices later.
In the print sphere, often the designer is building both the visual language and the objects it’s being used in (ads, fact sheets, white papers, brochures, etc.). In the digital sphere, the team starts with (and can build from) designer, front end developer, and project manager to make it a reality.
There’s a reason design systems and visual language get conflated. They include some of the same things, and from a client point of view may seem synonymous.
A visual language:
- Defines color, font, spacing, etc.
- Defines baseline components, e.g., buttons, tables
- Often develops a library of objects — software, code, or both — for easier iteration
Basics of branding
Building brand is a long-term commitment. It is visual, but it is also the words chosen, the ideas leaned into, and consistent use over time. I believe the branding team tends to correct when others try to mistake branding for one of the others. Conflation will still happen when the team isn’t around, because design system is sexy and leans into the complexity involved.
Branding can take an entire business of specialized skills sets. It needs all the skills for visual design (print and/or digital — branding covers both), and public relations, copywriter, and account manager are added as a baseline. Depending on the use case, the skill set expands.
Branding includes:
- All the visual design pieces
- Imaging (illustration, photos, glyphs/icons) styles, placement, and uses
- Logo styles, placement, and uses
- Tone and voice in writing
- Tone and voice in imaging
- Often develops a library of images to reuse, iterate on, and as an example set for tone and voice
Basics of UX Design
UX design marries psychology and behavior understanding to the scanning of a page and the process of moving through information, regardless of what the information is or how it’s surfaced or not surfaced. It affects the experience from macro to micro — from how the information is slotted into life as a whole, to the look and feel of a digital button to affect behavior.
UX design is a field because it is so complex, and the aegis include a vast set of subspecialities. UX design reflects the complexity of its primary subject: people.
UX design can include:
- Understanding the user
- UX writing & microcopy
- Accessibility review and design
- Flow design (from macro to micro, abstract to concrete)
- Investing in the user through design, information surfacing, and flows
- Applying cognitive bias bets, memory supports, and attention supports
Basics of a design system
At it’s simplest, a design system includes:
- All the visual design pieces, baked in
- Tiny bits (e.g., color, font, negative spacing/padding) and rules around uses
- Medium bits (e.g., buttons, tables, cards/teasers) and rules around uses
- Big bits (e.g., templatized page/screen layouts) and rules around uses and when it’s ok to make new big bits
- How each level of bits reacts according to device and screen environment
- Definition of how varying content & visual language pieces flows in and affects the bits
A design system should:
- Be flexible according to content without changing component structure, including edge cases
- Have defined patterns that can flexibly adapt to changing content
- Be scalable across designs, use cases, and devices
A good design system will have
- Visual language
- Branding pieces in an available context (libraries, documentation, contact and process support)
- UX design macros surrounding the creation and maintenance of content
- UX design micros supported through component consistency
- Understandable and communicable information architecture around the components, their finding, and their leveragability; assume someone will leverage them creatively
- Documentation of the invested logic of the system in a narrative build, e.g., from introduction/executive summary to nuance.
So let’s break this up into the skills needed to produce a system. FYI, this is a team effort; yes, they are different skillsets, but more importantly the cognitive landscapes are very different. So, with that caveat, the skills:
- Visual design — font, color, layout, components; pulled together into use cases that are scalable per user, content, artifact, device, etc.
- UX research — suspend ‘known’ to listen to the users on all levels to better understand the wishes, constraints, pain points, and effort they are comfortable with
- UX design — design through the found process and usability; focus on touchpoint interactions for the entire user body, including the people building from the system
- Information architecture — mental models, connectome, organization, delineating and transferring understanding
- Back end development — any true design system requires a more complex development foundation and data infrastructure
- Front end development — As well as the usual front end coding languages, the front end developer for a design system has to have the soft skills and time to go up the learning curve of how to parse together the complex information architecture built into the design system while still making an elegant and modifiable coding infrastructure that has more ties to a back end architecture than a visual language would
- Project management — Making sure all the pieces are hanging together, that the project is staying on course, and primary client and accounting interaction
- Writing and presentation — this helps to support short term and long term success. A design system is complex and built on systems thinking; people lean into linear process in their day to day lives, especially under the aegis of efficiency. Do the parsing and document it for your users, maintainers, and for your future selves while it’s still fresh.
And not to forget
This is one aspect of support for content. Content can vary from purely data to purely creative, and scale from individual to corporate/governmental. These pieces — visual design, branding, UX design, and a design system — support the process of content. They do not create content.
