Design Systems from the why to the how

I have been interested in user-centric product scalability for the past few years, even before being co-author of the design system I lead today.

It's clear that today, we can observe a broad movement in finding the correct answer to this problem.

"How can we scale products based on successful UX patterns?"
This is also where we started seeing the term "Design Systems" emerging in several publications as the solution to this problem and so many more.

What is a Design System?

Before diving into the why and the how let's try to understand what is a design system exactly.

There are a lot of descriptions out there, being the one that I feel best defines it from the Nielsen Norman group "Design system 101" article that states:

"A design system is a complete set of standards intended to manage design at scale using reusable components and patterns."

Let's quickly give it a go and dissect this definition by saying that a design system should be where we find the guidelines, patterns and building blocks based on well-defined design language and principles, easily scaled through different projects and products by a set of reusable components that standby those same standards.

WHY?

With the above introduction, some of the benefits of having a design system are already clear to you, but let me pin some of the main ones based on my own experience.

Scalability

Let's start with scalability, which will act as the most robust argument for applying the design system you invest in across different projects or products.

With a design system in place, we can design products that live within different configuration sets meant to grow quickly and significantly.

As a definition, we can take a design system's reusability aspect, which is a crucial enabler of scaling it. Having a set o reusable components, we can quickly create features for different user and business needs based on the defined core design principles.

See it like a lego challenge, where we find ourselves with the same box of Lego blocks that we can use to build whatever we want. Ultimately, we will have several different builds but still be identifiable as lego makes, given their design language structure and principles.

One great example that illustrates a scalable philosophy is the atomic design methodology.

Another great benefit will be efficiency, also easily seen through the reusability aspect.

By accessing a set of reusable design components and code, designers and developers can quickly drive their focus to their actual business needs, not bogged down in reinventing base features and tools.

There is a fundamental principle that any robust design system should follow. This is to become the single source of truth of the primary design resources and standards.

The single source of truth will help ensure alignment between different stakeholders by opening a direct line for feedback and increasing efficiency in the design and development handoff process.

Design DNA and Consistency

For example, your core business e dedicated to website creation for a specific core business where the design shall be adapted to the client branding and DNA. Then investing in a design system is not the best strategy.

Where design systems excel in heavy and complex product development cultures where continuous deliveries are a thing, and there is a vital objective of having a familiar look and feel across all projects.

A design system shall serve as an ecosystem where each feature is designed to be consistently functional and effective.
This will spread its design DNA across all features and products built on top of it.

How?

Now that we have gone through the fundamentals of why investing in creating a design system might be good, let's dive into the fun stuff on how you can start building one.

Design

First, we must decide what to use for the visual design process given that we should be able to cover fundamental requirements like:

• Create and access reusable components libraries
• An open line for direct feedback from stakeholders
• Solid organization features

There are a lot of tools out there that can help you cover most of these needs, being the most well-known ones in the community:

• Sketch
• Invision
• Adobe Creative Suite
• FIGMA

Again, tools come and go; the key is to keep the main principles in place to keep a healthy design system, even if you are forced to drop into another tool.

For this article, I will rely on my experience using FIGMA and how it can help you solve most of the common challenges regarding design systems.

FIGMA is a web application that can be run on most common browsers but can also be installed as a desktop app that you will need to use if diving into FIGMA plugin development.

I came from a design background based on Adobe tools that I still use today for other purposes besides UI design. But the ramp-up into FIGMA was a matter of hours, given that the flow and tooling are very similar to most of mentioned above tools.

FIGMA can house your design mockups and is also a powerful tool for prototyping. It provides a way of getting direct feedback from key players in the mockup files, leading to a decreased need for dedicated sessions and major refactorizations.

FIGMA also lets you create a master component library that can be shared across your community. This will allow any designer to drag&drop components, colour pallets and other libraries to reuse them in their designs. Checking the reusability mark for the design process.

Development

Realizing that the design process is already very open and flexible. Frontend development is a whole new world when it comes to flexibility.

If you research, in minutes, you will see a diverse set out there, resuming the most common ones to three such as React, Angular and Vue.

There are some critical lines of questions that you need to perform when choosing the stack for your reusable set of code components, like:

• How will you leed with the obsolescence process of a selected framework?
• How easy will it be to get skilled developers for that framework?
• Is it a good strategy to be tied to a framework at all?

Many design systems provide their set of reusable code components in more than one framework and even on vanilla Javascript.

Being part of a safety-critical software development company where the above decisions can easily translate into a showstopper. We decided to go with web components development, even when browsers were not fully supporting it.

At that time, we started using Polymer, providing the still needed polyfills, and today we are happily developing on Stencil JS.

Like Polymer, Stencil JS is a library, not a framework like the above-mentioned ones. In a nutshell, it compiles Javascript components classes into web standard-compliant custom elements. This also means it's easily integrated with any of the above frameworks.

It brings cool features into play, like Typescript, Decorators based patterns and JSX, also used in React.

For its unit and E2E testing support, Stencil relies on Jest.

How about the design and development handoff?

This is a topic of particular interest to me, given that I come from a product design background and left turned into software engineering during my academic and professional path. I have been constantly on both sides thought my whole career.

Nevertheless, I know this is a real problem, especially in heavy engineering cultures where digital transformation it's just starting.

As mentioned above, as a vital fundamental stating that a design system shall act as a single source of truth for its primary resources. But now we have a problem to solve because we have the design standards and components in FIGMA and the component's code binaries in some code repository manager we choose to use.

How can we link both sides together?

There is a fantastic and well-known tool called Storybook that can help us with this.

Storybook is a flexible tool given its API; it's possible to customize and adapt it to any project need.

It's based on stories, where each web component can be run in different configuration scenarios to showcase its features.

The component documentation comes alongside those stories, primarily based on the readme files that, today, most frameworks or libraries can already auto-generate based on a set of annotation and code comments strategies.

You can also write documentation pages based on markdown or MDX that combines markdown with JSX, which I might say is pretty damn awesome.

There is a nifty trick to connect all of this to FIGMA's components and design system guidelines; this is done by using a dedicated plugin.

https://storybook.js.org/blog/figma-plugin-for-storybook/

Like FIGMA, Storybook is also open for plugin development with a wide range of open-sourced plugins marketplace.

By configuring each component story with its FIGMA decorator linked with the component guideline project, we connect both worlds, the production and design ensuring that needed sync.

This can be done both ways by adding to each component in the FIGMA component documentation field the link to its stories in Storybook, closing the cycle.

How about no-code development?

If you love to code, this question might make you shiver, but there is no reason.

Just like was already mentioned in this article, one of the healthy design systems is the reusability aspect that it provides. With that in mind, imagine a scenario where you can easily extract the configuration metadata for a web component directly from a design mockup of an application to be implemented. Or even the source code to an element that follows the design system guidelines.

That will not release you from all of the development you still need to perform for your feature objectives, but it will free you from most of the generic efforts necessary until you start to focus on the logic of it.

This is the primary objective, to let you focus only on what you need to focus on.

One of the ways that this can be accomplished is to take advantage of the open FIGMA API to create custom plugins that understand which master components are being used in a mockup and their different states. With that, you can easily convert those mockups into JSON configurations or web components with all the properties or styles that make that component respect the design system principles.

To start creating FIGMA plugins, you must run their desktop version. The only one that will not work for this.

Once you open the plugin window, you will see three templates that will auto-generate a plugin project in your chosen folder.

These plugins are written in Typescript. More details on the FIGMA docs here…

Hope that this article has been helpful and motivates some of you that can benefit from having a design system to start it and learn from your own experience.

Keep in mind that each project is a project, and not all design systems out there might fit your needs, but by knowing the fundamentals, you will have more chances of making better decisions on what might better suit your project needs.

Also, I didn't even scratch the surface of the world of design systems; I have only shared my experience and learning process to this day, and I hope and know that will continue during my professional journey.

See you around…