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


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


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?


  1. 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.

  • Your linked example actually takes to the home page of the Carbon DS. Would you like to link to a more specific example?
    – Adriano
    Commented Mar 11, 2021 at 0:23
  • Oh, sure. I was referring to all components in general, but this one would be an example: carbondesignsystem.com/components/checkbox/usage#live-demo Commented Mar 11, 2021 at 13:11
  • Interesting question! I tried to add a clear outline and suggested an edit. Feel free to accept or adjust in case I rephrased too much from intended sense😉
    – hc_dev
    Commented Mar 11, 2021 at 22:39
  • Thanks a lot, I approved it 👍 Commented Mar 12, 2021 at 10:53

3 Answers 3


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.

  • I'm not really referring to the possibility of generating actual code through our design softwares (I looked into that as well, and no software seems capable of producing actual usable code, despite many claims). My question is about the direct relation between the code that is available on the DS examples I mentioned, and the actual products that eventually get built with them. For example, if that carbon DS goes down completely, are the products designed with it affected at all? Commented Mar 11, 2021 at 13:16

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).


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).


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.


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.

  • Ok, thanks for the answer, I think I got most of it. "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" So the DS is not the actual repository for the code; meaning that if it goes down, nothing will happen to any of the solutions that used the code examples it provides, yes? On that note, is the idea of a DS with the actual full code for a component something that makes technical sense? Commented Mar 11, 2021 at 13:23
  • Well that may depends. For instance, if the DS is deprecated so that the code maintainers decide to fold the repository as well, everybody in this case which imports this remote repository will be affected too. But again there's no direct connection between the website's itself with this repo (so that DS). And for your last question yes, it's mainly for frontend developer's part but it shows distinctively the foundations of it revealing in a technically more specific way. Commented Mar 11, 2021 at 14:32

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.

  • Thanks for your answer 👍 We actually had a go with using Storybook, but it was something from before I was in the company that apparently didn't take off. I actually abandoned any notions of outputting usable code from the design tool; So for now I want something that can be used as a source for both designers and devs, but not to the product itself; so if that DS ever gets moved or goes down, nothing happens to the sites and tools that were built based on it. Commented Mar 11, 2021 at 13:42
  • Yeah you definitely wouldn't want your product linked directly to the DS as it wouldn't give you sensible way to control versions (or make updates) without them instantly being reflected so testing would be impossible. This point is for me, why I consider it sensible to separate the DS into a dependency of the product (in a code sense) so that you can asynchronously develop the DS and publish updates without the product changing. Only when you want the product to change would you update the version of the DS in the product to bring in and test the changes. Commented Mar 11, 2021 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.