What is Design Thinking, and just as importantly to you – why does it matter to DevOps? For answers to that, we recently turned to Jeff Sussna, founder at Ingineering.IT. Sussna combines engineering expertise with a knack to bridge business, creative, and technical perspectives.

Sussna’s focus is on the intersection of development, operations, design, and business. He has more than 20 years of IT experience, and has led high-performance teams across Dev, QA, and Ops. Sussna is also the author of the forthcoming O’Reilly Media book Designing Delivery: Rethinking IT In the Digital Service Economy. The book is expected this May.

DevOps.com: You’ve obviously placed considerable thought into design thinking, and it’s a subject that is coming up more and more within DevOps. I’m imagining a lot of people in IT, including developers and admins, wonder what design thinking means in the context of DevOps and IT.

Sussna: I’d start by simply explaining what design thinking is. The basic idea is that if you look at designers across a wide range of industries, whether it be architects, graphic designers, or UX designers there’s a general way that they approach creating solutions. And what design thinking really does is try and capture that in a way that we can apply it to a lot of different things besides how annual reports or web pages can be designed.

So how do people do it? The basic approach behind any kind of user-centered design is very simply to try and understand the user and understand them from their own perspective. Design thinking is really centered on empathy, empathizing with the user. The way it works is often by taking an ethnographic approach, which very simply means actually getting out in the field and observing people.

That means, if you’re an IT person and you want to design some internal application that employees are going to use to track time, for example, or to do some part of their job, you want to start by actually going and sitting with them and seeing how they do their job. This way you can understand their job and you can understand how they see things rather than how you see things. Everything drives from that.

There’s a lot of focus on iterative design and user testing, but it’s really all focused on centering your solutions on what users are trying to accomplish and how they understand things and what their needs are.

DevOps.com: How is it applied to DevOps?

Sussna: We can apply that to DevOps in a very simple way. If you’re in Ops, for instance, you need to think, to some degree, about your customers being developers.

So what is it that developers are trying to accomplish? How do they see the world? What do they need from you in order to get their job done more efficiently? And even when we look at things like platform as a service, what it’s trying to do is to make it easier for developers to deploy code. If you look at infrastructure as a service it’s trying to make it easier for Ops teams and DevOps organizations to cost effectively manage scalable systems.

Conversely, if you’re a developer you need to think about things from the perspective of, “How does what I’m doing impact operations?” If I release some code and, A, the code isn’t secure and, B, the code isn’t scalable and, C, it takes 47 hours and 17 people in order to deploy my code, that’s not a very empathetic approach to operations.

DevOps.com: It is increasingly the case that more of IT has to think about the external customer as well, in the context of everything they do.

Sussna: IT is in the business of providing services to the company but more and more now to customers as well. And so we need to think of ourselves as being in the service business just like anybody else. It isn’t just an ISO definition of service. It’s really a business definition. If I run a shoe store, I’m in the service business. If I operate a bank, I’m in a service business. I have customers and I need to help them accomplish their goals and I need to think about customer satisfaction and I need to try and empathize with what their needs are.

There’s a branch of design thinking that is called service design. Sometimes it’s called service design thinking. And it’s really about applying these same principles of empathy, ethnography, and creative problem solving and iterative design. It’s applying them to services. In our case, the services happen to be IT services, both internal and external.

DevOps.com: How is this approach different than what IT has always done? IT has always tried, or at least stated that, the goal is to build apps and services that the business wants and needs to use.

Sussna: I think too often we’ve done it from a technology first perspective as opposed to a human first perspective. There is an assumption, and it’s a very subtle assumption, but there’s this subtle expectation that it’s our job to adapt to the technology. And it’s not just about technology, the assumption is that it’s our job to adapt to the process.

I’ll give you a perfect example. I went through a situation recently where I was having a problem with a laptop and so I filed a ticket in the ticketing system. And the response that came back was, “Well, your laptop, you can’t log in because your laptop got moved to a stale machine domain so we’ve moved it back to the correct domain and we’re closing the ticket.” And there was not even the question asked of, “Well, can you log in now?” It was, “We did the thing that we believe will fix the problem, therefore we’re declaring the problem fixed.”

So the point is that the process of carrying out actions was central and the question of can the humans solve their problem was secondary.

DevOps.com: That’s a great example, because it seems like the designer of that system just wanted to close tickets as fast as possible when you go through that example. There’s no indication of thought being given to the user at all.

Sussna: The irony is that if you look at the back and forth that went on afterwards to ultimately get to the point where the problem was solved, it actually took more time and more energy and more ticket thrashing than if they had simply asked, “Hey, can you please verify that this solved your problem and let us know if it did.”

So, yes, to some degree, you can say there was a focus on efficiency and volume of ticket closure and operational cost effectiveness and all of that. But I think that what design thinking is really trying to tell us is that if we think through the process and if we design things from a user-centered way, we can actually develop solutions that are more efficient for everybody.

DevOps.com: What are the primary benefits of Design Thinking to DevOps teams?

Sussna: I think the benefits are that you can design solutions that help people solve problems more effectively. And effectively both means that the user is satisfied and that the organization providing the service meets its needs as well. Design thinking works with a triangle, which is feasibility, viability and desirability and trying to solve for all of them. Desirability says, “This is the thing that works for me, I want to use it.” Because if I don’t want to use it, it will fail. Because even if IT says you have to do it this way, people will find workarounds if they know of a better way.

Feasibility speaks to the ability to actually build something. And viability means that it will work from a business perspective. What design thinking does is try and solve for all of those. It’s a solution that’s effective for the users but it’s also supportable for the IT organization.

DevOps.com: How do folks get started on that type of thinking?

Sussna: In terms of how to get started, I think it’s very similar to how you get started in DevOps. I think what people are actually trying to do with DevOps, that they may not realize, is they’re redesigning how IT happens. I think with both of them, the way you start, the way I guide people in starting is to just get out of your silo and actually go talk to people.

I’m working with a client right now and they are trying to build an integrated IT dashboard that will allow everybody in Dev and Ops to visualize what’s the state of their network, what’s the state of their servers, what’s the state of their application, and what’s the state of their data. And they’re getting excited about all of the different types of dials that they need. But I’m telling them, “No, stop. The first thing you need to do is figure out who you think is going to use this and go talk to them.”

Don’t tell them what you’re going to to give them or maybe come up with some a very, very simplistic, crude fantasy of what you’re going to give them. Go talk to them and learn in detail about what they need to do, what things they are missing, and ultimately ask “Does this work for you?”