Creating Cirrus: The next generation Predix design language
Evolving our design system with a community-driven approach
During the history of GE Digital, there have been a few generations of design systems. The current incarnation of the Predix Design System, based on reusable web components, was launched about two years ago. At the time, our product suite was smaller and the design system was focused primarily on one product line and some very specific use cases. As GE acquired products, the number of teams building apps increased and so did the requirements and expectations of their customers.
Common feedback told us that the design system wasn’t flexible and lacked visual impact and appeal. The original design language was created with a very minimal style to suit our main objective at the time: speed of delivery. While it was appropriate at the time, expectations grew for a more refined and diverse design system for our products. The time was right to invest in an overall refresh of the design language for the entire system.
To measure our success, we outlined a set of goals for the effort:
- Establish a more visually sophisticated design language
- Increase the diversity of design patterns
- Involve the design community to improve quality and adoption
- Provide better guidance about how to use the design system.
Determining our viewpoint
Prior to gathering the broader design community at GE, our core team needed to explain the elements of a good Predix application. Considering our digital-industrial use cases, the businesses goals of our apps, and end user workflows we devised a set of design principles to guide the refresh effort.
Purposeful
Design with a purpose citing context and clear calls to action that allow for fast orientation.
Efficient
Respect a user’s time and workflow.
Consistent
Rely on familiar visual styles and similar interactions for common patterns across the suite of Predix apps.
Elegant
Utilize modern visual and interaction conventions. Find opportunities to create and own innovative ideas.
These principles gave us a common language to speak about the work we were seeing and a framework to measure the success of existing applications and patterns for the refresh.
Connecting with the community
Before fully embarking on the refresh, we spoke with numerous designers and product teams about their experiences with the Predix Design System. Over the course of a few weeks, we scheduled informal conversations with stakeholders. We wanted to hear their thoughts about what was working and where we should focus our fixes. The feedback was fairly consistent. In general, they thought the components weren’t flexible for their needs, they wanted apps with visual impact, and they also wanted to know best practices for using the design system.
For the effort to be successful, we needed to invite teams into the process and give them a voice.
The previous version of the Predix Design System was built on the use cases and requirements of a single product. As other product teams appeared and applications evolved, a gap emerged. For the refresh to be successful, it was clear that we needed to invite teams into the process and give them a voice. We determined the best way to connect with the community and have them contribute was to conduct a series of workshops. Giving our stakeholders an opportunity to share their use cases, highlight challenges and brainstorm solutions would help us understand the needs of our users, build their investment in the System, and inspire design ideas for a System that would better address the everyone’s needs.
Structuring and running the workshops
To determine the focus of the workshops, we needed to better understand the work happening in the GE design community. We asked each team to post their work with annotations on our internal design-sharing site. We then printed out the work and posted it on boards and performed an audit. We catalogued existing patterns and components in framework of our design principles, noted where designers chose to create new components based on use cases, and identified emerging patterns we weren’t addressing.
We scheduled six workshops, allowing sufficient time for remote teams to travel and attend. In the first session, designers shared their work and spoke about requirements and design decisions. This helped us validate our findings from the audit and update the remaining workshops, while participants could communicate their priorities and compare with design work across the company. The other five workshops were focused on foundational elements of our applications. This included focused sessions on navigation, page layout, color, and materiality as well as data input and data presentation.
We structured the design workshops in three-hour blocks to keep attendees focused and respect their time. An agenda was shared beforehand and we prepared a brief introduction and handouts for each session. We arranged the room with tables seating 5–6 people each, and asked people to sit with others than their usual co-workers.
We wanted to facilitate cross-talk between business units and inform participants of the broad range of requirements the design system needs to support. The time was divided between sharing work, enjoying an activity based on themes that emerged from the sharing session, and discussing output from the activity. Following each workshop, we provided detailed notes and pictures to the entire design community (those present and absent).
Defining the language
During the course of the workshops, we started to see some trends and common pain points. By the time we wrapped them up, we had a fairly clear idea of the direction we needed to take the design system.
Color
Our products are used in critical environments, where colors have distinct and important meanings, so we were very purposeful with our use of color. In addition, data visualizations are an important aspect of many Predix applications, where some of the most in-depth tasks are performed. It was logical to extend our data visualization color set for more meaningful and expressive charts and graphs; however, we also needed to consider how much color to lend to the foundational interface elements, such as menus, headers, and navigation. Ultimately, based on research from our Healthcare design team, we chose to add more colors to our neutral core palette and shift the tone from warm to cool. This gives a Predix application a personality that augments meaningful color usage within data visualizations and alerts.
Materiality
The next step was to interpret the objective of a visually sophisticated design language. Because readability of data on our product interfaces is so important, we wanted to keep our data input and presentation patterns clean. We saw the background materials as a good opportunity to add style to the design system. The existing system had a light theme and a dark theme, but we learned during the workshops that the choice didn’t allow much flexibility. For a richer sense of materials, we combined the themes while extending our foundational cool greys — now a signature element of the System. Unifying the themes doubled our core color palette and gave designers more ability to highlight important information and add visual interest. The palette also allows teams to define a unique style for their app within the Predix color family.
Animation and layering
Predix applications often relate to real-world devices and environments, and we wanted to bring some of that tactile approach to the design language. We created a system for layering user interface elements that adds physicality and reinforces visual hierarchy. Components sit at the bottom of a page, temporary elements, such as drop downs, sit in the middle, and modals and navigation sit atop all. The clear layering helps reinforce hierarchy and priorities during workflows.
Further building on our principle of elegance, we added motion to transitions. We choose places to add subtle transitions, where they would add to the experience and not hinder the efficiency. This resulted in lightweight animation treatments for navigation menus, panels, and loading spinners that augment the experience and make it more fluid.
Iconography
The design system had relied on a practical, but not unique, open source icon font for its iconography. As we started applying the existing icons to our new, open, and modern language, we realized the bulky icons did little to help. Additionally, many teams didn’t have optimal metaphors because they were limited by the selection of the icon font. To fulfill the direction of our design language, we created a custom icon set that would let us address our industrial use cases and easily extend them when necessary.
Implementation
Before we committed to writing a line of code, we needed to stress-test our designs in real-world applications. Once we had worked through our initial design ideas, we provided a Sketch file with core components and layouts to allow designers to explore how to translate their apps to the new design language. We invited designers to attend office hours and discuss how the System was scaling for them. This process let us refine the design language easier than if we had jumped right into development, and our steps also let the community create the design language that helps create a shared ownership.
Before we committed to writing a line of code, it was important to stress-test our designs in real world applications.
We held monthly stakeholder readouts to recap the progress for designers, product managers, and engineers, to gather feedback on the design direction, and to field questions. In addition to demonstrating the core concepts and visual direction, we were able to show explorations by other teams to illustrate how the system would scale and apply to various applications. This proved a powerful way to visualize the community involvement and communicate the vision for our applications.
Once we were confident in our direction, the team went heads-down on implementation. We had to decide whether to release components in-progress or when all were ready. Typically, our team prefers continuous integration, but since this would be a breaking change, we chose to keep components in-progress behind a prerelease tag in GitHub. Having started the design process in January, we competed the huge effort and succeeded to ship the General Availability code in July.
Stats:
- 117 GitHub repos included in the release
- 3,578 commits to those repos
- 116 days of development time, for an average of 31 commits per day
- 3484 automated unit tests for our Web Components, which we run against 6 browsers
Introducing Cirrus
The result of this community-driven approach is our new visual language named Cirrus. The name suggests the thin, wispy clouds of the upper atmosphere, and reflects the “lightness” of the visual and interaction language improvements. The system is flexible to support the variety of our product use cases while still recognizable as Predix.
Guidance and adoption
Shipping the updated components was only the start. Prior to the update, the components and design guidelines had separate locations for designers and developers to adhere to best practices. If you knew about the component library, it was likely you had never seen the design guidance. Based on the output from the workshops and input from the community, we created a fresh set of guidelines for our new design language. With teams spread all over the world, we need to keep our all our documentation and guidance in one place. So, we built out a new section on predix-ui.com to serve design and development guidelines.
Published guidelines are helpful, but to be fully effective, our work needed to become part of a designer’s workflow. The previous iteration of our design stencil was built in Adobe Illustrator, and allowed some freedom, but didn’t provide much guidance on the functionality of components. The design stencil also allowed designers unfamiliar with the design system to easily veer away from available functionality in the components and inadvertently cause more development work for their teams. This created much friction for the product teams and confusion concerning what our components actually provided.
To avoid this, we built a completely new Sketch stencil relying on symbols to maintain parity with the functionality of the components. The symbols allow us to put rails on the customization and show designers how components work without entirely relying on the component catalog. The new stencil has been highly effective in boosting the productivity of designers as well as making their designs accurate.
Additionally, we doubled down on our on-boarding material on the site to clarify how to get started with the design system. As for the design guidelines, much of the material existed but was scattered. Sometimes showing is better than telling, so we created a sample app to illustrate how basic constructs like navigation, data visualization, and forms should work within an application.
Takeaways
Our design language is modern and elegant, the components and design patterns are more flexible, we’ve cultivated a great community through workshops, design office hours and other channels, and guidance for designers and developers is more robust. We’re able to ship a better product and have advocates when we involve the community in the design process. See how it all comes together at Predix-UI.com.
