Why Design Systems are the Next Big Enterprise UX Practice

Since the start of the new year I’ve been working on a new Design System for a large, complex, enterprise application. The existing application is becoming a monster; CSS has become unmanageable and monolithic. We are about to move our application over from legacy front-end frameworks to Angular 2, and it’s time for a fresh overhaul.

A page is not a page anymore

Style guides are a simple concept — a set of predefined styles that control an application’s visual style. But in recent years designers are leaning towards something a little more complex. With the rise in popularity of modular front end development, and the widespread adoption of various devices, style guides need to change. We no longer build applications for static, one-size-fits-all screens. We have to think about how our application will look and work on devices as small as a smartphone or as large as an 80” TV.

User experiences change from device to device, meaning it’s very possible that our applications will as well. For example, sometimes putting your entire application on a mobile device isn’t necessary. Features are often paired down and streamlined for specific experiences (think Facebook & Messenger), but that doesn’t mean we want the user to feel like they’re not in the same enterprise application’s ecosystem.

Designing and developing reusable, extensible components keeps our users feeling like they’re in the right place and ensures that pieces of the UI function the same way. When building a new feature or application, we can know with a pretty good level of certainty that our users will understand their interface. This also saves on development cost. Components can be developed once and applied across your devices and applications.

What this means for your team

Adhering to a single UI Design System forces our design team to make conscious decisions about adding new components. This can be as simple as a new button style, or as complex as an analytics card. Our team is small (for now) so it’s easy enough to keep designs consistent. But on a fast-growing or larger team, our application would very quickly turn into Frankenstein without these systems in place. It’s important to note that we don’t want to discourage innovative UI designs, just ensure that change also means improvement.

We’re changing the way we think about the partnership between design and development. In the past, designers would create mockups and developers would try their best to reproduce them. Using products like InVision our designers create interactive mockups to illustrate a user flow. Without a Design System in place these mockups actually become very misleading in enterprise applications because it becomes impossible to design for every state of of a UI. In this scenario, developers stop understanding the user experience they’re building, and end up focusing on pixel imperfect mockups.

A Design System bridges the gap between the two teams so that everyone can focus on what they do best. Now when developers are handed an interactive mockup they are using it for its intended purpose, explaining a user experience. In a Design System, UI components have every state and approved style built into them. This means the development process becomes composing a page of pre-approved components, and future enhancements of the component get rolled out automatically.

This transition is still on-going, but thus far the initial cost of setting up this component system is paying off rapidly. As developers get on-boarded to our new front-end framework they can focus on learning the new technology and not on building pixel-perfect UI’s.