Design Audits, Systems, and Defining a Foundational Design Language
The topic of Design Systems is without question a very popular one. Every other day there’s a new article on the topic, detailing best practices on how to build that system, while also illustrating which ones built by several Organizations on the market are the best, and where their virtuosity lies. Oh and tools to build Design Systems with, which ones best empower and integrate with diverse teams, which are ones are most likely to be sustainable and so on. All these articles are important and worth reading since they essentially bring attention to the topic itself, emphasizing in the process, the necessity to maintain consistency and coherence among product experiences, not to mention if used correctly, these systems can compliment effective onboarding experiences, and scale (both in agility and quantity), the process by which ideas get brought to market. Another common thread I’ve started to realize across these many articles is how they invariably include in their content an array of elements & terminology associated with this ecosystem/discipline. This typically includes Style Guides, GUIs, Toolkits, as ways to illustrate Design Systems themselves, at times failing to clarify how they’re part of the system, or even if they are indeed part of the system. I’m hoping this article can generally compliment all the information that has been compiled throughout Medium and other Design Blogs (including Invision’s, Marvel’s, to name but a few). As usual, I’ll pepper this article with examples of my own professional career, and how in the process of building design systems in the past (and at times the lack of), has impacted the experiences being conceived.
Foundational Language. Wikipedia defines Language as: “A language is a structured system of communication used by humans, including speech and gesture (spoken language), sign, and often writing. The most widely-spoken languages have writing systems of glyphs that enable sounds or gestures to be inscribed for later reactivation”.
One of the main aspects of this definition that resonates so deeply is precisely the aspect focused on “structured system of communication”, since that is at the root of what a Design Language actually is, and what a tool such as a Design System is meant to document and represent. If properly established and edified, a Design System will successfully illustrate what comprises a specific Design language of a particular brand. It will illustrate how that language exists, in what it exists, when to apply it, and generally speaking, define that whole ecosystem. Organizations have had for the longest time processes to document their brand existence, typically in the shape of more or less refined brand guidelines. Not to reduce their offerings to this particular component, but these Brand Guidelines and Initiatives supporting them, have been staples of Design Agencies for decades. These guidelines are, for the most part, maintained with regularity to ensure consistent usage of the brand, but also to actively document brand evolution, particularly as brands mature, and more diverse product solutions are shipped to market (and also because markets are ever changing, and therefore the brands and their guidelines need to keep shifting as well). All this to state the fact that Organizations and their brands, are something of value, something clients resonate with, build relationships with, and therefore, a valuable asset to be maintained, cultivated and labored.
Unlike Brand Guidelines which essentially have been around for quite some time, Design Systems have as of late, become a more pressing and urgent topic. This is due in part to the popularity and impact of Technology, specifically when it comes to Software and Application design, but also because since the advent of the iPhone and subsequent Android ecosystems, both their distinct languages and behaviors have brought much attention to how Design languages are edified, maintained, and democratized. Design teams, since 2007 (for the iPhone, 2008 for the Android) have had to become acquainted with these Design Languages, typically through the assistance of Graphical User Interface kits (and their documentation), in order to successfully understand Interactive, Visual, Motion paradigms that are inherent to these ecosystems. Design Systems have existed for far longer than since the mobile revolution started, but what that colossal shift in technology adoption and consumer habits has surfaced, is how important it is to have a documented Language that is consistent, coherent, detailed, parsable and evidently usable. These days more and more companies are building Design Systems, and assigning an array of Designers to sustain and enhance them, all with the purpose of achieving Consistency across their offerings, but also because if built effectively and used appropriately, this tool has the power to be consumed by an array of different teams, all of which can get what they need from it, even if they’re going on very different journeys.
Building a Design System. As the definition of Language clarifies, at its core, there is an establishment of a series elements and rules by which they live, which in turn, allows for that language to be understood, transmitted/shared and utilized between different individuals. The same is applicable for a Design language and Design Systems. A Design System obviously can’t exist without the context of the Brand that is associated with. The Brand is where it all starts, since that’s essentially the story an Organization is crafting, with the language that underlies it being the operational component which allows for the brand narrative to be consistently communicated.
These days, in order to craft a useful and usable Design System, many Designers and Strategists have been pouring and have been inspired by the work of author Brad Frost, who coined the terminology “Atomic Design”. According to this author, a Design System should contain Atoms, Molecules, Organisms, Templates and Pages. This progression is very sensical in the sense that it allows for baseline elements to be documented, and for a progression of artifacts to be built around those foundational elements. Another metaphor or approach to understanding this buildout or structure of a Design System, is to think how an individual learns a new language. You can look into the process that an app such as Duolingo has established when it comes to teaching new languages, where the learner/student, goes through a series of progressive levels, in order to eventually start crafting sentences, but also deftly communicating orally in the new language they’re learning. But it all starts with the foundational elements, in the case of a new language, there are grammatical elements needed to understand how to read, form sentences and eventually communicate in this new language. For a Design System this implies documenting everything that is associated with a particular brand, the rules and guidelines by which a brand exists, figuring out what is specifically applicable to Product Design.
Design Systems should in fact leverage much of the information that exists in Brand Guidelines, but go even further than what those establish. Defining what atoms are, including colors of the brand, fonts, iconography, baseline elements that are inherently associated with a particular brand, while also contemplating that what serves the purpose of Marketing Driven materials, may at times be insufficient for the needs of Product Design in itself. What that translates into, may be surfaced in a variety of different aspects, fonts for instance, since brands at times can have custom built fonts, which are adequate for their market positioning, advertising needs, but which are not web safe, or even at times, possible to be integrated with other languages. Therefore, the Design System should always document, what to do in situations such as those, what are the alternatives, when and how to use them adequately. Defining the atoms, molecules, organisms, which have translated into artifacts such as forms, panels, modals, tables, data visualizations, templates, pages themselves across multiple form factors, to name but a few, are components which have become associated with User Interfaces, which should be clearly defined in the System (across Desktop, Mobile, Wearable, Voice Only, any and all experiences the products exist on). On that note, and since the system is and should be consumed by an array of users that go beyond Designers, it should contemplate snippets of usable and clearly identified code, which allow for these elements to be easily built and integrated into whatever is being created. Be it with languages such as CSS, HTML, Javascript, PHP, and the list goes on, whatever language empowers these elements to come to life, should be documented and effectively explained on its applicability. Only then does this tool, this system becomes a powerful tool, whose scope goes beyond that of just educating Designers. It also eventually serves the purpose of instructing Product, Development, Marketing, Sales, Support teams (to name but a few), to understand the full scope of a Brand, with information which ranges from atomic/foundational aspects, to components which include UX Writing, Microcopy, Micro-Animations, Interactions, and the list goes on.
Design Audits, Toolkits, Style Guides, GUIs. I recently went through a thorough process of performing a Design Audit, across a variety of products and master features, with the support and partnership of Product and Development Teams. The goal for that particular initiative was to uncover where discrepancies of product and brand narrative existed, and start establishing the path for consistency and for a robust Design System. This Design Audit did not surface new groundbreaking insights: everyone on the team, with enough visibility into the product suite, already suspected that there was a serious gap in terms of consistency across the product suite. The organization throughout the years, through a series of acquisitions, episodic contracts with incubation partners, generated a series of product offerings, which all maintained a very specific product narrative, never quite feeling as a unified product journey.
The Design Audit had the goal to essentially identify the products and their main components, and build a strategy on how to bring convergence into all these disjointed product experiences. And this, in itself, also became the genesis for the Design System initiative. Looking at the brand, at all the products in which this particular brand multiplied its offerings, understanding its users, the global footprint of these offerings, with additional consideration into factors such as accessibility, allowed for the system to be divided into a sensical structure, very much similar to what is described in the previous point, which also allowed for every single organism, template and page to be progressively streamlined and built with a standard footprint, properly identified in the emerging system (the Audit also allowed to strategize a tactic to bring convergence across the products according to different components of the product experience itself, including for instance unified log in/log out experiences, navigational paradigms, GDPR and Technical Documentation, Core Functional Paradigms, to name but a few). In parallel with this system initiative, there was also a concurrent one which focused on the creation of Graphical Tool Kits, essentially shared libraries of components. These libraries allow for teams to easily drink from the same source, making sure there’s consistency in what they are conceiving, while also reassuring everyone that what is being utilized has an implementation component already vetted and approved. And if not, these libraries, and the system itself can always be expanded upon. However, and this is what is particularly important to always keep in mind, shared libraries are not a Design System. They are and should be an artifact that is associated with the system, but its utilization is typically more focused on Design teams, whereas Design Systems as a tool, can and should be leveraged by many teams. Toolkits, Style Guides, GUIs are essentially artifacts that are consistently and thoroughly built to educate and be shared between teams, but they don’t have the scope and footprint that a robust Design System will ever encompass. A Design System defines the totality of a language, whereas a toolkit, a style guide, a GUI, unifies, documents and represents the composition of that language, but even them are limited in their scope.
Tools to Build Design Systems. There’s a series of tools in the market currently, all aimed at seizing the attention of Organizations, particularly as there is a general excitement around Design Systems, and teams typically need for this initiative to scale rather quickly. All these tools claim to automate the process by which the Design System can be built, and invariably have close ties and integrations with other tools designers are using. These days Design System tools include Invision’s DSM, Storybook, Framer X, Zeplin, and the list goes on, but all this to say, they essentially reduce the concept of a Design system to the component of shared libraries, which are documented, and sustained by a series of implementation driven coding languages, which can be consumed by development teams. While all these tools are quite useful, they fall trap to the myopic concept that Design Systems are essentially for Designers and Development teams to utilize. And that in itself is a fallacy. While these integrations and components are without question fundamental for the operational efficiency of the integration of Design and Development efforts, a robust Design System should provide insight into all that was covered on the points above. While having used some of these tools extensively, one should always keep in mind that Design Systems are at the core of the existence of a Brand and the offerings of an Organization. The dependencies that some of these platforms create, can become troublesome in terms of scalability and longevity of what an Organization is intending to do.
Reality Check. Each Organization and its Design team will have to pay close attention to what they expect their Design System to be, how it can evolve and be maintained. Much like any language, it has to be nurtured, groomed, in order to stay relevant, pertinent and usable. It’s fundamental that Designers both educate, but also strategize when it comes to bringing and building a Design System to an organization. This is an endeavor that goes beyond shared libraries, toolkits and assortments of carefully curated and manicured assets. This involves creating a product in itself, that represents an ecosystem, from which many product experiences can be derived from. Therefore, making it informative, detailed, thorough, but also continuously improvable is something to always keep in mind.
I’ll conclude this article with a quote on the topic of systems from Albert Einstein:
“Everything must be made as simple as possible. But not simpler.”
