Hey, devops! Leave my UI alone!

The user interface and experience (UI/UX) should be consistent, and any and all changes should be announced

smartphone interface - virtual augmented display

So you’re doing devops. You’ve got integrated teams and an automated continuous delivery pipeline. You can release on demand using fine-grained feature toggles, canary builds, and the whole world is now your A/B test. Great! Just leave the user interface (UI) out of it, please.

Lately we’re hearing a lot about the importance of bringing customers into the development process as early as possible, a laudable goal when done in the right way. The sooner you get the product in the hands of customers, the wisdom says, the sooner you can understand their experience and make improvements based on feedback.

Continuous delivery allows you to do that with unrestrained ease. As soon as a feature is complete, it can be pushed into the hands of millions of customers.

When it comes to the user interface, though, abrupt and unexpected changes are almost universally detested. UI/UX needs to be consistent. Changes should to be announced. Users need to be prepared.

If people get into work one morning and things look different, there’s a frustrating transition period where time is lost. Even moving a button a little to the left breaks their muscle memory. And when something moves to a hitherto-unheard-of submenu? Now that’s just antiproductive!

And it’s not just the individual user; it’s your whole organization that slows down. The impact of unannounced UI changes ripples right across the business. Help desks become unhinged, flooded with tickets like “I can’t find X anymore!” and “They took away my menu!” and “Can you Google this for me!?”

The reason you want to accelerate your release cadence is to deliver value. Perhaps a little perspective on whose value is in order: Is it the product and engineering teams that get to check off another box and close another epic? The pressure to close stories is a consequence of agile that, among other things, conflicts with the one true MacGuffin: customer value.

It may be contrary to expectation, but reliability is more important than functionality. Customers need their tools to be consistent and familiar, not mercurial and frustrating.

It’s important to remember that people use tools to do their own work. They are not spending precious budget to become members in a test audience or to focus-group designs. In fact, they’ll pay good money not to.

Don’t get me wrong though, I love devops. The culture, the principles, even the buzzwords. But the first rule of devops is “Do no harm” (I think?), and for the users this kind of overreleasing on the UI is simply exhausting.

The problem is not devops or even continuous delivery (CD), though. The problem is with product managers going mad with power and abusing the beauty of CD, turning it into something ugly and hateful. Because that’s what this is: a misuse of devops practices as an abuse of customers.

I am not one to criticize without offering a solution, though, so what can you do about it?

First, you can follow the advice in Robert Stroud’s recent report, “Drive Devops Efforts with Customer Experience Pros.” He writes about how customer experience (CX) professionals are using customer journey maps, ecosystem maps, and user data to provide a well-rounded view of the what the customer experience should look like. This approach can be incorporated into how you build your products to provide the reliable experience that users are looking for.

By embedding CX pros into integrated product delivery teams, you can deliver consistent overall experiences. It may seem like an unlikely pairing, but coupling the people deploying changes with those designing the customer experience means that you won’t be unintentionally creating angry users by pushing too many UI changes too frequently. The roadmap for delivering these changes can be aligned to a schedule for releasing them that is reasonable and palatable for customers.

Second, I hate to say it, but this is one time where it is best to keep work open for longer than you’d like to. I realize that this advice goes against the long and august traditions of Lean and agile, but when it comes to UI, batch and queue is what works—let the changes build up and then release them as a well-communicated package, one that people know it is coming and have already made the mental leap toward.

It is difficult to think of any valid reason to make unannounced UI changes. So don’t. Make sure that unannounced UI changes are either going to willing and eager participants in some kind of masochistic Early Access program or to no one at all. In this way, you can make the world a happier place, one UI release at a time.

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform