No Wookie mistakes here.

In tech and software especially, we’ve all become accustomed to thinking about User Experience so much so that it’s become a critical consideration for everyone in product-building teams, including software engineers. The success of a product’s UX is a critical part of the success of the product, at least in competitive environments.

More recently, we’ve begun to consider Developer Experience in building tools and APIs to make them easier to use, engender greater productivity, and potentially even 🌟delight🌟 (sorry) developers. If you’re producing new command line tools, APIs, frameworks, etc. today, one of the most important factors in gaining users is a keen focus on DX.

But there is a third group of people who interact with software whose needs are often forgotten — operators. They use the software produced by developers as much as anyone, just often via a different interface. We need a name for their experience and to make it a part of the conversation in our software practice just like we do for any other user. I suggest, “Operator Experience” or OX for short. (Ooh-Ex as a pronunciation seems best to mirror DX and UX. 🐂 is another possibility, of course.)

Naming Operator Experience makes it easier to incorporate into our conversations about software practice like we do for all users.

This isn’t new

Other industries and crafts have long understood the role of needing to maintain products. The auto industry includes repair guides, has diagnostic computers, and produces parts to replace those that break. Japanese carpentry often does not use nails or glue so that joints can be taken apart for repair or replacement. Yet we often treat logging, metrics, health checks, and debuggability as an afterthought in software development.

It’s not surprising that our industry has evolved this way though. Software engineering, especially as practiced in environments of lean methodologies, does not value new software and thus encourages a very Mad Max approach until the software proves itself to be valuable. This methodology exists for a reason, but it must evolve with the product stage. Maintenance needs championing when the time is right.

Don’t make it hard to get to the fuses.

Simply put, if you have users, you have operators. Your users’ experience depends on your operator being able to do their job. Your operators are highly trained professionals who can put up with a bit rough road for a while, but they don’t have to put up with it for long. Investing in your OX will lead to better UX and hopefully just make your team happier overall.

How?

There are many, many better resources online on how to implement better OX than I could ever provide. In this post, I’m mainly interested in the conversation about making it happen. To that end, whether you decide to go for a DevOps route, create SRE teams, or whatever else, envision your operator’s needs of:

Knowing whether everything is ok or something is broken

Being able to figure out what’s going on when something has gone wrong

Have a way to make things safe after a breakage

There is a whole lot that you can do from the software side to make all of the above possible and easier. It all starts with a conversation, probably no different than the one you have with your product manager about:

Accessibility

Usability

Interface efficiency, etc.

Respect the operator

Even if you are a small team, somebody has to operate your software. That may well be you, even if you use an “ops-less” platform. Once you have users, design your software so that you and your operators can respond to failures more easily, correctly, and safely.