13 UX principles from an IT and DevOps perspective

In The Phoenix Project, coauthored by Gene Kim, Kevin Behr, and George Spafford, readers get a fascinating peek into the IT jungle of a large organization, where the dynamics in play are the same as those experienced in the wilds of UX. It's an understatement to say that this book is a "must-read" for UX designers, developers, and product managers. It's a "read now and don't come back until you're finished" kind of book on IT, DevOps and helping businesses succeed. In terms of user experience, the book makes clear that empathy is foundational to user-centered design. On every page, Gene Kim has provided the insights that help practitioners in all UX disciplines, as well as their users, to better understand the delivery of software that surrounds us.

I've led the design of user experience for an end-to-end continuous delivery solution. My close colleague and product manager exhorted me to read his favorite book, The Phoenix Project, in the spirit of getting to know our users—the enterprise DevOps professionals. With an open mind, I jumped into the world Kim imagined and since then have chosen to remain there. Through an insider's view, he describes what IT work actually is, how it flows, and how to loosen its impediments. The story led me to see numerous parallels to UX practices. I observed more clearly what UX work is, how it flows, and where its speed bumps reside. As software development and UX design are joined at the hip, the UX community should pay close attention to what the DevOps movement is ushering in, because the Ops portion teaches us lessons about what continuous design will look like when it finally aligns with continuous delivery.

For those who haven't read The Phoenix Project, I won't spoil the fun by describing what the book introduces to readers. However, I'll explain where I see the principles of IT and UX overlapping. In what follows, I have selected and reordered 13 axiomatic statements about IT that apply equally well to UX. After the comparison, I pinpoint what I think an organization can do to bring their UX practices on par with those of IT.

Lesson 1: UX competency is a predictor of company performance

"...to effectively manage IT is not only a critical competency but a significant predictor of company performance."

The inner workings of IT are mostly unknown to other departments, aside from when there's a problem. This is the case for UX, too, given the outcomes it produces through design decisions. Although the term "UX" is commonly heard, how it is practiced is nebulous to most. Everyone has had the experience of disliking a product they use, or they've heard customers complaining about theirs.

UX competency is also a predictor of company performance, because designing for continuous software delivery means being in step with the velocity of development while simultaneously listening to user feedback that gets translated into the next set of improvements. As every competitive company today relies on providing service through some form of software, so too must the competency to improve the experience of using the service be at the core of their expertise.

Lesson 2: UX is not just a topic or department. It is a competency for the entire company

"IT is not just a department. It is a competency that we need to gain as an entire company."

For an entire company to gain competency in UX, it requires educating product managers, support, engineers, and marketing teams. Caution, though: UX is not intended as a generalized topic but as practices specific to each department that are relevant to the type of decisions they need to make. This includes the HR department, which must be familiar with roles in UX and its careers paths if the organization wants to attract, develop, and retain talent.

Lesson 3: You must understand the business system that UX operates in and the organizational commitments the UX team is responsible for

"...you must gain a true understanding of the business system that IT operates in...there are organizational commitments that IT is responsible for helping uphold and protect that no one has verbalized precisely yet."

All departments must understand the business system that UX operates within and the commitments the UX team is responsible for. This is the most fundamental aspect of the practice that eludes the vast majority of department leaders—sometimes even the organization as a whole. No one states the relationship UX has with the business better than Alan Cooper: "Do you want to make money, or do you want to save money? Or do you want to innovate and make money? I'm not here to save you money. I'm here to make you money." He went on to explain that a design department in the organization is a cost center which, by definition, brings dividends later. It also offers a good ROI when management rises above the mentality of saving costs by understaffing, cutting quality corners, and removing key steps from its process.

Lesson 4: Make better business decisions by showing how UX risks can jeopardize business performance measures

"...showing how IT risks jeopardize business performance measures, you can start making better business decisions."

Areas of UX, such as research and concept validation, are typically sacrificed for saving time and costs. This sacrifice is usually blurred by the pace of feature-building—combined with setting goals that are too aggressive—to the point that methods of design-thinking are unable to produce their benefits. Worse is when this sacrifice goes unacknowledged in the frantic pursuit of conceiving solutions that would otherwise emerge faster from incubation and collaborative design iterations.

Decisions rooted in expediency and time-to-market concerns can create UX risks that cannot be accurately measured. In short, you cannot validate an idea that was abandoned at birth. You need a different line of questioning to begin assessing UX risks to the business. For example, rather than ask what gain there is from a particular implementation, you might instead ask, "What does the user lose by not implementing the better solution?" Or, "What greater value is there for the user by not implementing this more complete solution?"

Lesson 5: There are four types of UX work (projects, routine operations, fixes, and unplanned work)

"...there are four types of IT operations work: business projects, IT operations projects, changes, and unplanned work."

UX work can be mapped to this categorization. There are the projects directly associated with the products that drive the business. There are ongoing design collaborations that are routine operations to stay in tune with users' needs and ongoing fixes listed in the backlog. And unplanned work comes in the form of implementations that fell short of specs that invariably add to the UX debt.

Lesson 6: Unpaid UX debt can cripple over time in the form of unplanned work

"...technical debt that is not being paid down. It comes from taking shortcuts, which may make sense in the short-term. But like financial debt, the compounding interest costs grow over time. If an organization doesn't pay down its technical debt, every calorie in the organization can be spent just paying interest, in the form of unplanned work."

UX debt can cripple the natural evolution of a product. What should concern the entire organization is the unspoken awareness that certain task-flows in a product are clunky, or that the implementation of the UI is imprecise, and that there is a widening delta between the original intent and the current outcome.

Lesson 7: It's important to know where unplanned UX work is coming from

"...unplanned work is recovery work, which almost always takes you away from your goals. That's why it's so important to know where your unplanned work is coming from."

Indeed, the most egregious situation is when UX debt has translated into usability issues that development and testing teams have learned to live with—but users haven't. The backlash comes in the form of their pressuring complaints, which lead to fixes complicated by compounded interaction dependencies. When addressing them, the effort delays focusing on the innovations that otherwise might give the product its competitive edge.

This effort is unplanned UX work. So where is it coming from? Often, it originates from the design compromises made in order to adhere to the development schedule. The unplanned work is actually seeded in the thinking that focuses more on process and control than the outcome of user satisfaction.

There are two types of perceived time savers. One is deliberate. The second is circumstantial. In the first, we conjure calculating design rationales and sometimes with gut-wrenching sacrifices to the elegance of a feature. In the second, we forgo precision and thoroughness in the implementation, because they're deemed an impediment to keeping pace with the sprint's commitments. Either way, when the quality of UX is seen as the central problem, it spells user dissatisfaction and reduced sales.

The time required to define UX solutions with known shortcomings, to discuss them, and then to exact them, ends up costing more time and effort across all teams. One approach to mitigating this is by living up to W. Edwards Deming's admonition, "Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place." How is this achieved? Everyone who has a hand in the implementation needs to be educated on the standard of the UX quality to be met, from the user's perspective.

When the quality and success of UX are quantified in the business's performance metrics, the organization's awareness evolves into a new mentality that produces higher quality. The best retort in The Phoenix Project comes to the glib and posturing adage, "Perfection is the enemy of good," to which one of the protagonists shoots back, "No, lack of competence is the enemy of good." The goal needs to be to increase UX competency across the organization.

Lesson 8: Outcomes are what matter

"...outcomes are what matter—not the process, not controls, or, for that matter, what work you complete."

This statement reads like a maxim that applies universally in all activities. In IT and UX, this takes on a more profound meaning. When there are multiple dependent processes, checkpoints, and controls that govern execution, then delivering a feature by a certain deadline becomes the objective. But in the reality of the end user, that deadline has no relevance. What's ultimately a satisfying experience is the actual desired outcome, and that is independent of the internal workings of the organization.

Lesson 9: The longer the UX cycle, the longer the company capital is locked up and not giving a return

"The longer the product development cycle, the longer the company capital is locked up and not giving us a return."

This is the nucleus of continuous delivery that UX, dev, and IT must internalize into their very psyche. The most challenging aspect of this is adequately scoping the UX effort to allow design thinking to reveal the better solutions relative to development cycles. This can translate into devising a multi-tiered solution or accepting throwaway implementations. Here again, Kim teaches that through IT problem-solving, this discipline can be instilled through a greater understanding of the workflow.

Lesson 10: Create a fast UX flow by keeping dev team abreast of design rationales

" ...understand how to create a fast flow of work as it moves from Development into IT Operations."

In UX, work flows into development. Creating the faster flow is achieved by keeping the dev team abreast of design rationales and design intent in the most systematic and disciplined fashion. As soon as a design concept has emerged, vet it with the dev team. No further elaboration in wireframing needs to commence until dev is fully on board with what they'll be committed to deliver.

Lesson 11: Find the right balance to focus on what really matters and minimize WIP (work in progress)

"You've improved flow by freezing and throttling the project releases, but your batch sizes are still way too large...You also have way too much WIP (work in progress) still trapped inside the plant, and the worst kind, too. Your deployments are causing unplanned recovery work downstream."

In a nutshell, Kim ties together the intricate challenge that spans all product-focused departments. How big a difference must be made to distinguish the product from its competitors? Where does innovation matter the most? How big must the promises be for marketing's story to pique the interest of analysts and in turn grab the attention of the market? How does product management synthesize that into an incremental roadmap that charters a clear vision, while still remaining flexible in its journey? How does UX define a strong identity that's cohesive, uncompromising in quality, yet accommodating of business imperatives? For an organization that's ambitious to lead, these are existential questions. The Phoenix Project gives us a glimpse into answers through a method of execution.

Lesson 12: Experiment, have a bias toward deploying, and the discipline to make things small and quick

" ...we're now experimenting with doing daily deployments. Because the batch size is so much smaller, we can make small changes very quickly."

This, right here, is the essence of continuous delivery: the willingness to experiment, the bias toward deploying, and the discipline to make things small and quick.

Lesson 13: UX is not just a supporting function. Everyone in the organization should have experience in it.

"IT is not merely a department. Instead, it's pervasive, like electricity. It's a skill, like being able to read or do math—we expect everyone we hire to have some mastery of it."

UX is not simply a secondary supporting function. Every organization that produces software should expect everyone it hires to have some experience in it.

Continuous delivery is happening. Continuous design is being born. If it's not being born in your organization, then it's being born in someone else's while you're reading this. By current definition, you're either a DevOps organization or you're becoming one. And if neither, you're dissolving. Gene Kim and co-authors tell all these stories.