Design Systems for the Real World
In theory, there’s no difference between theory and practice. In practice, there is. — Yogi Berra
Large-scale design systems are created with great purpose. They also require a huge effort and broad capabilities to develop, engage users, and remain relevant for everyone. Application end-users are the target consumers, but before they get their hands on system-driven applications, UX designers and UI developers must first use the systems.
It’s not guaranteed that designers and developers will use a specific design system, or even that they will use the system as the creators intended. Designers and UI developers will use a system suiting their capabilities, constrained by their inherent limitations and biases (conscious or unconscious). Design systems must thrive in such circumstances. Designers and developers want a system that serves their particular needs and makes their work easier. At the same time, designers and developers want to know their contributions go beyond rote system application.
At GE, we’ve steadily evolved our Industrial Internet application design system over the last five years, with plenty of successes and our share of challenges. Based on our experience, a few key tools can give designers and developers autonomy, while also letting them create robust applications based on an established design system.
Design and Technology are Interlinked
All design systems require delivery by some medium. For large-scale digital design systems supporting many applications, reference implementations of system elements promise that designs will be implemented properly and with the desired fidelity. While the precise extent and approach can vary, the basic result is clear: design (aesthetics plus interaction) and technology become interlinked. Usage and adoption are also critical, as designers and UI developers must share the same effort and scope in applying the system.
Interlinking has provided us with great benefits at GE, but has also posed challenges for our teams. For our original design system at GE Digital (called IIDX), we used a combination of Angular, requireJS, nodeJS, and custom CSS (based on Bootstrap). Design stencils were provided in Omnigraffle and Illustrator. While the design stencils and guidelines were highly useful for designers, the UI technology became difficult to manage, and there was significant drift between designs and implementation; teams found the technology hard to use consistently and re-use was not as widespread as hoped. For the design system that followed, we switched to a framework-agnostic approach that relied on modular, highly re-usable web components and an extensible CSS framework (all accessible via Github), and shifted design stencils to Sketch and Illustrator. The latest evolution (Cirrus) uses the same component-based technology stack, but the design stencil has been standardized within Sketch, where our design team worked well to create extensive and customizable symbol libraries. More on our approach below.
Systems Come in Many Shapes and Sizes
No web application design system can encompass every conceivable application; there are always unspecified parts for the designer to interpret in applying the system. That also means there can’t be a reference implementation for all scenarios, so developers will always have to build something, even if when only laying out existing components and specifying the behaviors through APIs. As a result, systems come in many shapes and sizes, roughly like the spectrum shown below.
Consider a simple system that specifies colors, basic typography, and styling for HTML input elements (i.e., some basic “atomic” building blocks) like a set of Lego blocks. Designers will have nearly unlimited freedom in this scenario, and developers will need to build most things from scratch. In this example, there’s always a large gap between what the designer needs for an application and what the system provides, regardless of the complexity of the underlying application. Much interpretation is required, which allows the designer an imprimatur on the application while also creating more work for both the designer and developers.
A more robust system will have an extensive set of both atomic building blocks and more complex, compound, interactive components (possibly including some base layouts). The newly redesigned Predix Design System is an example (as was our previous Predix UI system). This system provides designers and developers with a robust tool kit, though not a complete prescription. The system avoids replication of common design patterns for many data-driven web applications, and promises reductions in developer effort by offering reusable components. The system is depicted right of center in the above illustration, showing how designers can have freedom while still accelerating basic parts of designs.
Based on our past experiences, and a desire for the appropriate design system complexity, we conducted a thorough series of workshops and involved the broader GE UX design community in creating our latest system. Our goal was to identify the patterns and elements that provide designers with the greatest value in application design. At the same time, our UI technology development team provided a component library with rich APIs to support customization through configuration.
The Gap of Interpretation and its Impact
For simple applications, a robust system has everything the designer and developer need to apply the system and build an application. For moderately complex applications, designers need to interpret the system, but with a relatively low degree of ambiguity, and developers can usually tweak existing reference implementations to achieve what’s needed. Complex applications are inherently more ambiguous when it comes to the application of even a robust design system.
At GE, our large-scale, data-driven Industrial Internet applications tend to be complex. The design system and its components rarely cover everything designers or developers need. There’s usually some pronounced ambiguity in applying the system, or a so-called “gap of interpretation.” Here are some of the challenges we’ve faced:
· Reduced Inter-Application Consistency and Increased Effort: Big gaps mean lots of interpretation, which, in turn, means it’s harder to keep applications consistent and there is more to design and build.
· Reduced Quality: Interpretation can lead to less-skilled designers applying the system to complex components. Quality inevitably suffers in this case, or can vary between applications. In turn, if developers have to build new components from scratch (i.e., without reference implementation), some items may not be tested adequately and skills gaps could be exposed in the UI development team. This can become especially pronounced if the underlying technologies used in the reference implementation are not core competencies for UI developers. We’ve found this is the case for our global teams with widely varying levels of technology exposure.
· Lower Degree of System Adoption: When these effects are combined, designers and developers may be reluctant to adopt a design system, or they may have difficulty applying the system “correctly” or consistently for sufficiently complex applications. If a system is going to expose capability gaps or areas for improvement or lead to lower-quality outcomes, some users might diverge from the system.
Conversely, we’ve seen huge benefits from our design systems. For all of the basic building blocks — and even many moderately complicated components — we’ve made work easier for designers and developers. Stencils and reference implementations greatly reduce the cognitive overhead in quickly launching consistent designs and implementations. Our success comes in our ongoing effort to provide a community-oriented support system for the design patterns and UI component library.
Get the Balance Right for Success
At minimum, the robust systems we’re describing rely on documentation (of the patterns and design system elements) along with reference implementations. This is substantially a “DIY” model that relies on the designer’s skills alone. Because of time and resource constraints, we pursued this approach in our earliest design system (IIDX).
A more hands-on, community-oriented approach expands the broader effort to include training, coaching to facilitate intra-team communication between designers and developers, elements of community (e.g., discussion forums and Slack channels), and explicit support (e.g., resources to answer questions about design patterns and implementation issues).
We now believe the best solution must embrace a community-oriented model (both as part of system creation and during the system’s lifetime and evolution); alignment can be achieved by co-creating both the design system and its applications. DIY models can work for smaller co-located teams, simpler applications, or for minor gaps of interpretation. For anything more complex (like most of our applications at GE), the community is key to success.
After several iterations at GE, we’ve determined an approach that starts with a great pattern library and design stencil (in our case, Sketch, which includes an extensive symbol library created with smart overriding and resizing behaviors and more). Next comes a re-usable component library with APIs supporting variation through configuration, and with avid, constant maintenance and support by a centralized team. Then comes the power of community: our Slack channels and forums buzz with user activity, as the collective effort handles gaps of interpretation, variations in team capabilities, and challenges with UI technology. We also have a contribution model that allows our diverse designers and developers to add to the core design system and component library.
Design systems aren’t a silver bullet to creating consistent applications with uniformly great user experiences. Their adoption isn’t guaranteed and their usage is subject to the real-world challenge of teams with varying capabilities under different constraints. While there’s no perfect solution to such conundrums, a community-oriented model and a sufficiently rich system can create significant value for system creators, designers and developers, and application end-users.
