In our webinar, How IBM designs for a global market, IBM Design Language Lead Hayley Hughes talked about changing the way IBM thinks about branding its products and her project to improve design across its portfolio. The company has been embracing concepts like flexibility and unity in place of more traditional, rigid and dogmatic design practices for establishing brand identity. Afterward, she answered your questions about bringing about this new way of thinking.
You mentioned this idea of “unity, not uniformity” as a central tenet of your design philosophy. But that can be very difficult to sell because the traditional thinking around corporate image is that it's more like a closed box. How did you sell this new approach?
I had the good fortune of having a lot of support from my design manager and our general manager. One of the things IBM is doing globally, across its entire business, is focusing on human-centered outcomes and making sure that when we’re thinking of anything (including our new hiring processes or how we evaluate our employees), we’re putting people first. And that’s been really essential when making an argument for unity. If we were to be hard-headed about the brand and say that our corporate image is more important than our users, that wouldn’t actually be true to IBM’s values. Part of it is to make sure that the belief system, and that the way that your company talks about its employees and who they serve, is reflected in the outcome.
So we needed to make sure that our designers had enough flexibility to design in context of the user’s real world, no matter who they were or what country they lived in. We also had to consider their cultural norms and expectations around how the software behaves, like what different colors mean, for example. So that’s why that flexibility is so essential: it means you can be more relevant and essential to your clients and your customers.
Who within IBM launched this initiative and sold the setting aside of such a large budget and team?
Our Head of Design at IBM, Phil Gilbert, first commented about the need for guidelines to ensure high quality in our product design across the board. The idea was that if you could put all of IBM’s work up on the wall, step back, squint, and see one company, it would pass the test. But we didn’t just align the look and feel of IBM. We also aligned our expectations of the experiences we want our designers to create. The idea of creating a design language came from Distinguished Designer Adam Cutler, who understood that creating a consistent set of coded patterns and giving them to teams was not the goal. He drove the focus on using guidance as a way to inspire people to think about doing great design, as opposed to just handing out assets and expecting people to know how to use them.
With such respect given to the flexibility aspect, how do you supervise the final result of a product across so many different teams, given the freedom they're allowed?
At this point, when I do reviews with teams, the expectation is that there will be a human-centered story they're going to tell me, and their designs should reflect it. I look at the way they’ve expressed the personality of the product, at how they've applied it to the functionality, and whether they've integrated good design practices—such as the right type scale or enough spacing and hierarchy.
About once a month we have these things we call playbacks, which are opportunities to align with the teams and have them share their work with us and receive feedback. There's no specific format—we offer recommendations for improvement and offer our time to help them where they need it most, especially when they’re working towards a release. But other than that, we like to give them autonomy so they can make sure they’re serving our user. We’re fortunate to have a lot of highly skilled and capable design talent who provide a lot of critiquing and work with the teams to ensure quality in the visual and UX design. Teams have their own design leads and design executives, so design is being invested in at many different career touchpoints across the company. There’s also a large-scale effort to make sure our front-end developers have modern frameworks and practices in place and that they're applying those to their prototypes and then delivering that into production.
Have you had any difficulty drawing in non-designers and ensuring others within IBM are on brand?
We hired one of the first (to my knowledge) executive-level designers at IBM on the marketing side, and, more importantly, the brand side of our corporate look and feel. This has allowed us to work more closely with our marketing team, and in turn they’ve leveraged our digital color palette, typeface, and other design elements for branded events, websites and similar touchpoints where our users and clients see our brand. Our security team, for example, has worked with its marketing group to figure out how they can scale out our design guide, not just for products, but for social tiles, posters, advertisements and larger events.
How long did the design language project take you, and how did you maintain team morale and interest working on it for so long?
The project started around the fall of 2013 and I started working on it in March of 2014. So we’ve been focused on this for about two full years now and getting closer to three.
We try not to lose touch with what the product teams are working on, so we'll get together often to think about different events we could create to engage with the teams more meaningfully. Recently we created a cross-pollination session, which involved panelists from all the product teams that were creating front-end design style guides. Anyone can ask them questions, including people who are newer and just learning how to build out a front-end style guide. I think having a lot of diverse perspectives and different people involved has helped morale and kept things from getting stale.
How do you keep the system live and consistent over time? Is it simply the fact that you’ve managed to integrate it into a CMS platform now? Or is there more to it than that?
One of the bigger challenges has been making sure that when we put something out there, people can access it easily and quickly. From what I’ve observed, it probably takes a good three to six months to really see how a particular design aspect works, like the iconography, for example, or the pattern library. So you can’t change it too quickly, because if you evolve it too fast, there isn't a chance to try it out properly.
We use GitHub to help with our workflow and we have teams note their issues in there. We also have a Slack channel specifically for the IBM design language that has well over 300 people constantly commenting, and that's been great. Having a crowd-sourced community allows for other people to come in and answer questions, instead of just the team.
So those are some of the ways that we’ve tried to maintain some consistency. Consistency is necessary for a while, so your product teams can test things out and see where they break. Then we try to evolve it. They are also our best resource for challenging any assumptions we may have, because they are the ones testing things with users.
Was your icon design influenced or informed in any way by the custom font design? If so, how?
The icon designs were inspired by blending the science in our engineering heritage with the art and soul of our brand communications. Helvetica Neue for IBM is a typeface that represents the precision, accuracy and objectivity of the message it communicates. It’s timeless, and we used that principle to really drive the evaluation of the style for our icons. Could they still look and feel like IBM decades from now, whether we choose to evolve them or not? Practically, we also analyzed the weights of the font to determine an appropriate lightness or heaviness to the icons so that whether you were using a light or bold version of Helvetica Neue, the icons would possess an obvious relationship to the type.
The design language is online, but is there anywhere public that your design team blogs about best practices or the challenges that you’re trying to overcome?
You know, that’s a great question. We have done a few blog posts on our IBM Design homepage. I’ve probably posted a few times myself along the way, when we’ve had major updates. We are really interested in sharing more stories and lessons learned, and our stories team is looking at platforms like Medium as well, so stay tuned for that.
You talk about a desire to “humanize experience”? Can you explain what you mean and some of the things you did to humanize experiences through visual design?
Humanizing the experience of our products means getting to know the people we design for. In the past, IBM engineers used to be able to walk down the hall and ask another engineer about a product they were coding without having to talk to the person that would actually be using it. This was because lots of what IBM made was IT software. With a focus on cloud, mobile and cognitive technologies, IBM isn’t just making products for technical developers anymore. Part of the way the IBM Design Language takes this into account is ensuring a flexible color palette that can be applied to different use cases. Another consideration is focusing on the clarity of the user interface design and front end, where someone with less programming knowledge can be given as much control over their work as a person whose capable of building the tool. But humanizing the experience is not merely about making products, just like staying in a hotel is not just about the bed. It’s about hospitality—a tone of voice, a warmth to the spaces, how the door opens and closes, that give you a sense of authenticity and thoughtfulness in the details of a design.