UX and DevOps: "Every app you uninstalled probably had UX failures" – JAXenter

JAXenter:Hi Debbie, thanks for taking the time to answer some questions for JAXenter. UX isnt 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 Id 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). Ill be renaming it Dev && UX for 2020. So people dont assume its a DevOps presentation!:)

JAXenter:Why do you think this is the case?

Debbie:From my experiences and what Ive 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 dont 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. Dont 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, its clearer how some time and money spent up front will save way more time and money during engineering and then after release. Youll even spend less on customer support when products better match peoples 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 were building, and theyll 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. Its painful!

JAXenter:Youve previously written about how its 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 dont write code and then decide its 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 dont 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 dont skimp on testing our code. We dont write code and then decide its probably good enough to release, so lets skip QA. UX testing is hugely important and can often be done fairly quickly.

Ultimately, the dream scenario for CX and UX is to be better understood in all areas of companies. Were not the people who sketch screens. Were 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.

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

Read more:
UX and DevOps: "Every app you uninstalled probably had UX failures" - JAXenter

Related Posts