In this blog post, I’ll be talking about design systems (also sometimes referred to as design languages) as it applies to the process of designing and developing web apps and sites, and the design system process we’ve found successful at Mercury.
The term design system is relatively new one in the world of development, and has only come into prominence since the front end of websites (also known as client side) has become more complex and the need for front end architecture has arisen. A design system is essentially a collection of styling and code patterns which aid in the creation and development of applications. The “aid” is really the key here, as design systems can have one or more goals, such as:
- Increasing speed of development
- Better re-usability of design and code assets
- Improving reliability of applications
- More uniformity and consistency in design and branding
So when should you consider creating a design system? Not all projects will warrant it, as there’s a great amount of time and effort (and therefore cost) to creating one. A single landing page or a small website won’t need a design system, as the scope and timeline is small. Design systems are better suited for long-lived sites and applications, or large scope projects, especially ones that have many parts (for example, one or more of: public website, intranet, extranet, internal app(s), mobile app(s), etc.).
Design System Process
Creating a design system can be a daunting task. If you haven’t created a design system before, I’d advise not jumping into a design program or writing code (it’s very tempting), and instead try to follow a process that is not unlike developing a website. Doing groundwork before jumping into code will help control the amount of re-work you’ll do further down the line, as work tends to get more complex and slow once you get past the initial discovery phase. There are also things you might uncover that better inform your decisions down the line, or you might even discover assets you can use to save yourself time and work.
The process looks something like this:
- Assess & Inventory
- Pick Your Tools
- Outline & Plan Work
- Create Components
I dive further into each phase below.
Assess & Inventory
The first step into creating a design system is to inventory what’s been created or is existing for your client or company. Unless you’re creating a design system for a totally new startup from scratch, you’ll usually have something to look at and assess. In addition, make sure you’re using digital tools to capture everything – especially tools that are accessible by your client or company (cross platform or web based tools work best!). Apps like OneNote or Evernote can keep and share text, links, and images. You can store files in something like OneDrive or Dropbox. Also, use a video capture tool like Ice Cream Screen Recorder to capture videos of existing animations and effects.
Make sure to inventory and assess:
- Branding: Logos, colors, typography, and animations
- Voice and tone: Examples of writing that reflects the client/company personality
- Sites: Public sites, intranets, extranets, and mobile apps – make sure to save images, SVG’s, and take many screen captures
- Technology: What was used to create the sites and apps? Is it modern, or is it outdated?
- Team: What skills does the team have that will be using the design system? What technology are they familiar with? How to they communicate?
- Needs: What projects are in the pipeline? Where is the company going digitally?
Design System Tools
If you’ve done a thorough job taking inventory and assessing things, you should be able to make some decisions at this point that will get the ball rolling, including the tools and tech you’ll be using to create the design system.
A design system is a living thing; when changes are made, how will the team be informed? This could be as basic as an email, or kept track of in a Slack channel. Use the communication tool that the team is comfortable using.
Many design systems include UI kits for designers or UX professionals who may not code, but often this is optional, or can come at a later phase of the design system. UI kits are commonly created for popular UI programs such as Photoshop, Sketch, and Adobe XD.
It goes without saying that you should be storing your code in a Git repository. Example services include GitHub, Bitbucket, or Visual Studio Team Services.
Choose your client-side coding languages. I recommend using a compiled CSS language such as SASS or LESS. For your interactive components, will you be using vanilla JS or jQuery? If the team is using a JS library, you’ll want to create your components using that library’s patterns – examples include React, Angular, and Vue. Again, use the languages that your team is comfortable using, or has plans to learn and use soon.
How will the team be using and downloading your design system? Options include direct download, package management, or both. Also, if you want to make your design system accessible to the public, you’ll want to consider open source licensing.
Other considerations include organizing your work with a task board like Trello, and also DevOps with building, releasing, and hosting your design system on a site.
Outline & Plan What You’re Building
We’re almost to code – I promise – but before you get there, make sure you have a plan of what you’re about to build. You should be asking yourself:
- What components do we need?
- What do we need for an MVP?
- What can wait for a future release?
- Do we have all UX states covered?
- When will we be releasing our design system?
- When will we be testing our design system?
- How will we organize the work?
- What browser support do we need?
- What kind of long term support do we need?
One other point I’d make is about naming things – which is harder than you’d think. I highly recommend following a naming convention and doing your best to stick with it. At Mercury, we follow the BEM framework, which helps with naming components in an easy to understand way. Other conventions include SMACSS and OOCSS. If you’re considering using a framework like Bootstrap or Foundation alongside your own creation, also consider name spacing your CSS classes with a prefix.
Now that we’ve completed our research and have a plan, we can start creating the design system. A key point to keep in mind during this phase is to start simple, and work your way towards complex pieces. A good pattern to follow is the atomic design principles created by Brad Frost – work your way from atoms, to molecules, to organisms, to templates, to pages.
The first piece of the design system is documenting base level styling and assets, such as:
- Tone and voice
These aren’t components per se, but are the basic brand styling rules that should be followed throughout the system. If you’re using SASS, these would be SASS variables. In the design system, you should be showing how these styles render, and provide documentation for how they are used. Using Mercury as an example, you should render blue and green for colors, include the variable name, the color code (such as HEX, RGBA, or HSL), and any variations for those colors (tints, shades, etc.).
Another piece to mention is that you should be abstracting the names of these variables. For example, instead of naming a color variable $mercury-blue, you should use $primary-color. This is important because branding changes – blue may not be a brand color down the line.
At this point we should be styling single element HTML elements. Some examples include:
Interactivity with atoms is low, so you may be tempted to speed through styling atoms, but I’d discourage that temptation. Make sure to spend time getting atoms right and browser tested well, as they’re the building blocks for everything that comes after.
At this point we’re now tip toeing into small collections of HTML elements. Examples include:
- Button groups
Molecules should be small groups of two or more atoms but together. The complexity here is still low – I’d argue that molecules should mostly be HTML and CSS, and these components shouldn’t use any JS yet.
Organisms start introducing interactivity, which means we’re becoming more complex, and we may be adding required JS into our components at this point (but JS is not required for an organism). You’re probably going to spend a lot of time developing organisms – this is normal. Examples may include:
A side note here: if your organisms do need JS to work, dive into your JS library of choice to learn how to create re-usable and highly configurable components. For example, if you’re using jQuery, learn how to create a jQuery plugin that can be configured with different settings when they’re initialized.
Templates start assembling all the lower level pieces and give them structure and arrangement. So far we’ve been working in more abstract components, but templates should now be forming more concrete layouts. If you’re following atomic design, templates do not include actual content yet, and as such they could contain any content. Expect to iterate and create many templates for your design system.
Pages fill out templates with actual content and assets, such as images and videos. Pages, created correctly, will put your design system into action and will stress all your components to see if they hold up to their intended use. Just as you might have many variations with templates, you should have many variations of pages as well to demonstrate the final UI.
For any design system I’ve created, I’ve found that there are certain CSS classes that don’t fit into the atomic design mold. I call these utilities – very specific-use CSS utilities for accomplishing global actions such as controlling display, sizing, and spacing. It’s very important to document these utility classes well, as they will help control CSS bloat.
Your design system code should include companion documentation that helps other developers use your patterns. One truth I’ve found for every minute spend writing code, you’re going to need to plan for a minute of time to create documentation and example usage. One strategy that may help is to use something like Knyle Style Sheets to help automate generating documentation.
Although testing is included below the above steps, you should be testing – especially browser testing – your code all along through development. At Mercury, we use Applause, a service for crowd-sourced human testing that we’ve had great results with. Also, make sure to include accessibility testing, which is often overlooked. Advanced coders should also consider Selenium testing (possibly in conjunction with Applitools) and unit testing to make sure future releases don’t contain bugs or regressions.
Once you’ve completed your design system, how to you know if your design system achieved its goal or goals? You can track your documentation site through Google Analytics, and most Git services have analytics around commits, pull requests, bugs, etc. Most importantly, you need to keep tabs on your team to see if they are using, adding to it, and modifying it, as well as referencing your documentation and following correct usage of the components that were made.
Also keep in mind that a large system won’t ever be “finished” – browser support changes, aesthetics and trends change, and native browser functionality improves over time. For large projects that warrant a design system, you should have a plan and time set aside for future improvements and bug fixes.
Example Design Systems