April 11th, 2024, posted in learning
by Adelina
We’ve talked about UI Kits a number of times. Collections of colors, buttons, dropdowns, inputs and so on. But what about its higher-level counterpart, design systems? These take the idea of a UI Kit much further by outlining an entire design language that not only covers one app, but potentially an entire suite of apps.
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).
So, what sets apart a design system from a regular UI Kit? Design systems bring in code guidelines and can also be considered a part of a company’s branding. UI Kits are smaller bundles of elements, while a design system is almost like a visual language that represents a brand. Most examples of design systems you’ll find belong to major companies who own complex apps or even app suites.
If you want to get a better understanding of UI Kits and truly see what the difference is, we wrote an entire series about our experience in building our own original UI Kit. Find out how we planned it and what kind of elements we chose to add to it, here.
What goes into a design system?
First off, since a design system belongs to a company or brand, it’s going to be adjusted to what that brand needs. Just making a design system for the sake of having something pretty is inefficient. To really determine what you need in your own design system, you have to take a good look at what you have and take into account what you plan to add to it all.
Each design system, of course, should contain several basics no matter what. A great way to understand how this works is by looking into Atomic Design, a concept created by Brad Frost. Put simply, this concept talks about dividing elements in a UI Kit or a design system in a gradual, logical way, inspired by chemistry.
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.
Source: Brad Frost
Thus, Atomic Design proposes you start off with the very foundation of your design system, those elements which will be put together to create proper elements, which, in turn, will compose entire pages. Those will be your atoms.
Atoms
Atoms will be the building blocks of a design system. These are base elements that a design system requires to survive. Elements that you’ll see everywhere and which will be reused multiple times, in different places, or put together to form bigger elements.
The most basic and essential atom in a design system is the 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. If your main brand colors are blue and white, those will also be the main colors used in your software products.
Color palettes work similarly in both UI Kits and design systems. These will include a primary color, the main color which represents your branding, 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.
Another essential item is typography. 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. Doing so ensures consistency throughout your apps and visual branding. The key here is picking one font and sticking to it. Alternatively, if you have a presentation website, you can pick a second font for big text - a serif & sans serif combo is often used and always looks good.
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. After all, what you’re trying to do here is keeping designs and code consistent, especially with each other.
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 can create a form. Or bits of text, some input fields and a button can form a modal.
In other words, molecules are your individual items, which can have a variety of states. Because this will all be turned into code, and we’re looking to stay consistent, design systems have to include all of those states as well. 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 come up with something themselves, and when you get back to the design, it won’t be easy to keep all of them consistent. It’s not about making the developers’ lives easier, but it’s about keeping a consistent visual language.
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.
Examples of organisms. Source: Brad Frost
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.
Similar to molecules, organisms can vary on different screen sizes. The best example here is an app’s navigation: if on desktop you can place it at the top, on mobile doing that might be too clunky. Picture that big CNN menu from the photo above on an iPhone screen. It won’t fit, right? Which is why nav bars are usually moved into a clickable icon, which will open it as a side menu. Thus, design systems usually include variations of these elements that don’t look the same on both desktop and mobile. For the sake of efficiency and consistency, of course.
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.
Similar to the last 2 elements, templates should be adapted to multiple screen sizes as well. This would help reduce headaches for the development team, who otherwise would have to resize or replace items on their own accord, and trust me, your designers don’t want that.
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. Otherwise we go back to that same problem - the developers will be tasked with taking UI/UX in their own hands, which creates discrepancies between the code and the design, or they leave these as they are and the QA team will consider them bugs.
Thus, getting to this stage lets you test your design system and find what’s missing in terms of element states. The key here is figuring out how many different actions and how many results to them can happen within a single page.
What kind of software products need design systems?
The main goal of having a design system is to make it more efficient to build new features for an existing app, or a new app within one umbrella of apps, belonging to the same company or brand. Thus, design systems are best made for apps that are in continuous development, which keep getting new features or new modules.
In other words, a bigger company/enterprise who has an entire suite of apps, or a single app that started off as an MVP and which is still in development. If you want to keep adding new things to your app, you might have to consider investing in a design system. Or you can look at it this way: do you have one or more UI/UX designers on your team and they get plenty of work? Then you might need a design system.
So, do you need a design system if you’re not adding new features to your app any time soon? No, at least not right now. If you plan on adding new features in 1 or 2 years, you can start thinking about it, or start small with a UI Kit.
Another good contender for a design system is an app suite with an outdated design which you’re looking to improve. A redesign is a great opportunity for design system building, since you’re already making new components and rewriting code. Even better if you’re redoing base items like color palettes and typography. This, on top of having a complex app that’s in continuous development, is a great reason to invest in a design system.
Here’s a design system planning template that can help you determine what state you’re in and what it would mean to begin building a design system. This is a great way to organize information and start an internal conversation about your long term design and development needs.
Do I need a design system?
We can answer this question pretty easily. Does your app match the description we previously made? Or are you just starting to build an app and you want to keep adding to it for the foreseeable future? If so, then yes, you need one. Can you live without it, though? Definitely. Would its absence make things slightly difficult for your designers and developers? Yes.
When deciding whether or not you want to build a design system for your app suite/brand/company, you need to take multiple points into consideration. There’s no questioning whether it would be useful or not - anything that makes continuous development smoother is worth it. Streamlining your designs and code will save a lot of time and troubles and will make for a better user experience, which means better conversions and customer satisfaction.
But design systems are not a quick or easy feat. It can take up to several months to create one from scratch - that, when all you have is some visual branding guidelines and no app designs. Which means having a big enough budget and a qualified enough design and development team. While making this decision, you need to take a look inside and figure out if your team can handle this. In other words, if you can pay now for several months of design work, to save on design work in the future when you add new features or build new apps under the same umbrella.
It won’t be expensive in all situations, however. If you have a few design files for your app already, you’ve got a starting point: most design elements have been mapped out already, there’s already a set of colors and some typography rules, and there’s a general direction for that design. But how well these are mapped out will determine how long it’ll take to build a design system. And how can you figure that out? Let a senior UI/UX designer take a look and estimate how long it would take them to build a design system based on your existing files.
In case you have some design files already, but they were made years ago and not by a senior designer, there’s a possibility that they weren’t built too efficiently. In other words, when passed onto a more experienced designer, they’d be difficult to work with and add new functionality to. In that case, it would be very helpful to build a design system based on those initial files and thus unify your current design language. If your app isn’t that big, you can stick to a UI Kit.
But here’s a caveat to all of this - spending a lot of time and money on a design system means it would be inefficient to rebrand your apps in a year or two. If you do a major rebranding, that could render your design system obsolete, which means you’d need a new one, which means spending all that time and money again.
Having a design system means consolidating your company’s visual language, and languages usually have a small evolution throughout the years, but they wouldn’t go from slavic to romantic within 2 years. In conclusion, you should be satisfied with the look and feel of your apps before you head into creating a design system. Otherwise it would be similar to adding extra floors to a really old building that has major structural issues.
There’s also another point to consider. Let’s say you already have one or two apps and you’re not entirely happy with what they look like. You’re looking to redesign these apps and maybe refresh your company’s branding as well. If you’re sure you’ll add to these apps in the next few years, it’s a good idea to build a design system for it. This will be especially helpful for the developers who will have to implement the new look on top of your existing features.
And lastly, you need to think about your existing design team. The people who know the ins and outs of your design best. Ask them one thing: if they leave your company and someone else will be in charge of your app’s design, would they have trouble navigating the current design? If their answer is anything other than a clear “no”, then you need a design system. Or at least a UI Kit.
And this begs the question: do you need an entire design system or just a UI Kit? If you’ll keep building onto your app for years to come, the answer is simple: a design system. If you’ll be done developing your app in the next 6 months and the only work you’ll be doing on it is bug fixing and maintenance, then a UI Kit is enough.
In conclusion, considering how complex a design system can be, you need to really understand what it means and how it could help you before you decide if you need one. This means taking a good look at your future business plans and involving senior designers into your decision making process.
And there you have it, we’ve talked about what a design system is, what it’s made out of, who it suits best and how to figure out if you need one. After all, it all comes down to the size of your business and apps, which you’ll know best. But don’t be afraid to consult with your designers and developers when making your decision. They work with all these items, they get first-hand experience, thus they will know best.
Thinking about getting your own design system or improving the look and feel of your app? Contact us and let’s see what we can do together.
Not ready for a design system yet, but you would still like to get a sense of the work you will need to put in? We provide a free UI/UX assessment, no strings attached.
You book a free consultation call and we evaluate your application against core UI/UX best practices. You then get an overall usability score for your product and actionable improvement recommendations for 3-4 complex screens (screens packing a lot of functionality). Read more about how you can get $3k worth of expert UI/UX advice for free by clicking on the banner.
