App design and development is a lengthy process, which means there’s more time for things to go wrong. But what if you had a system in place that ensured your app was built the right way from the get-go, regardless of which team member (new or old) was working on it? That’s what design systems do.
App design and development is often a lengthy and complex process. Even when you have a fully formed product ready for release, the work still isn’t done. You always need to be iterating, trying to create a better version of the app than the previous one.
But the longer you work on an app, and the more people that get involved, the more complicated the whole thing becomes and it can be really difficult to manage something like that. Different teams. New product iterations. Changing goals.
Without having a strict set of rules and guidelines to work from, your app project is at risk for delays, inconsistencies, errors, and more. But that’s what we have design systems for.
What Is a Design System?
Think of a design system like a toolkit for your app. Typically, it’s a central resource that lays out the following guidelines for a design project:
- Foundational elements
- UI patterns
- Design principles and guidelines
Google has built one of the most well-known design systems, Material Design:
Although this design system was originally created to provide guidance on how to design Google products and, more specifically, their UIs, the open-source toolkit eventually became something that any designer or developer could adapt for their own purposes.
Let’s take a closer look at how you should go about piecing your design system together.
How Do You Create a Design System?
Here’s what you need to know about the five key parts of your design system:
1. Assign Ownership
When creating a design system, you need it to be the go-to resource for your app team. And although the primary focus is on the UI, ownership needs to go beyond the designer. You need buy-in and support from other teams.
The number of owners of your design system depends on the size of your team as well as the size of your project.
For example, let’s say you’re building a design system for a small mobile app that’s slated to take four months to build. The lead designer and frontend developer on the job might pull double-duty as the makers of the app as well as the managers of the design system.
On the other hand, let’s say you’re working on an enterprise web app that will take about nine months to build and then you’re responsible for ongoing support. Something that massive would best be handled by a cross-disciplinary team consisting of:
- UI designer
- UX designer
- Frontend developer
- Backend developer
- Content strategist
- Project manager
There are other key stakeholders you might want to get involved. Just be careful about having too many cooks in the kitchen. The more people who have input on the design system and control over editing it, the more likely you are to run into a conflict that holds things up.
2. Set Up Your Design System and Toolbox
Once the matter of who owns the design system is settled, it’s time for you to create it.
Because this needs to be a living resource, you can’t just create a static style guide and call it a day. Consider creating your design system on a microsite, similar to how the big tech companies handle it.
While you won’t have to make yours public like Microsoft’s Fluent design system, it’s a good idea to save it in a place where it’s easy for your team to access it and see changes in real time:
By creating an easily accessible design system, team members will automatically have the latest and greatest guidelines to work from. This, in turn, will save you time having to message your team to let them know when there’s a new update to the system.
It also will make rolling back updates much easier, as all you’ll have to do is revert to a previous version. No time will be lost or confusion created by trying to get an outdated system out of circulation. What you see is what you get.
Don’t Forget About Your Tools
Because designers and developers speak different “languages,” they generally work with different platforms. This disconnect can cause problems when it comes time for collaboration or handoff.
I’d recommend reading this post on the 8 things you can do to strengthen design-development collaboration. You’ll see how choosing the right set of tools can unite your team, streamline your projects, and improve your outcomes.
Specifically, there are three tools your team should be using to seamlessly connect your design system to your existing workflows:
Unite UX is the collaboration platform that makes design handoffs to development a breeze. It also enables you to save your Kendo UI patterns to Sketch.
3. Define Your UI Styles
To create a truly secure design system around your app, you have to first define the foundational UI styles for it.
IBM’s design system, called Design Language, primarily focuses on this piece:
I’d say that, when building apps, you want to start by defining the following:
- Logos
- Colors
- Typography (including font families, spacing guidelines, sizing rules)
- Iconography
- Photography and/or illustration
- Interaction/animation
- Interaction/gestures
- Interaction/sounds
- Alerts and push notifications
- Layout
Make sure that you take the time to really drill down deep into each of the elements. For instance:
There should be absolutely no mystery about what to use, how to use it, and when.
4. Create Your UI Patterns
With your foundation laid down, you can start piecing together the patterns you’ll be using and reusing around your app. For this, I’d like to turn your attention to Brad Frost’s Atomic Design Methodology.
With this methodology, you’ll be able to develop your UI patterns with a more methodical and logical approach. Here’s how it works:
Atoms
Frost compares HTML elements to atoms:
HTML elements are the smallest building blocks of your app. In the example above, you can see how three of them (label, input, and button) might be designed individually.
Molecules
On their own, atoms don’t provide much substance. However, they become meaningful once you begin to group them together like molecules:
In Frost’s example, you can see how the three earlier “atoms” have merged to form a common UI element: a search form.
Organisms
Just as atoms come together to form meaningful units, molecules come together to form more complex structures. Frost refers to these as organisms:
Now, just because this example is of a website header, that doesn’t mean that every organism in your app will be a single block that’s comprised of a few components. Organisms on our planet range in size and complexity, so the same goes for your product’s “organisms.” They could be as small as a navigation bar or as large as an entire page.
A Note About UI Patterns
When creating your UI patterns and templates, keep in mind that it needs to be easy for anyone working in your design platforms to retrieve the patterns they need. This means that, in addition to designing your patterns, you also need to organize them in a way that makes sense for everyone and using a naming convention they’ll all understand.
So, keep it simple.
I’d recommend using organization labels like Apple uses in its Human Interface Guidelines (design systems):
Everything is simply named and easy to find. As you go deeper, don’t overcomplicate the naming of your patterns. Use sub-categories to define them. For example, this is a Kendo UI library imported into Sketch:
You can see in the example of “Navigation Sidebar” that the sub-labels are clearly and simply named:
- Collapsed
- Expanded All
- Expanded One
- User Dropdown
The same goes for the “Button” component that is broken down below it. In fact, it’s broken up into deeper categories:
- Default (further broken up by Icon and Text)
- Flat
- Outline
And each of those subcategories is divided up by button priority and state. But regardless of which button it is, the naming conventions remain the same, which makes locating the desired UI pattern easy no matter how large your library is.
5. Establish the Rules
Last but not least, you need to write down the principles and guidelines for your design system. These may include:
- Brand guidelines
- Design principles
- Usability and accessibility guidelines
You’ll find a good example of this in Material Design:
This helps designers more effectively work with a design system as they understand the driving force behind it.
Google doesn’t just relegate an “Introduction” page to its design principles. Each of the foundational elements are well-thought-out and explained, too:
In the example of “Environment > Surfaces”, we learn how real-world dimensions influence the design of components with light and shadow in Material Design.
This might seem like overkill for your app—and it very well could be, depending on the scope of the job. However, for longer projects, you never know when a new designer or developer might enter the job and wonder why the heck you’re doing what you do. Or you might simply need it there as a refresher when it comes time to update your app.
What Are the Benefits of Building Design Systems for Apps?
By creating a design system before a project begins, you set the rules for the job and ensure that best practices are adhered to from start to finish. But that’s not all.
Design systems are responsible for:
- Bringing consistency to the UI of an app
- Simplifying the management of even the most complex of apps
- Improving collaboration as team members approach the job using the same language, components, tools, and so on
- Making better products as stakeholders across various disciplines have a say in how the product is built from the very beginning
- Enhancing the scalability of the app as all the foundational groundwork and rules are already set
And although it does add more time upfront to an app design job, creating a design system actually saves you time later on when new designers or freelancers enter the project, the client alters the scope, or it’s been months since you looked at it and need to make adjustments.