Adam Cutler is a founding member of IBM Design and one of the first three Distinguished Designers at IBM. Now focused on designing for AI, he was previously responsible for the competency, culture and practice of design at the company. In a recent episode of Design Chats, a Pragmatic Institute podcast, Cutler spoke about how he gets buy-in for design from clients, how designers can more effectively advocate for their work and more. Read excerpts from the conversation below.
(Note: This interview has been lightly edited for clarity and length.)
Q: In your 21 years at IBM, how has design evolved at the company?
I almost quit my job at IBM at the end of the first week I was there. I finished my training, went and met with users in New Jersey, and when I got back to Boston, there was a team already coding a solution.
I went over to them and said, “I’m curious what you’re coding, because I just got back from talking to the user. If I’m the first person to talk to the users, what are you making?”
This engineer looks at me, not joking, and says, “Oh you have it all wrong. You’re just here to make things look pretty on the way out the door.”
At that moment, I thought, this place isn’t for me. But I couldn’t just quit and go find another job. So I decided to approach this problem I was facing as a design problem. What I realized was people didn’t understand design. They equated it to visual design or graphic design—font choices or mockups in Illustrator or Photoshop.
I had to get the point across that design is about addressing a deeper human need. It’s about understanding what people need to be successful and then architecting a solution around what those people need—versus the misconception that we should build technology first and then just try to make it look good and work well after the fact.
So I found more people to listen and see the reason behind what I was trying to do, explaining that design isn’t about what it looks like on the outside; it’s about the reason for existing on the inside.
When I was in the consulting side of the business, the clients didn’t necessarily know that they wanted or needed design. My objective was always to change the entire direction of the conversation to get everybody talking about design as opposed to some technological wonder.
I had built up my reputation for being able to get across why design was important to our clients. More people who weren’t connected to consulting were coming to me to ask about design. Eventually, Phil Gilbert was named the first general manager of design for IBM, and my name was brought up, which opened the opportunity to create IBM Design as a formalized movement inside IBM.
I was the first designer in the program, and my job was to help bridge the gap between all the different parts of IBM because I could speak the language other departments spoke. There were a number of people from different parts of the business that came together and we brought unique perspectives.
People who are told to “just make it look pretty” feel like they are in a fight, and they approach advocacy as a fight. You’re never going to change minds by fighting. It’s about how to articulate the message properly.
We were just lucky enough to have the right people in the right place at the right time. We were just audacious enough to pull off building one of the biggest standalone design competencies in the corporate world. In my wildest dreams, I couldn’t imagine where we’d end up today when we started in 2001.
Q: What advice would you give to designers who want to advocate for design in their company as they face similar challenges?
People who are stuck in the design box—placed at the end of the line and told to “just make it look pretty”—feel like they are in a fight, and they approach advocacy as a fight. You’re never going to change minds by fighting. It’s about figuring out how to articulate the message properly.
One of the things I learned early on, as it related to software (or whatever the problem was at that moment), was not to talk about the software. That opened the door for them to say that I didn’t understand the business, the industry or what they were trying to do.
I took a different approach. I started by talking about their homes. Specifically, the things they put in their homes like vacuums or coffee cups. I told them there was probably a reason why they chose one over the other. Additionally, I talk about that one thing in their house they can’t stand, and how they’ve been looking so hard to find the perfect replacement.
The purpose of this detour was to take the focus off of software to get them to understand that they do care about design because it’s everywhere. Then, they relax a little bit and they don’t know exactly where the conversation is going. They showed up to talk about software and now they’re thinking about vacuums and coffee cups.
Next, I introduce psychology and explain that human needs don’t change, but the tools we make to serve those needs change all the time. There’s progress and there are better ways of solving for that problem.
Then, you just say that people just want “it” to work. Whatever “it” is, there is an expectation that it should work, and they don’t care what you have to go through to get there. They don’t care about your org chart or department politics—all they care about is that the thing they are interacting with does the job that it’s supposed to do.
What do designers do? They understand what “it” is the users expect.
If I am in a room [with stakeholders], there’s an activity I recommend that’ll change everyone’s mind in six minutes:
- I set a timer for three minutes, and I ask everyone to draw a flower vase on a sticky note with a marker. (Of course, there is instant feedback telling me how they can’t draw etc. So I say to describe it, write a poem, or do your best).
- During that time I drew three common vases. I tell everyone to stop and hold their drawings over their head. Then crumple them and throw the sticky note on the floor, because I don’t care what they drew and it probably looks like one of the three common vases. (I also apologize if it was something unique or exciting.)
- Finally, I tell them to take three more minutes and design a better way for people to enjoy flowers in their homes. You can hear everybody’s skulls cracking open. They just learned an important design lesson in six minutes.
They learn some basics of design thinking, and they learn how to reframe a problem. When we complete the activity, everybody is excited to share their ideas.
What we also learn is people on opposite sides of the room, who aren’t collaborating, come up with similar solutions. Additionally, there are ideas that are different but together are wonderful solutions. Most importantly, this activity teaches the power of exploring the possibilities behind a solution.
This activity loosens everyone up, so you can start asking questions like, “How much do you know about your users?”
Advocating isn’t about fighting for your position as a designer or the importance of design. It’s about, in some ways, tricking people into understanding that it isn’t as bad or as fluffy as people might expect it to be—there is a purpose. When they see the patterns, they’re much more willing to collaborate.
Finally, to be a strong advocate you have to be good at the craft, which is much more than just design thinking, or we’ll find ourselves playing right into the stereotype.
Q: How do you approach roles and responsibilities on design teams, and what makes a good IBM designer?
When you look at design through the lens of roles and responsibilities, everything gets provincial, and it’s not just our domain as designers. I will argue some of the most creative and thoughtful design responses have come from software developers and engineers.
Making sure we are not locking responsibilities into a role makes it easier for us to work together. Everybody is co-opted into the design process.
We made a decision at the beginning of our program at IBM to strike the word “creative” from any job titles. After years of being pigeonholed, designers might hear things like, “That’s the creative team’s job.” It’s just patently untrue. Everybody is creative.
Making sure we are not locking responsibilities into a role makes it easier for us to work together. Everybody is co-opted into the design process. It doesn’t matter what your skill set is or what it says on your business card. It matters if you can work together. It is helpful to have a team where people can recalibrate based on what somebody else is bringing to the table.
There isn’t a one-size-fits-all answer to what makes a good design team. So when we were figuring out what it meant to be the type of designer for IBM. It was more about searching for that person who’s looking for the intent behind the things we make. That first cohort on the team was finishing either a graduate or undergraduate design degree. And we just wanted them to be articulate and convincing when presenting their work. We also wanted the quality and craft of their work to be good.
The first group was eclectic, so we couldn’t necessarily say any of them were the IBM designer. Instead, it was the mixture and how they worked together coming from all these different programs.
We are trying to find individuals whose aptitude is to understand a deeper problem and have the ability to say something about it with respect and still be able to disagree when the problem is stated in a way that is different than how the problem is understood.
We started to get a sense of what we needed to be successful, and one of those things is the lone-wolf designer was not something we desired. IBM is too big. This type of lone-wolf designer furthered a stereotype we were trying to eliminate, which was “Don’t worry about it. Leave it to me.” We needed team players.
There isn’t one design team at IBM and there isn’t a centralized design function. I’m part of the design program office and our job is to make sure that design propagates throughout the company. Others are on a product team, so they are helping with software. Then, some are working in the office of the CIO, in research and the consulting side.
But we are trying to find individuals whose aptitude is to understand a deeper problem and have the ability to say something about it with respect and still be able to disagree when the problem is stated in a way that is different than how the problem is understood.
Q: Designers often advocate for their work to business professionals. How can designers better understand the business perspective?
We have a few different programs and publications that we make available to our designers. One of them is called the Business of Design. And it’s getting them to understand how IBM’s business operates and where they fit in. It also helps them understand the basic terms and ideas behind how the business runs and how design plugs into these spaces within the company.
We also encourage curiosity and make ignorance okay so that if you don’t know something, you feel confident to put your hand up and ask for an explanation.
It’s an environment where you don’t have to pretend to be something that you’re not. We want it to be okay to say, “Can you teach me the basics of this, so that I can bring what I know to what you know?”
We actually start all of our designers as a cohort, regardless of where they are on the planet, regardless of what their discipline within design is. They all come together on the same day, and go through training for 12 weeks.
We try to teach them what they need to know to be the best IBM designer they can be before they actually join the team where they were going to do their actual work. One thing they learn is teamwork, because design school is a solitary sport. It’s not about getting the best grade in the class anymore. It’s about everyone crossing the finish line at the same time and with similar quality.
They learn several things beyond teamwork, like accessibility, design thinking and exposure to real business problems.
The benefit of this cohort style is they are able to make these friends across the company to whom they feel comfortable reaching out when they have questions. This approach makes it so much easier for our designers to thrive.
This training at the beginning of employment gives the new hires a running start. They aren’t joining their team at a standstill; they understand the pacing and what’s being asked of them. There is still an onboarding process because their team will have its specific culture and purpose.
I think it is very important when a new designer joins the team, they have the confidence to contribute. It also takes the strain off the receiving team or the team that’s bringing the designer on because they don’t have to get them up to speed, they just have to show them what’s specific in their department.
* * *
If you’re a designer looking to better understand the business perspective, advocate for your work, and speak the language of your stakeholders, enroll in Pragmatic Institute’s Business Strategy & Design course.
