Why I enjoy improving enterprise software

The end of this month will mark the 6th year since I started working as a "Quantitative UX Researcher" at Google. Moreover, for the whole time, I've been attached to the same broad team working on a bunch of storage related products in GCP. For many people working in tech, 6 years is ridiculously long span of time – most people would've switched jobs or did an internal transfer to another product already.

While I'm somewhat a slow adopter of organizational change, especially when I get along well with the many people I work closely with, there's another reason why I haven't bothered to go find another problem space to work in – understanding enterprise users is a giant, fascinating challenge.

In broad strokes, commercial software tends to be sold to two distinct groups of people – everyday consumers like you and me, and "enterprises". There's all sorts of definitions about what counts as an enterprise, with a wide gray area (for example, is a small business an enterprise? What about a non-profit? A government? A single-person company? A startup?). For the purposes of what I'm discussing today, when I say "enterprise user", I mean situations where the person who's using the software is largely not the same person that's paying for the software, or even the person decided to adopt said software.

I've worked on products that either catered to direct customers – think a typical e-commerce storefront, game, or phone app, as well as enterprise software like cloud services, and I find the latter to be a whole different puzzle that keeps me occupied enough to not want to switch.

Enterprise often looks different

One of my first exposures to what "enterprise software" is like comes long before I started working in software. I saw my father work in the insurance industry in the early/mid 2000s and got to see their software behind the scenes. If you ever work with an insurance agent on getting a policy for anything, they inevitably will pull out some kind of purpose-made calculation software to generate all the numbers related to whatever insurance policy you're dealing with. I'd watch people pull out the software and they just looked... old and horrible. This was the age of Windows XP and native desktop apps, but the agents I saw always used software that looked slapped together using Visual Basic by someone who clearly had no design skills whatsoever. The fields were ordered haphazardly, and it honestly required actual training to make sure agents knew how to use the software correctly. The modern concept of designing interfaces so that users are naturally guided to doing the correct things (and avoiding incorrect usage) just did not seem to exist for this software. On top of it all, the agents themselves constantly complained that the software was confusing, slow, crashed often, and was a pain to use. Everyone using the software hated it... but they had no other choice but to use it. There was simply no alternative tool to generate the necessary forms and tables.

Jump to the present day and if you work with an insurance agent to get a policy quote for you, you will see very similar software. The interfaces and code probably have gotten a facelift over the past twenty years thanks to the UI widgets improving in that time, but they're still about as horrible as before.

The primary reason why such software exists in this state for effectively forever is because there's no strong reason for things to be better. The team that's creating the software is probably busy with a bunch of other things. The users of the software are a captive audience – if they want to make a living they need to learn the quirks of the software. There are no alternatives. So the software can get away with being clunky.

If you zoom out, the insurance company is treating the human agent as a part of the service they're providing. The customer is supposed to work with the agent as the interface to the company's products and the crappy software is like an ugly, fast-spinning machine sitting in a corner of a factory. It works well enough to get the job done, even if it maims an inattentive worker every so often.

You never see this situation for consumer products. The field of competition is usually so dense, customers would quickly vote with their wallets in favor of software that is more usable and appealing. Most users would certainly not put up with software that requires specific training to use properly.

And that's where things are fun

So back to my main job as a UX Researcher and why I enjoy staying where I am – figuring out how to make usable enterprise products is fascinating!

Think about your most fundamental metric of whether your product is fulfilling its customer's needs – a simple completion of task metric. For a consumer product, if a large percentage of people can't finish their task (like purchasing an item or viewing the weather for the day), then the app is usually considered a failure. Sales and the business usually hinge upon users completing those fundamental tasks.

In an enterprise setting, that person is motivated to complete their work in the software because it is their job to do so. While they can still be frustrated, they have significantly more motivation to tough it out through interface horrors than any normal consumer. To some degree, they're paid to put up with a certain amount of BS. This means your task completion metric is qualitatively different. It's probably higher than otherwise because the "give up" point is set differently. In theory, an enterprise could have a 100% task completion rate of a ridiculously complex process just by writing down a detailed checklist of the 50 requires clicks to do a task. We see process papering over bad design decisions all the time. Think about whether you've seen examples in your own day to day work. So if you rely on just purely looking at metrics in a vacuum, you might draw the conclusion that your product is fine.

A lot of other things go a bit wonky too. For example, money. In the consumer world, purchases are a very strong signal. People paying, or not paying, for your product gives you an indication of where you stand in the marketplace. If your product is sufficiently crappy, sales usually suffer relative to the competition. But guess who's signing the contract and writing the checks for enterprise software? Often not the person directly using it. A purchasing decision goes through much more complicated evaluation processes. While end users like engineers usually have some input into what gets used, those can often be completely overridden based on the whims of an executive signing a sweetheart deal.

Another fun thing I've seen is how we can try to make a feature easier to use, with the hopes of reducing the amount of time people spend on a certain page. Sometimes we manage to reduce the time-to-task-completion metric... but users wind up spending MORE time on the page because they're working and they're just moving on to the next task.

This all means that nothing is straightforward. Signals don't always move in the direction you expect. Plus, your sample sizes for everything are orders of magnitude smaller. It takes a lot more creativity and working with other people to get even a rough picture of what is going on, let alone figure out what things should be. You're going to have to (gasp) talk to people. You'll need surveys. You'll be observing, doing usability testing, running experiments. Sometimes you're just gonna plain ol' take a guess in the dark and see what happens.

But wait, didn't I say that lots of enterprise software is crappy because there's no motivating factors in the market to make them better? Well, the enterprise products I've always worked on have consumer components. While a public cloud will happily take money from a billion-dollar megacorp as a customer, they're just as happy to take money from single developers like you and me. And it makes no sense to make a separate "easy to use consumer version" of the software. Making it so a student can't accidentally delete all their files without recourse also means a big company can't accidentally destroy their files too. Everyone benefits from better usability, and so as a side effect, I get to work in this wonderfully messy and complex space.

Oh, while not the reason I wrote this post, I just remembered that an adjacent cloud team is looking to hire a Quantitative UX Researcher. If anyone is interested in knowing more let me know.

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something a data-related post to either show off work, share an experience, or need help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

About this newsletter

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

• randyau.com — Curated archive of evergreen posts. Under re-construction thanks to *waves at everything

Supporting the newsletter

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted, so support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

• Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions
• Share posts you like with other people!
• Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
• Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!