Courtesy NASA. Licensed under Creative Commons 2.0. Image Credit: T. Arai/University of Tokyo.

How do you reboot the culture of a global megacorporation? By design. When he launched IBM Design in 2012, Phil Gilbert’s ambitious goal was to reshape a megacorporation around user-centered thinking. The company had earned its size by solving real customer problems. But like many enterprise-focused companies, buyer needs often trumped user needs. Increasingly, users were insisting on consumer-grade experiences at work.

As a recent acquisition, we had shipped product designs that showed how to appeal to users. Now, Phil had secured a funded directive to scale our user-centric approach across the entire company. We needed to assemble an army of teams who could design and build great products. To do so would require an infusion of design talent, and an appeal to existing teams to focus on the user. I helped bootstrap the talent and education programs for this undertaking (while continuing to run my product design team by day).

Finding design talent

To address a talent shortage, we needed to hire at least 1,000 designers. I worked with Fahad Osmani to bootstrap the talent program. We arranged the first interview fly-down in December 2012 with help from Don Hogan, Emily Jester, and Maria Elavumkal.

The design interview: unnerving, just like a designer’s job

This was no generic interview day. We wanted to maximize our chances of identifying high-potential designers. Employing methods I learned from my former design manager, Craig Moser, we asked candidates to give a portfolio presentation to the group and complete a hands-on design assignment. This was in addition to their regular interview loop.

A designer must be able to present their work clearly and confidently, or it will never stand a chance of being built, Craig often said. It may seem a bit cruel to make a candidate present to the hiring team and all other candidates all at once. Yet presenting is an integral part of a designer’s daily job.

In fact, it would have been a more accurate assessment of on-the-job duties if we were to plant engineers in the audience to periodically interrupt the presentation with protests such as, “That can’t possibly work!”

Being able to present effectively is just the beginning. Designers can request years of engineering work with a sketch or two. Sometimes due to their own ignorance they ask for things that aren’t even clearly possible in any reasonable timeframe. Engineers naturally become defensive when handed a drawing of a skyscraper and then asked to build it in time for the next release.

A Workman on the Framework of the Empire State Building, making a design real. 1930. Wikimedia Commons. Public domain.

Designers must be able to give a thorough pitch, and then handle rebuttals, rejections, and occasionally even outright attacks — all while maintaining empathy for their engineering partners who actually make the dream real.

Sourcing candidates

I briefly played a recruiter early on when I accompanied Maria to Stanford in January 2013 to open up our recruiting efforts there. Shortly after arrival, we were setting up for an evening information session and she prodded me to go talk to some of the students who were filing in. I was not feeling very outgoing, but I swallowed my anxiety and started working the room. Soon I was engrossed in conversation, and she had to pull me away so we could start the session a couple minutes late. That is how networking goes: it’s always hardest the moment before you begin.

We met many great candidates, and some of those people were eventually hired and became key contributors.

Convincing product teams that design actually works

Many existing product teams were skeptical of design and some were outright hostile. We approached the problem one team at a time, inviting a cross-section of product managers, designers, and engineers to a multi-day Design Bootcamp. Working alongside incredibly talented design leaders such as Adam Cutler, Charlie Hill, Douglas Powell, and joe meersman, I developed and taught sessions on playbacks and agile design and development.

Playbacks: Who, What, Wow

When we show work, we call that a playback. But what exactly are we playing back? A story, acted out with user interface. In bootcamp sessions, some teams realized they had been reviewing bullet points, project plans, or architectural diagrams, but not looking together at the actual user experience.

A great playback is story-driven. It depicts a person with goals and shows how the user achieves those goals by interacting with a user interface. It leaves the viewer with a shared sense of accomplishment. It contains a “pit orchestra” of features, which are essential to the story but don’t scream out for individual attention.

The playback should tell a believable and gripping story and create an emotional connection with the viewer. To assess this, we ask questions such as:

• Is this story 10x better than before?
• Is the story coherent? (Was I lost at any time?)
• Is it compelling? Do I want to buy this?
• Do I want to use it?
• Did I have a “wow” moment?

When we don’t like the answer to any of these questions, we iterate and play back again. Early on, the UI is most likely wrong. Showing it early and often exposes the wrongness so it can improve. These iterations can happen very quickly and greatly increase team alignment and user experience.

Design Thinking vs. Agile Development: Who Will Win?

In our agile sessions, engineers readily expressed skepticism that design and its penchant for post-it notes could actually solve serious problems. As a hybrid with deep engineering experience who had recently entered design, I anticipated this. So I began by sharing the 12 principles of the agile manifesto, in all its Bard’s Tale glory. Good design is right there in principle #9:

“Continuous attention to technical excellence and good design enhances agility.” — Agile Manifesto, Principle #9

We went through the principles together and found that design aids nearly every one of them. Still, one concern arose frequently:

“Doesn’t upfront design just lead to waterfall?”

If you make a big design upfront and then treat it as a contract, then yes. So don’t treat it as a contract!

Upfront design can powerfully enhance strategy when used as a vision statement and not as a contract. This requires trust. Designers and leadership must trust that engineers are working toward the vision. Engineers must trust that management will not use the design as a punitive measure against them if they miss a date.

Design used upfront as vision is exactly what agile product teams need. In The Truth of 10X, Joe Emison writes:

But what the vast majority of senior executives that I speak with haven’t learned yet is that Agile has made it incredibly easy for those executives to be very lazy with respect to making hard choices and setting focus. […]

“The reality is that successful organizations (and executives) are always making hard choices and setting focus — and, in particular, setting focus that isn’t 2–3 weeks out, but rather years out. Agile is wonderful, but it won’t get you what you want if you don’t yourself have a clear vision of what you want and a staff aligned and focused to reach that vision.”

Design can clarify that vision. Engineers should participate; some of the best ideas come from engineers and are clarified by the craftsmanship of great designers.

But designers can’t just pump out a vision and then check out. Designers must work alongside engineers on a sprint-by-sprint basis, validating and adapting their designs in response to feedback, and playing back changes continually.

Leveraging Sponsor Users

In my design career-change story, I mention work I did with clients to validate a product design. This work led to direct revenue impact and was featured as a case study in our early internal training materials on Sponsor Users.

So what is a sponsor user? A client who represents what real users need and can help you validate a design. You might be able to wing it if you’re designing a product you use yourself. But in specialized products, it is critical to engage with sponsor users and tap into their domain expertise in order to really validate your designs.

Liftoff

Soon, thanks to Fahad, Doug, Adam and others, the talent and education programs were in orbit. I was offered a role as a Front End Development Principal on the team. But seeing an urgent need, I instead accepted the challenge of leading design for the team that would launch our public cloud platform. Of that effort, the New York Times later wrote:

If you ask people inside IBM for a design-thinking success story, they are likely to mention Bluemix, a software tool kit for making cloud applications. In just one year, Bluemix went from an idea to a software platform that has attracted many developers, who are making apps used in industries as varied as consumer banking and wine retailing. In the past, building that kind of technology ecosystem would have taken years.

In future posts I’ll describe how we exerted design to shape that effort, redesigning the company itself in the process. We continue to stress-test design thinking at scale and it continues to prove load-bearing.

What struggles have you faced while building a design program or transforming a product by design?

—

Read the prequel: how I became a UX designer, and the product effort that preceded the launch of IBM Design: