There are times when it's better for a business or organization to have separate apps rather than one central application. On the consumer side, some services have spread out their news, sports, and streaming services into several different applications. Amazon is one such organization that spreads services across apps.
For internal organizations, things can be spread out even more, with various apps required for billing, payroll, project management, HR, and other functions a business needs to maintain. Having separate applications for a business makes it easy to maintain. Changes to one application do not risk unintended changes to another, and they can also have their own release schedules.
While isolated apps can be easier to manage than one large one, there is a huge risk in the apps losing their consistency and branding. Oftentimes, the teams developing these find their own UI components to add, and work as if they were their own application. What this leads to is apps that don't look or feel like they belong together, even though they are developed by the same organization.
Date-pickers may have different buttons on them, accordions may not open the same way, and even the layouts and colors used across various applications can vary dramatically. This can confuse users into thinking they are using a different product altogether. Oftentimes, the result looks as below:
On the development side, this can lead to disjoint coding standards as well. An organization wanted to use React and a date-picker component across its apps as it fit almost everywhere a team needed. One team liked the look and feel of a different date-picker, and went to the level of integrating AngularJS on top of their existing React stack just to use it. Code bloat like this can easily happen, and it gets hard to determine what direction an IT organization would like to go if they are all using not only different frameworks but different UI widgets as well.
To get around these problems, a design system is needed that applies to the enterprise level. Instead of a single design system for one instance of an app, this design system sets the standard 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 within 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 minimum and maximum values. However, a networking app within that same domain may not require the same minimum and maximum 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 look and 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 its 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.
- Example: Apple Interface Guidelines
- Example: 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.
- Example: US Web Design System
Governance
The last thing for a design system to work is to keep good governance. If one team lets a designer go outside the established guidelines, it's not often too long before the application has it's own design, and deviates from what the rest of the organization has established. Once one app goes this route, another one is shortly to follow.
To prevent this, design mockups should reference components that are found in the design system, and even creating sticker sheets for designers to use in their design software can help the app stay on track. If deviations are required, it needs to be documented on what the change is needed for. Make sure to note if another workaround using different components works and if the design system itself needs to be changed. All these should be considered before an app uses its own defined component. If it truly is a unicorn scenario, make sure the why is documented well.
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.
