Differentiate Design Systems incl. code-snippets from repositories

Question

I'm currently doing some research on design systems (hereafter DS) because we want build one.

Context

Requirements for a DS

• guides our designers when building something that needs to conform to our standards
• have a place where our developers can actually find components, so they can just copy + paste the code; at least for the more common ones like filters and tables.

Observation of imports in code

While there are many examples out there, built on a wide range of platforms, the ones with code gave me some confusion.

While I'm not a developer, I noticed that a lot of the DSs that contain code (usually tagged as 'react' or 'vue.js') show a code that starts with a "import this" and "import that".

Example: IBM's Carbon Design System has a checkbox component

Question(s)

What is the dependency between DS including its code and the finally to designed solution?

In detail:

1. Does that mean that the dedigned solutions built with code that was copied from that page are actually importing information from the DS? So that these designed solutions will depend on the DS to work?

Otherwise:

2. Is that code all, or nearly all, that would be necessary for a developer to actually implement it in a page; or are just snippets that serve only a "live demo" purpose?

I would also appreciate links to DSs that manage to have this "just copy and paste the code and you're good" approach, if that is even a thing.

Answer 1

The newest release of Figma comes with access to Figma APIs.

With the API the Designer can generate visual assets then appearing in Figma the app, and at the same time, the same code can be used to instruct the developer of what the component is supposed to look like.

It is a step closer to have a single source of truth shared between the visual UI and the source-code used to compile the HTML/CSS/JS.
Unfortunately, though, it comes with its own drawbacks. One of the major ones is that it needs the developers to refactor their code so that it can interact with Figma's APIs. It is not a major problem, but I can see it as a downside in companies with a huge codebase full of multiple components.

So, to answer your question: right now there is not such a technology that will allow designers and developer to work on the same "objects" that compiles both visually and code-wise.

I am looking for this tool/technology myself too, and I would love to hear anyone else's solution.

Answer 2

TLDR; No. Even the context (language or language-specific platform) can be used interchangably, codes mentioned here generally tend to be maintained on GitHub or npm for Javascript (so again it can be linked to a repository on GitHub or on some other platform).

Clarification:

First, clarifying the name of these scopes you mentioned above like, design system and Javascript framework will be more appropriate. Even there is nothing stated with 'import ...' with the link you provided, you probably meant the imports alongside with this link (Please warn me to edit my answer if it's not the case).

Explanation:

Well import is widely used in many programming languages (even sometimes in an alternative form), here with the link, it's both used in css pre-processor and for frameworks like React and Vue as well. So that yes, they're mainly used within files related to that specific code platform to be included in programming context.

And for your consequent questions, these import statements preferably used on that specific part of the project page, like component mentality as almost the same with design systems. For more appropriate words, it allows users to import whatever part of this library or design system instead of copying all of these features of that specific content within the imported file scope.

Extra Info:

Also as you mentioned with your question, it's not something necessarily displayed on that page for live demo purposes. Basically apart from the webpage it's displayed, for Javascript packages i.e., the library stays on npm and when it's imported, it directly comes from another source (that's the code repository). So that even you copy this statement from the displayed webpage, there's no direct connection between these sources and the user should install these libraries as well beforehand in order to successfully importing these libraries.

Lastly, there's a good usage of both the design and code displanation within the same place with Vuetify library, works like a plugin to Vue framework you mentioned. Hope the answer helps and please don't hesitate to edit your question to let me edit mine, or comment as wishing me to explain more.

Note:

The Javascript frameworks you mentioned above (namely React and Vue), are not design systems but more of that, they're the technological background for these design systems are used on. But the repositories like Vuetify or more popularly Bootstrap, are a kind of tools including the features like letting their users to shape their application via code, so that can be understood more close to the design system in this context. Hovewer, besides having also more capability then design systems, seperately they can be used to designing an interface with lots of ready-to-use components, giving proper functionality with a shorter code to be executed by users, or even letting their users to be able to work with test frameworks within these libraries' components or functionalities.

Answer 3

Interesting question, here are a few key points on the topic.

Does that mean that the solutions built with code that was copied from that page are actually importing information from the design system (which means that they will depend on it to work)?

Yes and no. Typically code examples in design systems are illustrative but can be copied and pasted if the requisite dependencies exist in the project you're working on. So if your project is already setup in that way, it's possible that copy/pasting can work.

Additionally, when you say "importing information from the design system" this is a nuanced point. As above, if your system is already implemented in code, for example the colour palettes and sizing scales already exist, then a component which sets a property to color="primary" (or similar) is using part of the system. I emphasise using, because it's important to differentiate between using and importing. Let me expand, depending on where your design system is situated (the tool and medium for example) the process of making a change in the system and having it reflected in code will differ. Let me give two examples.

1. If you manage your design system in say, figma/sketch/something which isn't code based and that is the source of truth, there will be a process to get the design tokens into code. (Figma does offer APIs and there are ways to automate the process of creating and naming tokens in Figma, calling the APIs during a build process and perhaps using something like https://amzn.github.io/style-dictionary/#/ to create assets that can be used in code.) That said, typically the process of translating the design system into code is normally manual. Even if you can automate the design tokens, you'd still likely need to create components in code and have those updated by hand when changes happen (like adding something new).

2. If you manage your design system in code, using something like https://storybook.js.org/ and that is the source of truth, then when you make a change in some way, the code is written as part of the change and would automatically be made available to the consuming components/developers.

We want to have a DS that not only guides our designers when building something that needs to conform to our standards, but we also want to have a place in which our devs can actually find the code for those components, so they can just copy + paste it; at least for the more common ones like filters and tables.

This is a sensible goal, but I would probably remember that a design system is, after all, documentation and this needs to be both adopted & maintained. The further away from the code, it exists the less likely it is to be adopted and the maintenance burden will become huge if the steps to make updates are too laborious.

It really depends on how you set things up and how you want to maintain things over time. There is no one solution to this problem and you'll need to find what works for you and your team.

As a general point though, consider what the purpose of your design system. How much actual time are you saving through copying and pasting from a documentation site? vs just having the component in the codebase and agreeing as a team when and how to use it? Speak to your developers, find out what's costing them time and effort, remove those blockers where you can. Communicate what you want to do and how it will help them, give them the challenge of finding the tools and processes that will work for them and then discuss and compromise to find something which works all round.

You can create a system that is immediately available in code, but there will likely still be a step where designers need to communicate changes to "someone" who can update the system in code. Strive to make this process quick and simple.

You will likely struggle to gain adoption if your processes are cumbersome and the teams on both sides keep butting up against each other. So focus on that side of things first. Then build things from there.