Building Terrible Software Is the Default

We all have to use terrible software. It’s all over the place. Whether it’s from our bank, insurance provider, or applications that we have to use at work; it’s something we all deal with on virtually a daily basis. I’ve run into some truly terrible software experiences in my day, and wrote about one not too long ago.

Everyone deals with it, everyone has to cope with it. But we cope with all of this craptacular software in different ways. Here are three personas that I think most people fall into:

1. “It’s a wasteland” – People who are just resigned to the fact that “most software sucks” and have moved on with their lives. These folks are delighted when they come across software that appears to even remotely work as expected.
2. “It doesn’t have to be this bad” – People who are truly dumbfounded by how software is as bad as it is, and get angry with broken software. But don’t worry, almost all of these folks will eventually end up in one of the other categories. These folks just haven’t had enough time to be worn down by the never-ending flow of crappy software.
3. “It’s my fault” – People who come across bad software, and generally assume that they are the problem. They think they are doing something wrong. “It can’t possibly be this bad, I just don’t know how to use it.”

Most folks who are involved in the creation of software fall into one of the first two camps, but with one distinction. They generally know why most software is terrible. They’ve seen it, they’ve lived it.

It used to be terrible because we really had no idea what we were doing, and the idea of user experience in software was a very nascent thing. We just needed to get some input from the user, and give the user some output. Very few people were worried too much about the user’s “experience”.

A Hero Emerges

Then along came Don Norman, and within a decade, the software industry had seen the light and began to build all software with the user in mind. Virtually overnight the development of software changed from an engineering driven process that rarely involved users into a design led process that put the user at the center of the process and sought to craft products and tools that met their needs.

I hope at this point you’re either gasping with laughter, or staring angrily at your screen thinking about what could have been.

We all know things didn’t go in this direction. Since Don Norman and Jakob Nielsen founded the Nielsen Norman Group in 1998 the software industry started to slowly awake to the idea that there was a better way to build software than what we had been doing. We started to realize that the people building the software were often the worst people to tell us how to design it, and that only by interacting with people who had real needs could we build software to meet those needs.

This sounds really simple. It must be simple, right?

Not even a little bit, and that is why building terrible software is the default. It seems these days that the default method of building software is to:

1. Get a bunch of software engineers, and maybe a few designers.
2. Produce some requirements using whatever combination of project manager, business analyst, product manager, product owner, crystal ball, and ouija board make the most sense for your team.
3. Put all of these things into a board of some kind. Extra agile points if you use real sticky notes.
4. Start sprinting.
5. Have meetings on a regular basis to prove to the business that you’re not just reading Reddit all day.
6. Launch software.
7. Have your first unmonitored user tests in production, and then have a flurry of follow up meetings about why users “just don’t get it” or “need some help to understand the software”.

The unfortunate reality is you can’t build good software by locking software engineers and designers in a room and saying “build good software”. But at the same time you can’t send software engineers and designers to a group of users and have them ask “what should we build?” Neither group by itself is capable of producing usable software.

And this is why so many software products still end up with horrible user experiences. Hiring a UX designer but not giving them the business support to talk to users and collaborate heavily will result in usable software that solves nobody’s problems.

Building software by talking to users takes an investment. It means you have to be willing to listen, to throw things away, to not be too precious about your solutions. But if the software you’re building is important enough, then you don’t have any other options. You have to make a decision about whether you’re going to accept the default of building terrible software, or whether you’re going to roll up your sleeves and do the hard work of uncovering your user’s true needs.