UI Kits vs. design systems. Which one you need and why.

There are lots of terms you hear about often in software development and UI/UX design. Agile, SCRUM, components, libraries. But two UI/UX terms tend to be confused a lot: UI kits and design systems.

So much so, that non-technical people involved in software projects might not know they’re two different things. You could be asking for an UI kit when it’s not what your project actually needs.

UI kits help you get started, whereas design systems help you continue on with a particular design language and components. 

They might seem like the same thing, but telling them apart can be very useful when working on a big software project - you might need one of them, but you can’t know for sure if you can’t set them apart.

So in this article, we’re going to explain what UI kits and design systems are, and we’ll help you set them apart & understand why they’re different.

What is a design system?

Design systems and their central concept are easier to understand if you look at them this way: a major brand like, say, Google, has an entire suite of applications. All of which follow a central design system called Material Design. This maps out how all of their products look and feel, providing both visual and code guidelines.

A design system can contain (but are not limited to): style guides for colors, typography, icons, shapes, shadows, visual effects, page elements and components such as headers, buttons, cards, menus, form elements, tooltips and more, and code guidelines to bring all of these to life (example here).

A design system’s role is to help designers and developers keep apps consistent with a company’s branding or existing software. Once they add new features, they can use the design system to build them faster & in a way that makes those features fit into the software overall.

And a great way to understand how design systems work and what they contain is to look into Atomic Design, a concept created by Brad Frost. The basis of Atomic Design is that all matter is composed of atoms, atoms form molecules, which together form organisms. And through this logic, you can create a design system from the ground up, in such a way that every element connects smoothly in the end.

Here is what you’d include in a design system, based on the Atomic Design concept.

Atoms

Atoms will be the building blocks of a design system. These are base elements that a design system requires to survive, which you’ll see everywhere and which will be reused multiple times, in different places, or put together to form bigger elements.

Atoms you’d include in a design system are:

• A color palette. Colors are a major part of a company’s branding, and if you want your software products to be consistent, it’s best you stick to a specific color palette that matches that branding. You’ll need a primary color, which will show up the most across your app, a secondary color which can be used as a highlight, and a neutral color for text, borders, lines and other similar elements. Alongside those, design systems can also include shades of green and red for alerts/notifications, catered to the primary color so they go well together.
• Typography rules. In a design system, it’s crucial to outline what big display text, headings of different sizes, or body copy are going to look like. This section will come in the form of a scale, with text styles from biggest to smallest, adapted to standard code rules. Frontend frameworks such as Tailwind provide ready-made typography scales, and to stick to the whole point of a design system, it’s best you use those in both designs and code.
• Grid and layout rules. Your app’s pages will also need blueprints on how you usually place elements. Does your sidebar stay open all the time? How wide is it? How many content containers do you put in a page and what size are they? What kind of sizing and padding scale do you want to use? All of these are important guidelines designers will need to keep building on top of your app.

Colors and typography will come together to form a variety of elements that are also considered atoms. Like an input field or a button. These don’t do much on their own, but can be turned into essential parts of a bigger element.

Molecules

This is where the atoms come together to form actionable elements. For instance, the input field and the button can form a search bar. Or several inputs together, checkboxes and radio buttons can create a form. Text, an image and a button can compose a content card.

In other words, molecules are your individual items, which can have a variety of states. For instance, an input field can be unfilled, filled, active (selected) or disabled. A design system should include all of these variations, otherwise developers will have to design those themselves. And that can affect your UI’s consistency.

Aside from states, molecules can vary on different screen sizes as well. A dropdown of filters can become a separate screen on mobile, tables will need to extend and be scrollable to the right, and modals will need to be more compact to fit smaller screens as well. In other words, you’ll need to take these variations into account and include them in your design system.

Organisms

This is where molecules come together to make up groups of items. These will become entire sections of a web page, such as a header or side panel. Standardizing these sections will help save time and they’ll keep your pages consistent. 

Another example of an organism, says Brad Frost, is a product grid (which would be used in online stores): this is composed of a repeating molecule (product cards) which, themselves, are composed of atoms (titles, images, tags, and so on). These elements should stay consistent across a brand’s app suites, especially card elements overall. This can be accomplished by keeping padding rules, border radius, strokes and shadows consistent.

Templates

A good analogy for Brad Frost’s idea here is that templates are essentially wireframes. These screens are composed out of the organisms you’ve created and they give off a more accurate representation of an app’s screens. But they’re not high fidelity designs.

In this situation, inputs would contain example text, all text portions would contain placeholders (your standard lorem ipsum), images would be placeholders and icons might not 100% represent what they signify. Templates, thus, are just a skeleton of a page.

Pages

This is where the templates come to life to form the final designs. Placeholder items are replaced with real elements, such as real and final copy, images, and accurate icons and input fields. Putting all the atoms, molecules, organisms and templates together into pages, says Brad Frost, helps you test the design system and ensure that they fit in together. If they don’t, you can always go back and update them.

In addition, pages are a great way to figure out how many variations your elements can have, says Brad Frost. You might keep a certain number of characters on text portions just for the design to look pretty, but in reality these sections can contain more text - thus, the design system would require an example of what that would look like.

What is a UI Kit?

UI kits are like puzzle pieces you can use to design and/or build a piece of software. Compared to design systems which help you build onto existing software while staying consistent, UI kits help you build software faster by giving you a foundation, a blueprint to use to build it.

UI kits will provide a series of common software components and often include their coded counterparts: the whole point of these is to help you speed up the app development process, which is why the puzzle (or Lego) analogy is so fitting.

Example of a small UI kit we made for a project.

UI kits might include (but are not limited to):

• Branding elements such as colors, typography, icons, 
• Guidelines for grids and layouts
• Alerts
• Buttons of all kinds
• Cards and carousels
• Charts
• Form elements (input fields, toggles, dropdowns, checkboxes, radio buttons)
• Navigation
• Pagination
• Progress bars
• Range sliders
• Tables
• Tooltips, tabs, tags
• Uploaders

Most UI kits include a variety of states for each component. This helps developers code faster, as they know what a hover, disabled or active state would look like for each element. In Figma, these are set as variants and they help designers switch from a component version to another without spending time looking it up.

If you want to have a better understanding of how UI kits work, we documented our experience building our own UI kit. This series can help you get a better insight into what goes into a UI kit.

Some UI kits also provide ready-made pages using their own components. These can be dashboards, CRUD pages, landing pages, marketing pages, and so on. This is a great way to get you started. You can take them as is and input your own data.

But the big caveat to UI kits is that they’re not customized to your branding, but are more like themes you can apply to your software. You don’t get to decide its look & feel like you would with a design system. Whoever made the UI kit decides what it looks like.

What you can do here is take the time to find a UI kit that matches your branding or which you personally like. One thing to consider is that using themed items to build software means you won’t be so original in terms of aesthetics.

You can, however, customize UI kits to your liking:

• You can change color styles to match your branding, and if the UI kit is made properly in Figma, the new color styles will automatically apply to existing components.
• You can change the font used in the UI kit’s typography styles. Same as colors, it should apply to all components.
• You can adapt the pages you build to your desired layouts, while the UI kit components are just puzzle pieces you use across the app.

And so, even if the UI kit you decide to use doesn’t match your branding, you can still make adjustments to make it your own. But it never really is, is it?

And that gets us to our next section.

Design system vs UI Kit, which one do you need?

The quickest and simplest answer to this is: use a design system for major, enterprise projects or app suites. Use UI kits for smaller projects that you won’t build much upon, and which you need to release quickly.

Let’s go more in depth.

Here’s what design systems are good for:

• Big software development projects you’ll for sure keep building upon. Design systems help you build up your software visual branding and thus they make it easier to add new features as you grow your business.
• App suites. If you want to build an entire suite of apps, under the same kind of branding, a design system will help you stay consistent and will be very useful for designers and developers.
• Projects that need to match your branding. UI kits are downloadable items made by other people, so chances are they won’t match your branding. Design systems are made by your own team so they match your desired branding.
• Major projects you have plenty of time and money for. Design systems are made from scratch by your design team, so it’s not something you just download. They require time, and thus money. If you’re planning to build a big software development project, it’s good practice to invest time and effort into building a design system from the get go.
• Existing projects that got a bit chaotic. You might find yourself needing a design system halfway through. Your app is launched, but there are clear UI inconsistencies. You’ve hired different designers or migrated from a design app to another. To make sure you’re keeping your app’s UI consistent as you keep adding new features, you might need to create a design system. It’ll take a while, but you’ll reap the benefits soon after.

And so, design systems are generally good for bigger projects that need to look consistent. They’re a great way to avoid visual chaos and to keep your app’s UI in order.

Here’s what UI kits are good for:

• Projects you don’t need your own branding on. If you don’t care much about keeping your brand colors or typography, you might benefit from UI kits.
• Projects that don’t need much customization. UI kits can be customized, but there’s only so much you can do when you’re already in a pinch. The big benefit to UI kits is being able to take them as is and just use the components.
• Projects you need to finish quickly. If you’re in a time crunch, UI kits are a great way to quickly build a few pages to show investors. Make sure you get one that comes with coded elements as well.
• Teams that lack a senior UI/UX designer. If you only have a junior designer or a team member who only dabbled in design, UI kits might help them move faster as all key elements have been built already. Design systems are built from scratch, so you need someone more experienced for that.
• MVPs. If you’re just launching a small project, a design system is way too much effort.

Thus, UI kits are better suited for smaller projects, tighter deadlines and smaller teams. They’re also extra useful if they contain coded elements - otherwise you’re only speeding up your design process.

So overall, both UI kits and design systems are very useful and they help you build features faster while looking visually consistent. But what sets them apart is your project and team size. A design system is way too much effort for small projects you don’t build much upon. But if you’re planning to build a bigger piece of software or even an app suite, a design system can help guide you and stay consistent.

Looking for your own design system or an entire piece of software? Contact us and let’s build awesome apps together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.