Written by Scott Sullivan, Applied Designer, Adaptive Path@Capital One
After leaving Adaptive Path in 2012, Todd Wilkens has been focused on one of the biggest issues in Service Design: building a Service Design practice on a massive scale. In the past four years, Todd has been a pivotal part of design initiatives at Mayo Clinic, the enormous design transformation initiative at IBM, Atlassian the enterprise software developer, and is now starting a new position as the head of WooCommerce. Todd is speaking at Adaptive Path’s upcoming Service Experience Conference in San Francisco, and is bringing his hard-won expertise to explain why we need to sacrifice Service Design as a unique discipline in order to build great services.
Scott Sullivan (SS): So looking over your recent work history, it seems like it’s focused on building a design practice within massive, massive places.
Todd Wilkens (TW): In the last few years, that’s for sure. I’ve been going to places, trying to help build design practice in big organizations.
SS: The scale of what you were doing at IBM is just — is insane, right? I mean, everybody was just like, “I can’t believe they’re actually attempting to do that there,” but it seems to be working out really well.
TW: Yeah, that was why I originally went to go take that job was because it just, it was crazy. It was crazy what Phil Gilbert and the team he was putting together were trying to do, and it just seemed like, you can’t just not — if you have a chance to try that, you gotta give it a shot, right?
SS: Absolutely! And IBM is doing great now. They’re getting stuff done, consistently publishing really great insights and tools, really useful stuff. Would you consider that, from your current perspective, mission accomplished? Or well on the way?
TW: Yeah, you know, it’s funny. Something that I learned from working at Adaptive Path in the past was, people used to come to Adaptive Path for help transforming their organizations a lot of times. They’re trying to understand how to do design or Service Design or planned thinking or whatever phrase they use — trying to bring that in, make it strategically impactful. How do we do it?
We’ve talked to lots of large organizations about that, and the one thing you always realize is that this is a task that is never completed. You start working on that, but it’s never like “it’s done, okay, we can hang up our hats and it’s going to be fine for the next 10 years.” Transformation almost never just “happens” — it’s always moving in the right direction.
IBM is one of the places where the basic idea for my talk was cemented, which is that you have to stop focusing on being a designer and owning design. You have to recognize that, in order to make great products and services around the world, designers don’t do that by themselves, right? It’s these whole multidisciplinary teams that actually get things out into the world to have impact. That was one of the first places where I realized I had to kind of give up the ownership of design. It couldn’t be this precious thing and this precious identity to myself and the people on our team. We had to prioritize getting good things shipped out the door over ourselves as design people. The output, the impact in the world and the impact on the world was much more important than us continuing to own or even get credit for everything.
SS: So would designers be seen as more of a gatekeeper? When you’re working with multiple lines of businesses on multiple touchpoints, what’s the service designer’s responsibility?
TW: It’s interesting that you say, “the gatekeeper,” that’s a conversation that we had at Atlassian, sometimes people use the word gatekeeper, sometimes they say “Is this some kind of stage-gate that everybody has to get approval before we build a thing?” Sometimes the word ownership gets used in those kinds of conversations as well, asking “Who is the owner that has to make the decisions and has to be consulted before a decision is made.” And, what’s interesting is that, this happened at IBM, and this is one of the lessons I’ve learned at Atlassian, the sort of trite thing to say is that software products and services are never done, right? They’re just in their current state, and you’re trying to make each state of their release better than the last, but they’re never done, and they’re also never perfect. And even if you got something that was “perfect”, the world would change enough that it would stop being perfect as a match for that world within three to six months.
So we’re always evolving everything that we release, whether software or service. I say that because it’s actually an interesting thing when it comes to design, in my experience, and the role of design. If you ask most designers “should we be iterating on things?” they will say, “Of course you’re iterating on things! It’s never perfect, you’re always iterating, always improving, you’re always duh-duh-duh-duh-duh.” But most designers talk about that within the studio, “as long as I’m ‘in the prototyping phase’ — yes, of course, it’s iterating. But then there’s a point where I have to feel like it’s done and I’m releasing something to the world. They tend to choose their criteria for success when something is released out into the world. It needs to be better, more perfect. And then there’s this kind of real hesitance, I’ve found, around how you handle iteration once something is out in the world. Designers are really comfortable with that iteration idea, but I find that they get more uncomfortable once it’s released into the world.
I want to change the conversation and start saying, “Well, yes, there are some things we can learn and improve on when it’s kind of in our control in the studio,” and I use the word studio in a sort of generic sense, not out in the world. But there’s this sense that we aren’t really learning if it’s working until we’ve made it and gotten it out in the hands of people that use it. Yes, we can do generative research. Yes, we can do evaluative research before it’s out. But oftentimes, especially with services, which tend to have complex touchpoints — you know, it’s one of those things that we can’t actually completely understand all the implications before it’s out and being used. The sooner you get it out into the world, and the better you are at quickly iterating it once it’s out in the world, it’s actually a better way of reducing risk and getting to success than spending time up front. One of the things I’ve learned is that, in some cases, that skill set is actually more important than all the design thinking that goes on.
So what that means is, designers need to stop seeing themselves as a gatekeeper and more as a conductor. You could say it like a train conductor, or like a music conductor. Both cases are actually accurate in some sense as a metaphor. It’s like being a conductor or a jazz musician with improvisational jazz. You don’t know what the next thing that is going to happen is, and you need to empower your people to respond to things, even when you’re not there telling them what to do.
Join Todd to learn more about Service Design as a unique discipline within organizations at the Service Experience Conference on November 3 & 4 in San Francisco. Todd will be joined by a line-up of premier leaders in Service Design and workshop teachers with practical take-home tools and know-how.