by Jeff Gothelf
Finally, developers are familiar with asset libraries. These collections of reusable code elements are intended to make the developer’s job easier by providing tested, reusable code that’s easy to download from an always-current code repository.
As with many ideas in the digital world, digital design systems (which we’ll call design systems for the sake of brevity) are a kind of mash up of all of these ideas. A good design system contains comprehensive documentation of the elements of a design, rules and examples that govern the use of these elements, and crucially, contains the code and other assets that actually implement the design.
In practice, a design system functions as a single source of truth for the presentation layer of a product. Teams can sketch at the whiteboard and then quickly use the elements found in the design system to assemble a prototype or production-ready frontend.
The Value of Design Systems
Design systems are a powerful enabler of Lean UX. They allow the visual and microinteraction details of a design to be developed and maintained in parallel with the other decisions a team makes. So decisions like screen structure, process flow, information hierarchy—things that can be worked out at the whiteboard—can be handled by the right group of teammates, whereas things like color, type, and spacing can be handled by another (very likely overlapping) group of folks.
This has a couple of big benefits for teams:
It allows the team to design faster, because they’re not reinventing the wheel every time they design a screen.
It allows the team to prototype faster, because frontend developers are working from a kit of parts—they don’t need to recreate the elements of a solution each time, they can just go get the appropriate pieces out of the design system.
It also has some big benefits for organizations:
Increased consistency
A good design system is easy for developers to use. So they are more likely to use parts that they find in the design system, and less likely to “roll their own.” This means a greater likelihood that their work will adhere to brand standards.
Increased quality
By centralizing the design and creation of user-facing elements, you can take advantage of the work of a few highly trained and highly specialized designers and UI developers. Their high-quality work can be implemented by other less-specialized developers in the organization to produce top-notch results.
Lower costs
A good design system is not free. It requires investment to build it and staff to maintain it. But over time, it pays for itself by providing tools and frameworks that make the users of the system—the other developers in the organization—more efficient and more productive. It allows new designers to come up to speed more quickly, for example, because it documents all of the frontend conventions used in an app. Similarly, it allows new developers to come up to speed more quickly, because the basic building blocks of their work are available in an easy-to-use framework.
Case Study: GE Design System
In 2012, GE opened GE Software in San Ramon, California. This new “Center of Excellence” (CoE) was designed to help GE improve its software game. A few years earlier, a strategic review helped the company to see just how central software had become to their business—measured in lines of code, GE was something like the 17th largest software company in the world. And yet they felt they were not treating software development with the focus it deserved.
San Ramon included a new team at GE: the GE Software User Experience Team. This small team at the heart of a giant company created their first design system in 2013 in order to scale the impact they could have. Indeed, with fewer than 50 designers to collaborate with more than 14,000 developers (inside an organization of more than 300,000 people), there was no way that this startup design team could grow quickly enough to have a meaningful effect at GE.
The team’s first design system, called IIDS, for the Industrial Internet Design System, was designed by a group of internal designers with the help of a small team from Frog Design, one of the leading design firms in the world. The team built the system on top of Bootstrap, the HTML/CSS framework created by Twitter. It proved incredibly successful. Within a few years it had been downloaded by internal developers more than 11,000 times and had been used to create hundreds of applications. It helped software teams across the company produce better looking, more consistent applications. And, perhaps just as important, it created a huge amount of visibility for the software team and the UX team at San Ramon.
With that success came some problems. To be sure, simply having a good UI kit doesn’t mean that a team can produce a well-designed product. Design systems don’t solve every design problem. And Bootstrap was showing its limits as a platform choice. It had helped the team achieve their first objectives: get something out quickly, provide broad coverage of UI elements, and create wide adoption by being easier to use than “roll-your-own” solutions. But Bootstrap was hard to maintain and update and was just too big for most needs.
In 2015, GE Software, having had great success as an internal service bureau, morphed into GE Digital, a revenue-generating business in its own right. Their first product was called Predix (Figure 4-9), a platform on top of which developers inside and outside of GE can build software for industrial applications. And with this change of strategy, the team realized they needed to rethink their design system. Whereas earlier the goal had been to provide broad coverage and broad adoption, the new design system would be driven by new needs: it needed to enable great Predix applications, which was a more focused problem than before. It needed to limit the number of UI choices rather than supporting every possible UI widget. It still needed to be easy to adopt and use—it was now intended for use by GE customers—but now it was imperative that it be easy to maintain, as well.
The design system team had by this time grown to about 15 people and included design technologists (frontend developers who are passionate about both design and code), interaction designers, graphic designers, a technical writer, and a product owner.
Figure 4-9. The GE Predix Design System
The team chose to move the design system to a new technology platform. No longer based on Bootstrap, the system has instead been created with Polymer, a JavaScript framework that allows the team to implement Web Components. Web Components has emerged in the last few years as a way to enable more mature frontend development practices.
To create the new design system, the team spent nearly six months prototyping. Significantly, the team did not work in isolation. Instead, they paired with one of the application teams, and thus were designing components to meet the needs of their users—in this case the designers and developers working on the application teams. This point is really important. Collaborative design takes many forms. Sometimes it means designing with your cross-functional team. Sometimes it means designing with your end users. In this instance, it was a hybrid: designing with a cross-functional team of designers and developers who actually are your users.
Figure 4-10. The GE Predix Design System on GitHub
Creating a Design System
As the GE story illustrates, there’s more than one way to create a design system, and the choices you and your team make should be driven by the goals you have for the work and capabilities at your disposal. GE is a company with a large enough budget to hire excellent consultants to get the effort started, and the resources to create and dedicate a team to the effort. Is that realistic for your organization? And what goals must your design system support? Is widespread adoption important? Do you need broad coverage from day one or can you build the system over time? All of these questions will drive the approach you take. With that in mind though, here are some common themes to consider as you create your own design system.
Characteristics of successful design systems and style guides
Whether you are creating a full-blown design system or a more limited style guide, consider these important characteristics:
> It takes into account audience needs
Remember that the audience for your style guide is the entire product team. Designers, developers, QA people, will all rely on the design system for their work. Include them on the team that creates the system and make sure the contents of the system reflect their needs.
Continual improvement
Design systems must be considered living documents. They must be a single source of truth for your organization. As your product evolves, so too must your design system. The design system should be malleable enough to add updates easily, and you must have a clear process for making these updates.
There is clear ownership
Assign an owner to the design system. This could be a dedicated team with a product owner, an editor, or curator who works with content creators, or simply a single responsible person, but it needs to be clear who is responsible for keeping the design system up-to-date. If this becomes a burdensome responsibility, consider rotating this role on a regular basis every three months.
The system is actionable
Your design system is not just a library or museum for user interface elements. It should be a “widget factory” that can produce any interface element on demand. As each new element is added to the system, make it available for download in whatever formats your team will need. Ensure that not only the code is available but the graphical and wireframe assets, as well. This allows every designer to have a full palette of interface elements with which to create prototypes at any given time.
The system is accessible
Accessibility means that the design system is available to everyone in your organization. Accessible design systems are: Easily found
Use a memorable URL and ensure that everyone is aware of it.
Easily distributed
Ensure that your teams can access it at their convenience (in the office, out of the office, on mobile devices, etc.).
Easy to search
A comprehensive and accurate search of the design system greatly increases its usage.
Easy to use
Treat this as you would any other design project. If it’s not usable, it will go unused very quickly.
What goes into a design system?
If it’s made of pixels, it goes into the design system. All interaction design elements should be defined and added to the design system. Use design patterns that work well in your existing product as the baseline of your design system. Form fields, labels, drop-down menus, radio button placement and behavior, Ajax and jQuery events, buttons—all of these should be included in the design system, as is illustrated in Figure 4-11, which shows the system for Salesforce.
Figure 4-11. If it’s made of pixels, it goes into the design system
Provide three data points for each interaction design element (see Figure 4-12):
What does the element look like?
Include detail about the minimum and maximum sizes of the element, vertical and horizontal constraints, and any styling demands on the element.
Where it’s usually placed on the screen
Make it clear if an element should be consistently placed in certain areas of the screen as well as any exceptions that might negate this design pattern.
When it should be used
It’s imperative that your team knows when to use a drop-down menu over a radio button and other factors that would determine the selection of one UI element in place of another.
Figure 4-12. A detail from the Westpac GEL design system
Next, include all visual design elements. Begin with the general color palette of your product. Ensure that each primary color is available with hex values along with complementary and secondary color choices. If certain elements, like buttons, for example, have different colors based on state, include this information in the description. Other elements to include here are logos, headers, footers, grid structures, and typographical choices (i.e., which fonts to use where and at what size/weight). The same attributes of what, where, and when provided for interaction design elements should also be provided here.
Finally, you need to codify copywriting styles, as well. Capture the tone of your brand, specific words you will and won’t use, grammatical choices, tolerated (and not) colloquialisms, along with button language (“OK,” “Yes,” “Go,” etc.) and other navigation language (previous/next, more/less, and so on).
Alternatives: The Wiki-Based Style Guide
Of course, not every team will have the wherewithal to create a design system. For teams that can’t justify the effort, you can still get a lot of value out of a wiki-based style guide. Here’s why:
Wikis are familiar places for developers. This means that getting your teammates in engineering to participate in this tool will not involve forcing them to learn a new tool or one that was purpose-built only for designers.
Wikis keep revision histories (good ones do anyway). This is crucial because there will be times when you might want to roll back updates to the UI. Revision histories keep you from having to recreate previous states of the style guide.
Wikis keep track of who changed what and provide commenting functionality. This is ideal for keeping a trail of what decisions were made, who made them, and what the rationale and even the discussion were for making that change. As you onboard new team members, this type of historical capture can bring them up to speed much faster, as well. In other words, wikis are your documentation.
Collaborating with Geographically Distributed Teams
Physical distance is one of the biggest challenges to strong collaboration. Some of the methods we’ve discussed in this chapter—especially Design Studio—become more difficult when a team isn’t all in the same location. But you still find ways to collaborate. Tools such as Skype, Google Hangouts, and Slack can provide teams with the means to collaborate in real time. Google Docs (including Google Draw) and purpose-built services like Mural.com allow teammates to collaborate on a document at the same time. Trello and wikis make it possible for teams to track information together. And a phone with a camera can make it easy to quickly share photos in an ad hoc way. All these tools can make cross-time-zone collaboration more effective and can help teams to feel virtually connected for long periods of time during the day.
Collaborative Design Sessions with Distributed Teams
Working on a geographically distributed team can make collaborative design more difficult. The benefits of collaboration are worth making the extra effort it takes to overcome the challenge of distance. Let’s take a look at how one team we worked with overcame a continent-wide separation and designed solutions together.
This team was spread into two groups in two cities: the product and user experience team was in New York and the development team was in Vancouver. Our goal was to run a Design Studio and affinity mapping session with the entire team.
Set up
We asked the two groups to gather in their individual conference rooms with their own laptops. Each conference room had a Mac in it with a location-specific Skype account (that is, it wasn’t a specific individual’s account—it was an “office” account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group. This visual element was critical because it was the closest we could get to physically being in the same room.
We prepared a very brief (roughly 10 slides) setup presentation that explained the problem statement we were tackling. It included customer testimonials and data, and a very brief recap of our customers’ needs. The presentation also included the constraints of the solution space.
Priming the pump with affinity mapping
We kicked things off with an affinity mapping exercise. Typically, these are done by using sticky notes and a whiteboard. In this case, we used a shared Google Doc spreadsheet to conduct the exercise, as shown in Figure 4-13. We asked everyone in both offices to sign in to the shared spreadsheet. The spreadsheet itself had a column lab
eled for each person. Google Docs allows multiple editors to work in the same document. For this meeting, we had eight team members in the document at the same time!
We asked the team to come up with as many ideas as they could think of to solve the problem we presented. Each team member wrote one idea per cell in the column marked with that individual’s name. We gave the team five minutes to generate as many ideas as they could.
Next, to make sure everyone in each location was aware of all of the proposals, we asked the team members to read their ideas to the distributed team. Some ideas went by quickly, whereas others generated more discussion.
Figure 4-13. Using Google Sheets for an affinity mapping session with a distributed team
To simulate affinity grouping in the shared spreadsheet, one member of the team, serving as a facilitator, began a second sheet in the document using a personal laptop. The facilitator created some initial column headers in the second sheet that reflected recurring themes that emerged from discussion.
Then, we asked the team to group the ideas under the themes. Everyone moved their own ideas into the theme sheet, and people were free to add new themes if they felt their ideas didn’t fit into any of the existing themes. At the end of this process, we had created a spreadsheet filled with ideas that were sorted into themes. Some themes had just a pair of ideas; others had as many as eight.