CREATING A DESIGN LANGUAGE AT SCALE
In 2013, I started working at a very large, century-old tech company. They set out to hire 1,000 designers in five years and I was one of the program's early pioneers. The problem: IBM was caught between its legacy in engineering and the demand for a more human approach, and the company found itself in need of a design overhaul. Their solution: create a sustainable culture of design—and by doing so, infuse an empathetic and radically collaborative way of working into IBM's DNA.
At IBM, we create thousands products that touch industries ranging from healthcare and finance to transportation and government. My job was to create a unified design language to modernize IBM's enterprise software. The challenge: bring cohesion to software design not through rigid guidelines, but through an approach that embraced creativity and gave newly hired designers the flexibility to adapt the language for unique use cases.
Languages are living systems. They evolve over time and are responsive to change. Like the grammar, diction, and syntax of a written language, design languages have principles, elements and contexts. These parts work together to create holistic meaning and intent behind a design.
All IBM product teams, business partners
Design lead, team of 20+ creators
Concept development, generative research,
user experience design, writing
My team's process is documented
via Monotype webinar. For additional
details, explore the article and interview.
It was important to break bad habits formed in the absence of good design.
For quite some time IBM products had been stuck in a late 90's time warp that we desperately needed to get out of. All you had to do was look at the software we used inside of IBM day in and day out to see that our UI patterns were out of date.
Everything looked exactly the same: blue, skeumorphic, all in a light box or table. What’s more, there was nothing uniquely IBM about anything—no defined color palette, typography, consistent iconographic style, etc. Before I started working on the project, IBM had a component library called One UI which enforced consistency. It was so rigid it required engineers to use the same development framework.
Developers plugged and played with hundreds of pre-built widgets, leaving designers out of the product development cycle. We decided it was important to start fresh and make a framework-agnostic design language to break bad habits formed in the absence of good design.
There were too many engineers focused on the machine.
It wasn’t hard to justify the need for design. At IBM's scale, there were too many engineers focused on the machine and not enough people focused on the people. We had a number of obvious problems that when you boiled them down fell in to three categories: visual design consistency and quality, UX quality and brand personality. For each of these key problems, we worked to identify the source of the problem, and then used that information to shape the goals of the project.
Elevate the understanding of software design as a craft.
Ensure designers have a seat at the table and can influence product outcomes.
Make our products easier to use by humanizing the experience.
Express our identity in-product in immediately recognizable ways.
It didn't make sense to limit our work to role-based personas like "manager."
When designing for everyone, our research lead us to prioritize the archetypal needs and behaviors of our users. It didn't make sense to limit our work to personas for particular roles like "designer" or "manager." We wanted to make the site accessible to the largest audience as possible—keeping it open and public for third party service providers, acquisitions, and other business partners who don't use our intranet.
We geared the guidelines towards a learner—someone coming to the site to get up to speed on software design practices and IBM-specific branding guidance. We optimized resources for the crunch-time creator—someone in the middle of a release cycle for their work who's under pressure to produce quality experiences. Lastly, we created a "look book" or mood board of UI screens aimed to give someone contextual inspiration when looking for examples of the design language in real use cases.
We needed to answer five questions in order to create a design language.
In developing the Design Language, we observed users, reflected on the problem we were solving, and made prototypes to continually test our work.
We created scenarios, concepts, and user flows with pen and paper to quickly collect feedback and critique. To stay aligned, we created a framework of five questions we needed to answer in order to create a design language: What came before? What could or should be? What is the thing? How does it work? How might it evolve?
Each study and sketch got us closer in fidelity to the desired experience, until we moved into developing the site wireframes. The sketches helped us curate what the site should look, sound, feel, and work like.
The website's visual narrative was an online maker space filled with powerful tools.
IBM's design history dates back to the 1970s—when Design Director Eliot Noyes hired architects, designers and visual artists like Charles Eames and Paul Rand to help bring IBM’s identity to life. We took inspiration from the patterns, bold color blocks, and chunky geometric shapes of the time period, but applied them with modern design principles—"continuous momentum", "as little design as possible", and "defer to the content."
The visual narrative for the site revolved around the concept of an online maker space filled with powerful tools for your work. We wanted the tone and voice of the website to sound like the friendly shop owner—a kind and clever expert who doesn't get in your way, but helps you create your vision behind the scenes.
Adding objective opinions helped build trust and reinforced our user-centric intent.
Asking designers to adopt a design language in a large company can feel intimidating to those who may not participate in the process. While we co-created with design teams globally, not everyone knew our approach. This meant we had to be very deliberate in how we recognized the people behind the pixels.
Instead of sharing videos of the design language creators, we recorded short testimonials of designers who adopted the design language. Unscripted, designers in their daily work could speak directly to its benefits and limitations. Adding objective opinions helped build trust in the design language and reinforced its user-centered intent.
machine motion metaphor
Our hardware had unique movements that could inspire how our interfaces move.
On a research visit to our "Museum of Machines" in Germany, we found that our old hardware shared a set of unique movements that could inspire how our interfaces move. In defining the motion style, we observed how the machines’ motion relayed their functionality, just like the use of animation in software products aims to enhance its usability.
We recorded our mainframes, magnetic tape reels and typewriters sliding and spinning as reference material. Then, we looked for screen transitions, components and micro-interactions to translate the metaphors into UI motion. Each video gives a side-by-side comparison of the concept and its implementation.
Anecdotal feedback was not the only way, or even the best way, to prove business value.
While stories are great, we realized that anecdotal feedback is not the only way, or even the best way, to prove business value. A new way we measure our design language is through a net promoter score to the site. If you peruse the site, you’ll see a smiley face icon on the left side of your screen as you scroll down.
Anonymous ratings and feedback people provide on the site give us an honest look at our strengths and weaknesses. Some feedback we receive comes from clients, who tell us that they are asking IBM sales teams to create products inspired by the design language; it lets us know we're successful at creating outside-in demand for quality experiences.
We needed to provide data visualization guidance in the IBM Design Language.
At IBM, many user experiences with data live in a spreadsheet-like environment. The static reading of rows and columns in a data tables is not conducive to dynamically gathering insights. As a result from research with product teams, we discovered that the we needed to provide data visualization guidance in the IBM Design Language.
For 9 months, I lead a project working side by side with data visualization designers to imagine and create a new set of guidelines to help employees from all over the world design innovative and effective data-driven products that look and perform like IBM. The guidelines include practical instructions, original designs, animation samples, and interactive examples.
All strategic products at IBM have adopted the language at varying levels of fidelity.
All of our strategic products at IBM have started adopting the IBM Design Language at varying levels of fidelity. At least a dozen of our larger product portfolios like Security, Watson, Cloud, Commerce and Analytics created "child" front-end style guides based off of the "parent" design language.
Each team has dedicated people and places for hosting all of the product components, marketing materials, etc. Each business unit takes on their own industry-relevant topics like, “What does a data-driven experience sound like?” or “What does a cognitive health experience look like?” I look at these guides for common patterns and things we can repurpose or directly contribute back to the IBM Design Language.