This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.
1 - The Mission
Ok, so youre a really passionate UI developer
Great! Weve got an exciting project that we want to entrust with you.
Our top-notch, e-commerce site ZapShoes provides the zappiest way to get shoes delivered to your doorsteps.
We recently raised 100 million dollars in funding, and we believe we can keep the momentum going by giving our application a facelift.
Weve hired a core group of designers that have whipped up a fresh design system.
So far, the design system just includes a set of Figma files.
Since youre the UI guru, we want you to build tools that will ensure that our current web application can successfully be migrated to the new design system and stay in sync with it.
We also want the tooling to be flexible to be able to easily handle a future redesign.
Moreover, we want to ensure that if we add applications for other platforms, like mobile and desktop, that we have a smooth way of ensuring that those applications can adopt and stay in sync with the design system.
Imagine being a new hire and assigned the project as Ive outlined above.
How would you feel?
Well, given that youre a developer, you may feel excited.
After all, developers love solving problems. At the end of the day, the project is just another problem to solve, and solving problems is fun.
You might also feel energetic.
A design system is a really fun thing to work on.
Its a perfect blend of doing something thats highly visual and architectural, requiring you to think on a large scale of how systems work together.
It satisfies both the visually orientated and engineering-driven sides of a frontend engineer, a combination that is hard to come across.
More likely than not, you would feel nervous.
Creating the tooling around a design system is an exciting, energizing task, but it is also intimidating.
There is a whole lot of ground to cover, starting from receiving a set of design files to delivering assets to an indefinite list of consuming applications, regardless of platform and technology.
You are molding the way for the future yet working within the bounds of current technology, which is always subject to change.
There is an indefinite list of stakeholders interested in the tooling around the design system, each wanting the tooling to work well for their use cases.
Let me encourage by making some remarks which hopefully will take the bite out of these intimidating thoughts.
First, if you are a developer you love to solve problems. Not only that, I completely trust that as a developer, you are talented in being able to solve problems. A design system is just another problem that you are capable of solving.
Second, a design system is satisfying to work on as mastering it will give you an appealing professional skill, enlarging your critical thinking, communication, and coding skills.
Third, working on a design system requires covering a lot of ground, but that is simply an opportunity to work with a wide range of talented peers.
The connections you are forced to make will boost your morale. The solutions that you build will bless a wide range of people, providing an objective value to your work that will certainly result in an increase in your energy and motivation.
Finally, you are not alone. As of today, there countless developers who are trying to solve similar problems. There are modern technologies that make building tooling around a design system easier and more engaging than ever.
One of those countless developers trying to solve a similar problem is me. He also gets nervousness mixed in with the excitement when thinking about design systems.
The mission of my book, therefore, will be to walk with you as a fellow nervous developer, growing our ability to solve the problems surrounding design systems.
By the end of it, we will know how to solve the imaginary project that ZapShoes has assigned to us. In other words, youll be able to develop tools for a robust design system all by yourself.
2 - The Problem
There are several difficulties in trying to develop tools for a design system.
First, the design system has to scale as more and more applications are added within a company.
Second, the design system has to be consumable across various types of platforms (i.e. web, mobile, desktop) as well as specific technologies for those platforms (i.e. React, Vue, Angular).
Third, the design system has to be flexible to handle updates by the designers.
Similarly, and finally, the design system as implemented by consuming applications has to be high fidelity. Meaning, it has to be pure, or faithful, to the official specifications.
Lets talk briefly about some real-life scenarios where these pitfalls are encountered.
The first couple of difficulties are usually encountered together. Imagine that your company, ZapShoes, only consisted of an e-commerce site built with React. To accomplish the project we outlined in the previous chapter, you decided to build a UI component library written in React. That way, you can encapsulate all the design specifications within sharable components.
Now, that only works as long as ZapShoes only consists of a React app. However, another team is spun up to create a customer support app. They decide to build this with Vue (despite your best efforts to persuade them otherwise).
Because of this, you can no longer apply the styles from the design system by consuming a shared UI component library. The React app will need a UI component library that works with React, and the Vue app will need a UI component library that works with Vue. The design specifications are then encapsulated in a shared CSS-in-JS library. This is used to get the design specifications for the UI components in both the React and Vue UI component libraries.
That works as long as all the applications at ZapShoes are built with modern web frameworks. However, theres been a push to go back to the basics with a marketing landing page thats built with plain HTML and CSS. Now, the design specifications need to be encapsulated into a CSS file as that is the only common way to share styles across all three applications in the company.
This stinks because you either need to build some tools to port the CSS to the CSS-in-JS library, or you continue to use plain CSS which doesnt give you the power of CSS-in-JS which you prefer.
You can imagine how this problem can spiral downwards if a mobile application built with Java was announced.
The last couple of difficulties manifest themselves when things do spiral downwards as in the example I just provided. Imagine that because of the sticky situation to either use plain CSS or make a tool to port CSS to a CSS-in-JS library, you decide to have the design specifications encapsulated in the CSS file and a JavaScript file referenced in the CSS-in-JS library.