| By Gabe & the User Experience Team |
In our last post, we illustrated the problem of having products with different experiences and how the UX team started the conversation towards fixing that problem. Our solution was to create a comprehensive design system for all Gale products to follow. Now, we move on in Part 2 to how we created our design system. In particular, we’ll look at the tools we used to build it, how it’s impacted our design, and provide a preview of the design system itself.
Selecting the right tool for the job
To review, a design system is a collection of standardized, reusable user interface (UI) components and interaction guidelines to be used across the organization’s products. Typically, designers create the initial design system, but ultimately it’s the full team, including product managers and developers, that are responsible for updating, implementing and maintaining the design system in support of the unified user experience.
Designers have a wide selection of tools available when it comes to visually defining UI patterns and we chose Sketch. We liked Sketch’s vector-based illustration capabilities, ability to create reusable component libraries, and version control functionality (through a plugin). Now let’s take a close look at each of these features and how it helps us.
Vector-scalable images allow us to create graphics and icons at one size and easily re-scale them without losing quality. These images can be used in place of standard image formats like PNG or JPEG which don’t scale well. The benefit is that we create the images once and then the developers can make it any size or color they need through code.
Reusable Component Libraries
Libraries are perhaps the most valuable feature in Sketch for the purpose of creating a design system. In Sketch, designers can create a UI component – let’s say a button – and then mark it as a symbol. This creates a master copy of the button that can then be placed in design mockups. The real magic is that if the button styling changes, it only needs to be updated in the master copy and then those changes automatically appear in all of the mockups. With these reusable components, the UX team can build out a complete library of UI components that can all be updated from a single place. This means we don’t have to make changes to every single button any time a font or color is changed and saves us a lot of extra work.
Finally, with a plugin for version control called Plant, each member of the UX team can make changes to the design system simultaneously. This means everyone can contribute without fear of affecting each other’s work and, if by chance two people work on the same part, the version control helps sort it all out.
Bridging the gap between design and development
Having the design system in place now makes it easy to know what to do when we encounter a non-conforming component. One of three things can happen:
- Developers swap in the design system code for that component
- If the code isn’t there, developers build the component to match the design
- If the component isn’t part of the design system yet, the UX team designs the component for developers to implement
Get a first look!
After so much discussion of why and how we have built a design system, it’s time for a preview of what we’ve made so far. We will share screenshots from our files showing some examples of buttons, form controls, and icons that illustrate different types of content found in our products. The images shown here make up some of the components that we designed and tested in early development phases.
The design system is now a living piece of our design and development process. We’ll continue to both expand the pieces in our design system and get them implemented in product. While the UX team leads the effort, the entire organization makes it possible. Our system has been in use for the past six months and it’s already become part of everyday development. It’s taken a lot of time and effort, but the benefits are already clear and the vision of what lies ahead is even better.
Up Next: In Part III, the UX team will give a complete overview of the design system as it stands now, focusing on the reasoning behind our designs and how they benefit the user.
Gabe Pompilius | UX Designer Jamie Smylnycky | UI Developer Kyle Stewart | Senior UX Researcher Thomas Piggott | Senior UX Designer
Gabe is the newest addition to the UX team. He has done a lot of research and design work on concept products as well as existing Gale archives that are part of an upcoming migration project. In his spare time, Gabe likes to cycle and go camping around Michigan’s Great Lakes.
Jamie is a designer-developer hybrid. Because of her eye for visual design and her command of HTML and CSS, Jamie is the principal developer of the user interfaces for Gale products. In her spare time, Jamie creates and sells her own artwork. She is also an avid gamer.
Kyle is a veteran Gale employee and leads UX research at the company. In addition to his research efforts, Kyle has pioneered Gale’s accessibility initiatives to ensure our products are WCAG-compliant. In his spare time, Kyle enjoys reading and playing card games.
Thomas is a UX Designer at Gale and has lead the design of the Digital Scholar Lab along with redesign initiatives for Gale.com, GVRL, and the OMNI product platform. In his spare time, he likes to travel to far-away lands, where he tends to encounter tropical storms that delay his return.
Gabe Pompilius | UX Designer
Jamie Smylnycky | UI Developer
Kyle Stewart | Senior UX Researcher
Thomas Piggott | Senior UX Designer
2 thoughts on “Cooperative Design <br><small>Part 2: Implementing a Shared Vision for the Gale Design System</small>”
Speaking of design, I just had a custom mascot for my school printed on a bunch of visitor passes!
Now, that is cool!!