Unlocking Success: Navigating User-Centered Design in DevOps

As reflected in last year’s State of the DevOps Report, where the intersection of technology feasibility and business needs is more crucial than ever, user-centered design becomes the guiding light for success. To utilize it properly, focusing on users doesn’t stop at the UX team — it requires synergy between the entire company. So, how do you ensure that the user is considered at every step? Our Director of Customer Experience, DJ Jahn, shares his insights into the importance of engaging customers and clients, understanding user behavior, and balancing technical constraints with user desirability to show how organizations can seamlessly integrate user-centered design principles into their DevOps practices.

Engaging Clients with Curiosity

At Aviture, we engage our clients in the same way that we encourage them to engage their customers. Engagement is being inquisitive and empathetic while asking questions like, “What is the why? What are you trying to satisfy and accomplish?” The goal is to get all the meat on the table to call out opportunities for alignment alongside points of conflict — making sure that we've got something that is satisfying both our customer and their users’ needs. Without this sort of due diligence, we can end up building something that's perfect for the business that no one will use but will bankrupt a company. The needs of the customer and the needs of the business will sometimes be in conflict, but it's about navigating those to make the best solution and find compromise.

Getting to the Root of a Problem

A lot of times people will ask for a solution using terms, experiences, or things that they can relate to. It’s like Henry Ford’s old adage: if you asked people at the time what they wanted, they’d want a faster horse — not a car. In order to get to the root of a person’s problem, you need to understand their language, take a step back, and translate the problem they’re trying to solve with the words they're using. At Aviture we’re a big proponent of using the 5 Whys, a technique of continuing to ask “why?” when presented with a problem. For example, “What do you want? Why do you want it? Why do you think it'll do the thing that you're thinking it'll do? Etc.” This helps our customers get closer to an understanding of what the actual problem is they're searching for a solution for.

This is a process that can be done on both the business side and the user side as well. Users need to do stuff — and they're going to do it the way that they're accustomed to. In some cases, that might not necessarily be right or all that's possible when we start to think about technology. When engaging users, what they do and what they say are not always one-to-one. A lot of times people will say something, but it doesn’t reflect their actions or real beliefs, so being able to discern between the two is very important.

Asking (the Right) Questions

Observing how a user is engaging with the product is one of the most valuable ways of getting true data, and through instrumentation and analytics, we can ask the following questions:

• What are they doing?
• What are they not doing?
• How does that align with our hypothesis?
• What are they saying, feeling, thinking, and doing while they're engaging with our tool?
  

Questions like these are essential for understanding a user’s process, but they need to be very specific questions. If you're asking how does something feel, or how do they like something, you're going to get very surface-level answers. Read between the lines of what they’re doing or not doing, what they’re saying or not saying, and what's hiding right beneath the surface. The 5 Whys help to better understand their perspective on a solution. The following questions are some examples to get a better response beyond the “I like it/I don’t like it” canned response to help you move on to meatier topics:

• Why is this working for you? Can you highlight the pieces?
• Why is it not working? Can you elaborate?
• What are the points of pain? Is it confusing?
• What brings joy or excitement?
• What is working well and why?

Navigating Blockers Preventing User-Centered Design

Some organizations are structured with chains of bureaucracy to approval. It satisfies the business side, but it can come at the expense of the user. With our customers, we make sure that we understand and are aware of what the corporate environment is. We articulate and communicate what we're doing, why we're doing it, and make sure that that message goes all the way upstream so we're not just satisfying an internal user who's not an actual user of the product.

A lot of what we need to do requires us to figure out what our constraints are as quickly as possible; “How do we satisfy this problem efficiently and inside of the constraints?” This allows us to navigate some of the bureaucracies and identify where potential risks or concerns are. We can buy down those risks early and upfront and ensure we're not taking a waterfall approach during the design process.

Balancing Business, Technical, and User Perspectives

There are business needs from executives, technical feasibility concerns from engineers, and user needs, expectations, and requirements — all are separate audiences that need to be understood and have a voice in the project. As you step into conversations with each group during the project, it’s important to advocate for each audience that might not always be in the room. If there’s an audience being left out, bring that into the conversation and make sure that they’re spoken for. If they are, make sure that the messaging is aligned with the current understanding. User personas and other artifacts that describe who the users are, or what the purpose is, help make sure that understanding permeates the entirety of the team.

User experience suffers from the misnomer that there’s a specific person or team that handles it all. The reality is that user experience is informed by all three of those parties. Business decisions can impact your users, technology choices can impact your users. 

User Experience is Essential

User Experience is not a line item. It's not optional — you're doing it. The only things that are variable are how much you're willing to invest in it and how much of a priority you're putting into it. If you go into an effort, and you focus solely on the technical needs, it could be a beautifully designed solution, but that's not assuring that it's meeting a user's needs. And that's not assuring that it's necessarily aligning to a business problem. Having that well-rounded perspective, accounting for those three parties — the business, users, and technology, ensures you're doing the right thing. I equate it to a pterodactyl trap, where I can build an infinitely scalable, well-architected, beautiful machine. But at the end of the day, it's still worthless — it's not solving a real-world problem.

Let's not make pterodactyl traps, let's solve real problems. To have real problems solved, you have to have a real understanding of your users and their problems.