In developing a software product, there are times where building a set of apps is more ideal than building one giant application. As an organization, you may have needs such as billing management, performance reviews, product management, or creating a small networking site for your associates.
These applications are usually designed silo-ed from each other, and this brings a variety of issues to the table. When designed separately from each other, some apps may use a dark blue for their background, while other apps may add different tones of blue to the base background color in an attempt to distinguish it. As a result, you may have a set of apps that can have as many as 15 shades of the same color. Not only that, but different widgets for picking dates and navigation may be different for every app that is part of the suite.
These problems divert from the experience of your consumer base. Users expect the same widgets to interact and behave the same way if they’re part of an offering of applications. Using the jQuery date picker in one app and immediately using the Airbnb date picker can throw off your users' expectations, especially since these apps may have links that take you to a different app in the package. Not only that but using different colors and fonts for applications makes them feel disjointed from each other, as brand identity is lost. The result can look like this:
To get around these problems, a design system is needed that is applicable to the enterprise level. Instead of a single design system for one instance of an app, this design system is setting the standards for all applications that belong to an organization or suite of related apps. Having this system in place resolves several concerns including:
- Prototyping apps is easier, and layouts and base widgets are already defined.
- Maintenance for widgets is easier, and the base code for the widget relies upon a system that can be modified and released for apps to consume.
- Spacing, font size, and navigation are more unified and easier for the user to follow, as an Enterprise Design System includes utils and components for these 3 issues.
In addition to these benefits, having a design system can make transitioning to a platform much easier. By defining these interactions, you can pass off the design to other consumers of the platform. This will help them build better applications for consuming data and content from your platform. The standards are already created, and the consuming teams just need to follow them. A great example of this design system is the Material Design System that Google developed, which is comprised of components that can be used on a mobile android application.
Building the system
How the design system is built depends on whether you are developing an entirely new set of applications, or you are trying to unify the designs of a set of applications. In general, the following things are needed for an enterprise design system to be effective.
- Base widgets
- Base Layouts
- Base font sizes
- Base colors
For existing applications, establishing these patterns will require a UI audit of applications within the same suite. Different apps may have established their own patterns for dealing with interactions such as form inputs and date changes, and those interactions need to be unified across apps among the suite. The widgets don’t have to be identical, as some apps may need to provide additional mechanisms that others do not.
For example, if you have an application for setting up performance evaluations, picking dates may require min and max values. However, a networking app within that same domain may not require the same min and max properties. Going through multiple apps in order to unify user interactions may seem daunting, but you already have several apps that use some kind of pattern. This makes it easier to identify the parts that are (or can be made) the same.
For developing new applications, creating new UI components can be daunting. It’s not exactly clear how the components should be handled across various scenarios, so it’s best to keep it as simple as possible. Otherwise, there is the risk you may make the component more flexible than it needs to be. This would make it less reusable in regards to keeping a consistent feel across applications in a given suite. As more needs arise for interactions within a set of apps, more use cases of a particular component will reveal themselves (at which point it should be added to the style guide). Typically, this occurs after you have 3 or more apps that require the same component.
Customizing the design system
While the goal of a design system is to have the same interaction patterns across several domain applications, instances will most likely occur where you will need to change the look of an app. A client organization may want an app to have the same colors and logo as it’s brand identity, or you may need to provide dark and light modes of an application to provide better accessibility across your user base. The best way to accomplish this is to provide a theme for the application to follow. This allows for changing of presentational, such as colors, font families, and base font sizes.
Theming is usually implemented by creating variables instead of hardcoded values for the margins and colors for all of your components and layouts. For fonts, a variable would be applied to the root application that allows you to change the font library or a typographic component that sets the font of the text. For example, if you were theming a web application, most likely you would have a root select for the HTML node and a CSS variable that can be changed.
Examples of Enterprise Design Systems
Enterprise Design Systems exist for several platforms. Microsoft and Apple, for example, have their own design systems for building native apps on their platforms. Their goal is to unify the base interactions across any app launched on their platform. This includes base interactions such as menu bars, closing the application, and how buttons should be used.
Microsoft Interface Guidelines
In addition, several non-tech organizations have established their own design guidelines as well. Over the past few years, the US government has been looking to unify the interactions among various applications. They’ve spent a lot of time auditing their applications and finding commonalities that can be applied to all of their online applications.
Final thoughts
Getting the interactions consistent across an enterprise set of applications can be daunting. By developing a design system that can be used across the entire suite, you can ensure that your apps are consistent and users will have an easier time interacting with them.
While having the design system helps create a unified experience, everyone needs to follow it once it’s established. It can become really easy to deviate from the design guides when it feels like your scenarios are not adequately covered. While it’s tempting to create your own components specific to the app, this creates inconsistencies among apps. It’s up to both the developer and designers to keep each other in check while working on their respective projects. Otherwise, the same problem that the design systems fixed will resurface, bringing you back to square one.
