Hey! DevOps! Leave my UI alone!

So you’re doing the DevOps. You’ve got integrated teams and an automated continuous delivery pipeline. You release on demand 47 times a day using fine-grained feature toggles, canary builds, and the whole world is your A/B test.

Great! Now leave the the UI out of it please!

I hear a lot about the importance of bringing customers into the delivery process as early as possible, a laudable goal when done 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.

And continuous delivery allows you to do that with unrestrained ease. As soon as a feature is complete you can push it into the hands of millions of paying customers.

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

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

And that becomes unbearable when a well-tuned DevOps machine enables changes to happen daily, hourly, even minute to minute.

It’s not just me who suffers, it’s my 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!?”

Let’s take a step back. The reason you want to accelerate your release cadence is to deliver more 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 or close another issue? No. That pressure to close stories is a consequence of agile that, among other things, conflicts with the one true MacGuffin: customer value.

When it comes to business tools, customers value reliability even more than functionality. We need our tools to be consistent and familiar, not mercurial and frustrating. We are not spending precious budget to become members of a test audience or to focus-group your designs. In fact, I for one would 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 OVER-releasing on the UI is simply exhausting.

Let’s be real , though— the problem is not DevOps. The problem is product managers going mad with power and abusing the beauty of Continuous Delivery, turning it into something ugly and hateful. Because that’s what this is: an misuse of DevOps practices and an abuse of customers.

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

You can find some great advice in Robert Stroud’s recent report, “Drive DevOps Efforts with Customer Experience Pros.” He makes the case for a customer experience (CX) role in your delivery process that uses 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 a CX role into your integrated product delivery teams, you will be capable of delivering a consistent overall experience, watching for problems like 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 you might need to sacrifice on your lead time. I realize that this advice goes against the long and august traditions of Lean, but when it comes to UI, batch and queue works better — let your changes build up in your dogfood, and then release them as a well-communicated package. One that people know 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 is either being pushed to some willing and eager participants of a masochistic Early Access program, or to no one at all. You can make the world a happier place, one UI release at a time.