DevOps is often defined as the processes, operations, methodologies, tools, and culture surrounding a company’s software and systems development.

But engineering doesn’t operate in a vacuum. Blueprints, ideas, designs, and concepts come from product design specialists who decide layouts, flows, and interactivity. These are non-engineering individuals and teams who share DevOps’ goals and desired results.

DevOps is about so much more than how developers connect with IT, how infrastructure is managed, and how frameworks can be improved. It’s about recognizing how many teams are truly involved in the software development process, how intertwined their roles and work are, and finding better ways to make sure everybody is at the table.

Developers and engineering architects want to be involved when the product and creative teams are designing the software or system. But where is that in the current definition of DevOps? Product, UX, and creative teams want to stay involved during engineering processes yet so many methodologies exclude them. These are old silos that we need to break down.

Your customers only see your user experience (UX). They don’t see how many developers you had or if you were Agile or Lean. They have no idea which DevOps tools are being used. Your company’s UX is the product, and it can make or break you. They wonder who built this piece of junk. With so much competition and people happy to uninstall an app or leave a website, will you get a second chance with the customer who abandoned you?

Agile Rarely Trains on UX or Working With UX Specialists

Many engineering teams often find UX to be siloed and difficult to collaborate with. UX doesn’t seem Lean and many flavors of Agile exclude specifics on how to work with UX. Some Agile approaches specifically suggest that a product owner describing a feature is “good enough.”

SAFe Agile makes the mistake of deciding that the best way to solve UX siloing is to exclude them completely. SAFe “empowers Agile teams” to do their own “Lean UX.” As more companies understand the value of incorporating UX specialists and a full UX process, SAFe is going in the wrong direction.

The absence of explaining UX and their processes from Agile training and books has lead teams around the world to exclude or minimize the involvement of specialist product designers.

·         When you incorrectly imagine that UX just draws boxes on pages, it’s easy to assume “I can do that job.” Like so many American Idol auditionees are sure they are the best singer on the planet, most product managers and engineers self-assess as being great at UX. This normally means they believe they are great at laying out screens. But as this article explains what really goes into UX work, you will see how a UX specialist would not see a developer who makes wireframes as someone who should be given UX tasks.

·         Books on Scrum suggest that if a UX specialist becomes a bottleneck, she should train non-UX roles to do her job. This type of decision is rarely suggested about other roles in software development; nobody would want an untrained or inexperienced developer to do the coding, even after a bootcamp or reading a book about programming. We would never suggest that if a developer becomes a bottleneck, she should train the project manager to do some coding.

·         Hiring managers who incorrectly believe that UX is an artistic (UI) job hire artists to do UX work. There is no educational overlap between a degree in UX and in UI. Natural talents often don’t overlap; someone great at UX might be a poor artist and vice versa. Hiring for “UX/UI” often delivers you a great artist with minimal UX experience, expertise, process, or education.

Those looking only at the bottom line would love to slash the budget by giving UX tasks to individuals who might lack UX education, experience, expertise, skill, or natural talent. But this is short-sighted and can lead to poor productivity, efficiency, culture, product, and customer satisfaction.

The Importance of Incorporating Expert UX Specialists in Agile

 

In late 2018, management consulting firm McKinsey & Company published, “The Business Value of Design,” a report on research they did with over 300 companies.

They found that, “Design is the only way companies can stand out from the crowd.” When competitors have close feature sets, what makes them stand apart? Design is sometimes thought of as just the aesthetics or what makes this look like our brand. But when used with, “UX,” design means the architecture of features and the decisions made about screens, steps, flows, layouts, processes, organization, and menus.

UX is part of the continuous improvement process, always seeking to better understand users and select and design the features and product that best match their needs, solve their pain points, and bring them meaningful innovation.

McKinsey also reported that, “Companies must embrace design holistically and early in the process rather than seeing it as a small tool that fits in later.” Teams assuming that attention to user experience is something that can be minimized, excluded, or done after releasing the product are taking the wrong approach.

McKinsey collected quantitative data and found that firms that embraced UX design generated 32% more revenue and 56% more shareholder returns in a 5-year period. Declaring your company to be “user-centric” isn’t enough. You must walk the walk by integrating UX practitioners and processes from planning and portfolio down through development and QA.