UX and DevOps: “Every app you uninstalled probably had UX failures”

JAXenter: Hi Debbie, thanks for taking the time to answer some questions for JAXenter. UX isn’t a topic that comes up that frequently in discussions about DevOps, and yet, like you say in the description of your DevOpsCon Munich talk: “Your customer only sees your UX, not 1,000 developers or whether you were agile”. Do you think that the importance of UX has been severely underestimated in DevOps setups?

Every website you stopped going to, every company you cancelled, and every app you uninstalled probably had UX failures that made you feel done with them.

Debbie: Hi, Chris. Thanks for asking! Before I answer that, I should mention that I see the definitions of DevOps changing a bit. My focus is where DevOps goals include customer satisfaction, increasing your ability to build the right product, faster fixes (though I’d say fewer fixes if we want to reduce defects), improving efficiency, and improving product quality.

This is where UX best overlaps DevOps goals, and why I named my presentations and workshops “DevOps ICU” (ICU is the hospital intensive care unit taking care of the most serious patients). I’ll be renaming it Dev && UX for 2020. So people don’t assume it’s a DevOps presentation!:)

SEE ALSO: Microservices: “Service landscapes are of great benefit to business agility but require very fast remediation cycles”

JAXenter: Why do you think this is the case?

Debbie: From my experiences and what I’ve heard from others, Engineering, DevOps, and other related teams are often siloed from UX. There might be a gatekeeper, or the teams sometimes silo themselves because they don’t have a good understanding of what each team does, and collaboration went badly. Combine that with a general misunderstanding of UX, as well as Agile materials and coaches excluding us (again, due to lack of understanding), and you end up with companies trying to build “better” products but without changing their processes or bringing in the UX experts who would get it done.

JAXenter: What are the benefits of making UX a more prominent consideration in the development cycle?

Debbie: There are three main beneficiaries of correctly integrating UX into dev cycles. The first are our potential and real customers. Don’t wait until they are complaining, angry, or dumping you for the competition for you to put in more effort to create something that better fits their needs. It rarely gets fixed later, and by then, we may have lost customers or found our product is harder to sell.

The ROI is measurable, and businesses love that!

The second beneficiary is all of Engineering. They will save time, money, and sanity when UX pros are able to research, architect, design, test, and iterate on concepts before Engineering writes a line of code. This should drastically cut down on surprise changes of mind that waste time now, and it should cut down on “fixing it later” when we learn after expensive dev cycles that we need to build something better for customers.

The third beneficiary is “the business.” People who are watching budgets and measuring ROI are often hesitant to add UX to the process. Without understanding what UX does, how, or why, they see them as an expensive line item we can cut or skimp on. Once they “get” UX, it’s clearer how some time and money spent up front will save way more time and money during engineering and then after release. You’ll even spend less on customer support when products better match people’s needs, are easy to learn, and easy to use. The ROI is measurable, and businesses love that!

JAXenter: Are there any examples that stand out to you of how a big project was ultimately let down by the UX? Why was it so problematic?

There are many examples of products that were let down by excluding, circumventing, overruling, or skimping on UX.

Debbie: There are many examples of products that were let down by excluding, circumventing, overruling, or skimping on UX. The easiest example would be every time you uninstalled an app because it was garbage or not what you needed. That company failed you. Did they even research with people like you to learn who you are and what you need? Or did some stakeholder just announce this is what we’re building, and “they’ll figure it out”? Every website you stopped going to, every company you cancelled, and every app you uninstalled probably had UX failures that made you feel done with them. And this can all be avoided by hiring at least one expert per project.

For more famous examples, people can research what happened when Skype and Snapchat separately made big UX changes that customers hated. Read all the bad press, see how the stock price dropped, check out the angry Twitterstorms, and read about how it alienated customers. Consider what that cost those companies to build and then have to undo or rebuild. It’s painful!

JAXenter: You’ve previously written about how it’s important not just to consider one end user, and how user testing should be integrated into the UX process. What would you say is your dream scenario for UX in software development setups?

Testing is the QA of UX. We don’t write code and then decide it’s probably good enough to release.

Debbie: The dream scenario for UX testing would be to have the time and budget to run multiple rounds of testing with real and/or archetypal users. Sometimes we don’t have “real” customers yet because this product is new. But if UX research does a great job helping us focus on where the sweet spots of our target customers are, we build for them and we test with them. Many projects can work with realistic UX prototypes, saving Engineering from having to build our prototypes. We can then give real people some real tasks, and see where there are flaws.

Testing is the QA of UX. We don’t skimp on testing our code. We don’t write code and then decide it’s probably good enough to release, so let’s skip QA. UX testing is hugely important and can often be done fairly quickly.

SEE ALSO: DevOps: “A T-shaped human has the benefits of being a specialist in a particular area but also a generalist in many areas”

Ultimately, the dream scenario for CX and UX is to be better understood in all areas of companies. We’re not the people who sketch screens. We’re not artsy fartsy hipsters. The core of UX lives in cognitive psychology, far from anything artistic. We must be able to understand and predict human behavior. We must be problem finders and problem solvers. We must be able to predict and mitigate business risks. Great UX meets and exceeds the metrics and goals the business has set out, but UX rarely gets the credit.

It’s time to finally understand what UX is, who does it, how and why, and how it can be Agile, Lean, and collaborative.

The post UX and DevOps: “Every app you uninstalled probably had UX failures” appeared first on JAXenter.