Cooperative Design
Part 1: Finding a Common Language in the Gale Product Suite

| By Gabe & the User Experience Team |

Since 1954, Gale’s mission has been to empower learners and serve libraries with the tools their patrons need. In that time, our suite of products has expanded to meet the evolving needs of the research and education market. We now manage over 160 digital products and platforms. As the number of products grew, so did the number of interfaces, platforms, and experiences. One of the outcomes of this growth ended up being design discrepancies across products and, ultimately, a less-than-ideal experience for users.

In this post, Gale’s User Experience (UX) Team will look at how product growth has impacted design and how the team saw it as their responsibility to develop a comprehensive design system to unite the experience across products.

Illustrating a Problem

Over the past few years, Gale has moved to consolidate products onto a single modern platform known as OMNI. This allows for better utilization of features across products and a reduction in maintaining multiple platforms and interfaces. As this shift progressed, inconsistencies between products became more obvious. We often migrated features exactly as they were on the old platform, which led to identical features looking or functioning differently between products. Witnessing this breakdown helped us realize the need for a design standard so that developers no longer had to guess how features should work on OMNI. Instead, they could refer to the design system and feel confident that their implementation would be consistent with the overall experience of our products.

To illustrate these cross-product discrepancies and the impact they have, let’s take a look at the difference in browse functionality between Academic OneFile and Opposing Viewpoints In Context. Both products live on OMNI and have similar use cases for instructors, students and researchers.

In Academic OneFile’s browse feature, high-level categories (academic disciplines in this case) are displayed as buttons. Clicking one of the buttons reveals a relevant list of topics. In turn, clicking a topic returns a page of related search results. In contrast, Opposing Viewpoints In Context uses a drop-down menu for its categories instead of buttons. Once a selection from the drop-down is made, a list of topics is shown, just like in Academic OneFile. However, clicking a topic from this list returns a portal page that provides an overview on that topic along with sample search results bucketed by type.

So, the two major differences are how you select categories and what happens once a topic is selected. We’ve set our users up for a bad surprise and some confusion if they switch between products. Now our users must learn two different interactions and remember which product behaves which way. This is problematic because research tells us users expect consistency. Without it, task completion rates fall, time to completion increases, and the user experience suffers.  

Now, let’s explore how developers are subjected to unnecessary effort because of how the design is maintained. We can use the Advanced Search feature as an example.

Imagine that Advanced Search in Opposing Viewpoints In Context calls for unique styling and an added piece of functionality. That would require the developer to add code specific to that particular product instead of at the platform level. This essentially creates a second instance of the Advanced Search feature that now also needs to be maintained. A good example of why this is a problem centers on Gale’s drive to improve accessibility. If we need to update Advanced Search to better work with screen readers, we now have to do it in multiple places: at the platform level and any product that has a unique implementation. So, when considering product features, we must always be aware of how it fits into the design system. If it fits, great, and if not, is there enough value to the user to take on the burden of inconsistency and additional maintenance. Of course, we still want to have product-specific features where it makes sense, but we want to be intentional about it. Without the design system in place, it’s easy to see how a few small changes quickly add up and become unmanageable.

At its core, the design challenge that Gale faces is about agreeing on a vision, planning for the future, and arriving at a common language for talking about design and development.

Building Stakeholder Support

“Design is the rendering of intent.”

– Jared Spool

Jamie Smylnycky, Gale’s UI Developer, was initially inspired to implement a design system after attending An Event Apart, an interaction design conference, in August 2017. To do so, she knew it would require building mutual understanding between many different stakeholders with diverse responsibilities and priorities. Jamie began seeding interest in the idea by presenting at the weekly lunch-and-learn session on CSS (Cascading Style Sheets is a style sheet language used for describing the presentation of a document written in a markup language like HTML) hierarchy in Gale products, many of which are several years old and built on top-level style sheets. The focus of her talk was that as Gale rolls out new products, existing code will get repurposed and over time style sheets will pile up, leading to frustration for developers as they grapple with growing inconsistencies across products. This was the spark that lit the fire.

Over about a 6-month period, Jamie and other developers gave more public talks about different aspects of streamlining the product development process. As momentum grew, more internal stakeholders began relating to the problems for which a design system offers solutions. The Product Managers, deeply in-tune with customer satisfaction, kept hearing from customers about the value of consistency in how products look and function, because of the wide set of products they have from Gale and other vendors. In the same vein, the Sales Team relies on customer satisfaction to close deals and keep subscriptions intact, Content Strategists depend on the backend architecture of our products to render content in the user interface, and leadership has a vested interest in streamlining employee efforts.

The usability expert Jared Spool coined the phrase, “design is the rendering of intent,” which is to say, design is relevant to everyone in an organization whose efforts are to be realized. By starting a conversation, the UX Team helped the many contributors to Gale’s success find common ground and a way forward.

Up Next: In Part II, the UX Team will explore the process of creating the design system with specifics on how it’s being implemented.