“Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works.”—Steve Jobs
With the emergence of Node-based technologies such as React and Angular have come new opportunities for both UX designers and developers to leverage design systems to enhance their application user experiences. This article aims to help those of you who are weighing the advantages and disadvantages of using design systems and component libraries for your application.
Consider the scenario of a Web application that is being designed using a Material Design style, which could be built to specifications for one device, serving one operation, or could perform significantly differently under other conditions, in another context. When you consider the variances in how user interactions function, the value of leveraging a design system starts to pay returns as front-end development teams build out component libraries at scale, yet performance teams may also find variances in the user experience that are worth researching.
Champion Advertisement
Continue Reading…
VMWare’s Project Clarity Design System
The UX guidelines for VMware’s Project Clarity design system advise third-party engineers on managing the implementation and look and feel of user-interface (UI) components.
At NGAtlanta 2019, Jeeyun Lim, Senior UI Engineer at VMware, described Project Clarity as follows:
“While we have published UX guidelines for [third]-party developers with Project Clarity, our design system provides the look and feel for how we want it to perform within an application. Clarity is for both designers and developers.”
At the intersection of UX design and functional programming, the user experience encompasses how an application looks, performs, and makes users feel as they navigate and use an application. Therefore, design systems try to bring parity to these complex interactions by bringing both designers and developers into the same conversation about an application’s user experience at the component level.
The clearest advantage to developers of using the Angular CLI (Command Line Interface) build tool with Clarity’s installs is the ability to create UI components quickly using the design system. This gives teams a clear build process for their Web technology. The following commands instantiate global design styles for the application:
$ npm install -g @angular/cli@latest
Using a Design System on a New Project
For new Angular projects, use ng commands to build new projects with the CLI, as follows:
$ ng new build-with-clarity
This command creates a new directory called build-with-clarity for a new Angular application. Project Clarity also defines a few design dependencies to get started with global styles:
$ npm install @clr/icons @clr/angular @clr/ui @webcomponents/[email protected] — save
Add Clarity for Application Styling
Whether you’re styling your application using CSS or SASS, you can load the Clarity design scripts to your project to create a consistent visual framework.
From the designer’s perspective, the advantage of leveraging the design system’s base styles is that the visual-design language has already been considered, and you can work from the building blocks of styles.
But it’s important to note: it is very likely that designers would need to modify these styles to meet their organization’s brand and user experience guidelines.
The Paradox and Shared Value
The advantages of the design system’s visual language can also bring a user-experience paradox that adds complexity to a diverging application architecture. The particular UX design that the design system employs also dictates how UI components are delivered. While both developer and designer must simultaneously evaluate the extensibility of both the visual components and the technology, the criteria for estimating their value might not get equal weight on the team because of technical constraints or customer needs.
For example, a developer or UI engineer might need to support a legacy interaction to maintain an existing user workflow or integration with a third-party API. In contrast, a designer might offer user-research findings or user sentiments that validate a necessary design change. The outcome could very well be that neither party gets exactly what they need from the design system out of the gate. Therefore, product customization could be necessary.
A UX paradox often arises early on, when a team is envisioning how they might use a design system. Learned behaviors and user preferences for an existing user experience could overshadow discovery of the design system’s features, so moving design forward could be challenging. Both the designer and developer might get caught up in the look and feel of the system rather than examining or testing how they could customize it to meet their needs. This can be a missed opportunity. A bias toward the existing user experience can prevent testing and experimentation when integrating new components.
For instance, consider the performance of a UI component such as a progress indicator. Human-factors research such as a TAFIM (Technical Architecture Framework for Information Management) might tell us that a progress indicator should operate within a 15-second target rate and provide sufficient visual language to enable the user to understand the system feedback for an operation. A development team could try to customize and hit that target by modifying some aspects of the UX design. The extensibility of design-system components might help determine whether a developer or designer can work with a given component library or would need to create their own.
Experimentation Is Key When Choosing a Design System
Designers who are able to see the application architecture can consider how to abstract components for their UX design. By gaining some familiarity with the application architecture and being able to prototype and experiment with the components, both designers and developers can test parts of the application such as the header or a content area, while at the same time considering how they impact the rest of the design.
Such experimentation benefits the entire team as they come together to discuss the architecture in relation to the consistency of the user experience. For instance, design discussions can focus on optimizing the layout for user workflows instead debating design styles. The following is an architecture example from an application using Clarity:
./src/app/ui
├── layout
│ ├── header
│ │ └── header.component.ts
│ ├── layout.component.ts
│ ├── main
│ │ └── main.component.ts
│ └── sidebar
│ └── sidebar.component.ts
└── ui.module.ts
The shared value that derives from experimentation—whether that means prototyping or testing—benefits both designers and developers when sharing design ideas and testing implementations.
Has your team used a design system for a project? How did it go? If you have any thoughts or comments to share, please add them to the comments or ping me on Twitter @clevelandrachel.
Rachel is a User Experience Engineer at Rockwell Automation, the world’s largest creator of industrial-automation and information products, whose flagship brands Allen-Bradley and Rockwell Software have been recognized for their innovation and excellence. She leads interaction, performance design, and UX strategy initiatives for engineering and product teams. Rachel has spent the past decade creating, cultivating, and working in agile communities globally. She promotes collaborative engineering as a vehicle for increasing quality and productivity within teams. Read More
