Focus on the Operator Experience
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.
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.
If you’re interested in working with us, discussing issues like these and others, please check out our jobs page and get in touch!
