Design systems have been a huge part of the conversation around design for the past few years. There have been many attempts to create a design systems that are open source. Some examples include Material Design by Google, the Atlassian design system, and Ionic from the Ionic team.
What is a design system?
To simplify, a design system is a collection of rules, guides, and principles implemented in design and code through components with the goal of building a multitude of applications with a consistent user experience. There are many parts of a Design system such as documentation, design toolkits, component libraries, best practices, UX patterns, and branding guidelines.
Some high profile companies have chosen to make their design systems public, others have gone a step further and made their component libraries open source and available for anyone to use. This is the case with Angular Material built on the Angular framework for the Material design system.
Reasons why you need a design system
Some of the most common challenges with teams when it comes to the frontend have to do with undocumented styles, too much custom CSS, and lack of consistency in the UI. From a developers perspective, many do not want to spend time writing CSS. They would prefer to work on implementing features and move on.
Like in most teams, without documentation most developers are unaware of what they already have at their disposal. Many will end up implementing custom CSS that might have already been written by someone else. A design system would help centralized documentation for CSS, reducing the amount of work developers need to do. Like with JavaScript, CSS also comes with cross-browser challenges. Centralizing documentation helps team solve the problem once and allow others to reuse their work and reduce the amount of custom CSS necessary. This will also help reduce the size of files users need to download on their devices to render the UI.
Inconsistency is a huge problem specially in more mature products. Without a set of centralize rules and guides implemented in the code base, many applications end up with inconsistent way to perform the same actions, such as filtering a list. Designers frequently will also create different designs for the same problem because they are unaware of pervious solutions. A documented set of UX patterns and best practices can help designers implement consistent UI solutions.
The primary benefit of a design system is scaleability. Design systems reduce inconsistency across one ore more products. They also reduce the amount of code written, freeing up developers to work on more exciting features that will add value to their users. From the end user’s perspective, they receive a consistent user experience across the different solutions the origination offers.
Reuse an existing or create your own
Resource are always limited regardless of the size of the organization you work in. Putting together a design system for your organization is no easy task. Many organizations choose to use an open source option. This mostly takes the form of a UI component library, one of the many pieces of a design system. In most cases this will work in the beginning. As the organization grows and more digital product offerings are introduced there will be draw backs. This is specially true for the UI in companies with multiple applications where different teams maintain them.
Implementing your own can also be resource consuming. Like any other product, a design system needs time to mature. If an organization does not have the resources, or is not willing to invest in it, an existing public design system may be a better option.
The advantage in creating your own is that it becomes exactly what your company needs. Keep in mind that systems like Atlassian’s design system were created to solve the problems of their organization and their users, not yours. While there may be overlap, you will quickly see where you may find yourself retrofitting their solutions to match your product needs. This is more evident with component libraries.
If you are starting your own design system consider where you see the biggest pain points and start there. In my experience, most organizations are spending too much time writing the same CSS, HTML and JavaScript over and over. For this reason it may make sense to start documenting existing CSS and introduce a component library since that’s where engineers will save effort when implementing features. It also helps centralized the UI because it makes it easier for redesigns in the future. Remember, a component library is simply the coded implementation of the rules and guidelines identify in the design system.
You also don’t have to be original with the documentation. Many of the existing design systems already have great documentation such as patterns that you can adopt in your system. Take what best fits for your product, team, and users.
On component libraries
When most organizations think of a design system, they think of a UI component library. UI components are a small part of the entire design system, but for many it makes sense to start here to reduce redundancies during development and testing.
Open source software is amazing because it makes developing applications much faster. It is also one of the leading problems regarding product inconsistencies in my opinion. Over the years I have seen organizations use a plethora of UI component libraries within the same product. Mostly introduced by developers when they needed to solve a problem quickly but their current library did not have a solution. Instead they found something on Stack Overflow and introduced it into the code base without thinking of the larger ecosystem of the product. Many times this is fine in the beginning, but this approach does not scale for large organizations.
The lack of a centralized design system has lead to the use of different open source solutions all within the same product. I have seen the same application using Telerik, multiple versions of jQuery UI, and good old Bootstrap. As you can image this becomes difficult to maintain and the differences in UI implementations between these libraries make the user experience inconsistent.
If you are thinking of building your own, consider the resources your team is willing to invest in it. The project may not take off if there is no buy in from the management team. Bellow are a few other items to consider around UI component libraries.
Writing your own
If you are considering building your own, you really have to have buying from key team members. It will take time for the components to mature and workout all the bugs. It’s wroth taking the time to do a cost-benefit analysis if you decide to go on this journey.
Future proof your UI components
Most mature products are likely to have different applications built with different stacks. If your organization’s UI across applications includes multiple frontend frameworks and UI component libraries, it may not make sense to write your library in Angular because they would not be compatible with older version such as AngularJS or other frameworks such as Vue. I would recommend that you look into StencilJS if that is the case in your organization. If you are lucky enough to have your applications in only one technology, ensure your team does not plan on changing or introducing new incompatible technologies before choosing how to build your toolkit.
Replacing an existing one
One of the most difficult aspects with existing applications is redesigning and replacing old UI components built on a different technology. Most resources tend to go to building new features. One approach is to update the components as each page is being redesign, but it will most like take years for a large complex application. Future proofing your components will help make them available for use in applications with an older stack. It does not solve the problem of replacing existing ones, but having them as on option is the first step I would recommend.
Multiple products
If your organization has multiple products consider building your UI components in a way that are agnostic to technology or frameworks. In other words, make sure you can write them once and use them everywhere. Building in such a way will increase the likelihood of other teams adopting the design system and still give engineers opportunity to use different technologies when necessary. It also makes designers happy because the UI will look pretty and consistent everywhere.
Refreshing the brand and redesigns
Regardless of whether you are building your own or reusing an existing UI component library, you should consider how easy it will be for your organization to keep your applications looking edgy and modern. Technology changes, and trends come and go. Keeping your products up to date with today’s visual trends is a good way to reintroduce life into products. As you explore what best fits for your organization, I would encourage you to consider this into your decision. It will also help with introducing features such as white labeling, themes, and dark mode for accessibility.