Design System Advantages

While working as a developer at Gap Inc. I initiated and led the first design system which was used in their point of sale system.

I learned a lot about the advantages of having a design system and recommend it for these reasons:

• consistency design
• less code by reusing by using reusable components
• consistency in code
• faster development (copy-and-paste to get component look)
• separation of coding design and coding implementation
• easier maintenance and design updates

The team I worked on consisted of mainly back-end developers who weren’t comfortable with css. By creating components, and having documentation that showed you what a component looked side-by-side with its code, it became very easy for developers to scroll through the published design system. They would find what they needed and just copy-and-paste the code. Css and styles were no longer a focus. They code focus on their strengths which was hooking up code logic.

This drastically reduced the amount of css we had. Prior to this every developer who needed a blue button coded it in their own way. The buttons never looked exactly the same. Different heights, widths, fonts, different blues were just an example of design and code inconsistencies.

Also when design wanted to change the blue used in our buttons, it only needed to be done in one place. The buttons would just inherit the change making it easier to maintain and update. Also if you tested the behavior of a button once and it worked across all your devices, you knew the tested behavior worked across all the buttons.

Another great thing about design systems, was that designers had to think through the use cases and the components they designed more. They became consolidated components so they could handle more use cases. By having less components and more consistency the user experience also became simpler.

A great video on design systems and advantages: here

When I worked at the Gap we were using Angular, and I was able to use comments in our scss to create a design system that got published to github pages. I used hologram as a tool that parsed through my scss. What was nice about this was that my documentation for my design system lived together with my code, so it was very easy to keep my documentation up-to-date with my code.

If everything in your app is in your design system, then at the end of the day, you shouldn’t have to write any custom css. If you just copy-and-paste your components, they will fall into the appropriate places. However, to start you can just aim to make your base components, the things you reuse over and over everywhere such as buttons a starting point.

Today, I’m at Creator Inc. working with a react code base and using storybook to create my design system. I loved this video React Storybook Tutorial with Examples — Getting Started with React Storybook posted by Fullstack Academy given by Gabrielle Sin. It goes over a lot of the advantages I spoke about and more.

There’s lots of examples of storybook design systems here.

Note: storybook is compatible with non react code bases

Quick Steps to Getting Design Systems

1. DESIGN

• 1.1 Get designs
• 1.2 Work with design and break things down to components, try and minimize the number of components, simplify and merge things that have similar functionality

2. CODING THE DESIGN SYSTEM

• 2.1 Choose a platform for you design system (ex: storybook, hologram…)
• 2.2 Code your constants/theme: colors, fonts, sizes…
• 2.3 Build your most basic components (ex: buttons, toggles, inputs) and add them to the design system
• 2.4 Build out the components that inherit other components (ex: form: which includes the button and input components) and add them to the design system

3. USING IT IN YOUR CODE

• 3.1 import your components into your project and start implementing logic

Once you’ve started coding out some basic components you can start using them in your code base right away.

Design System to Production Work Flow: What We Did in Reality

• Design for the project were already made
• The Product Management team wants FEATURE A out for the next iteration (JIRA tickets get made in the backlog)
• We inform the design team that FEATURE A is coming up in the production pipeline
• Designers start to review designs related to FEATURE A and make last minute changes (link final design specs to the JIRA tickets)
• Iteration starts: components get coded in the design system code base
• Designers check components once it’s coded (refine any unknown issues, and update code)
• Component gets imported to project code base, hooked up, and tested

A common work flow was that once we knew product management wanted a certain feature in the next few weeks, we would inform the design team.

Usually a design had been already done, but when they knew it was going to be in production soon, designers would re-review the designs in more detail and go over all edge cases. Usually there were last minute changes or new information or just visual changes they wanted.

Communicating to design early on, gave them enough time to finalize the designs, then the engineer would code the components out in the design system, review them with the designers, and the last step was to import them and hook up functionality in the project code base.

This work flow kept designers and engineers happy, because designers got the designs they wanted, and engineers rarely re-coded designs.

If any changes were made, it was done in one place, in the design system, and it just cascaded down. So long as the interface to the component didn’t change, the project code base didn’t need to change, it would just need to upload the latest design system code and it would just work. We created an npm package our of our design system. This made it was easy to import and update to the latest version.