No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry. Bad software, or bad anything, happens because making things is hard, making good things doubly so.
The three things that make it difficult are:
Possessing the diverse skills needed not to suck.
Understanding who you’re making the thing for.
Orchestrating the interplay of skills, egos and constraints over the course of the time required to make the thing.
Individually these challenges are significant, but combined they create a wall of suck so high that few people can see the top, much less throw anything over to the other side.
What it means to say “this sucks”
Whenever you hear someone say “This sucks” they are doing several things simultaneously: expressing frustration, experiencing shock, using criticism to mask feelings of helplessness in a cruel universe, and, most importantly, communicating the gap between their expectations and reality. It’s rare to hear people complain about things they don’t care about.
One way to think about how people respond to things is this spectrum:
What is this for?
I have that but haven’t tried it
I’m annoyed by this, but I don’t need it often
This is acceptable
This is cool / I love it
This works so well I don’t even think about it
This is just one representation of how people respond to things. The point of this representation is that “this sucks” is right in the middle. In order for people to say “this sucks” they have to care enough about the thing you’ve made to spend time with it and recognize how bad it is. For things that are equally bad, but are unimportant to someone, you won’t hear the same complaint. We’re frustrated most in life by things that come close to our deepest needs, but don’t deliver. It’s the things that tease us, making us think they’ll satisfy us but then fail, than hurt the most.
Looking towards the bottom of the spectrum, the better designed something is the more positive the responses are. But the surprise is that the best possible design for many things, especially things perceived as work, requires no change in behavior for the person using the thing. These designs are so good they eliminate unnecessary interactivity: they just do what they’re supposed to do without bothering you. Think better batteries, tastier food, fuel injection systems, web server upgrades, etc.
For most people, most of the time, they really don’t care about the details of however the thing you’ve made works: they care only about the effects of the thing you made. If they can enjoy most of the benefits without any work, they’ll be very happy.
This suggests that one common reason for suckage is the creator (or programmer) wanting to share their world, the internal world of how things work, with their consumers. They may do this out of love: “If I think this is fun, won’t they?” But often there is a violent mismatch of desires. The creator wants the consumer/user to care about the very things the consumer doesn’t care about.
Creator: I love the power of Unix/AJAX/C#/whatever. Customer: I want to finish my work and go play outside.
Sometimes this love is so strong that when a creator hears a “this sucks” or even a “I can’t figure this out” response, they take it as an attack on their beliefs, rather than feedback on the details of the design. Creators, often sensitive about their work, may respond by rejecting the very people they were supposed to be designing for, starting the ugly downward spiral of resentment and passive aggressiveness between creators and consumers, which can end only with one result: software that sucks.
The translation table for “this sucks”
If you look deeper, you’ll find that when people say “this sucks” they mean one or more of the following:
This doesn’t do what I need
I can’t figure out how to do what I need
This is unnecessarily frustrating and complex
This breaks all the time
It’s so ugly I want to vomit just so I can see something prettier
It doesn’t map to my understanding of the universe
I’m thinking about the tool, instead of my work
These issues represent a diversity of skill failures. To avoid causing these feelings in people you’d need a combination of talents few people have. The above list represents skills including: interaction design, software engineering, quality assurance, product planning/strategy, visual design and project management. Some rare individuals are good at all these things and god bless them, but most of us need to admit and grow out of our weaknesses, or involve other people if we want to make things that don’t suck.
If we invert these feelings, we’ll find common responses people have to good software.
This satisfies my needs
I can figure out how to do what I need
This is smooth, seamless and fun
This never fails
It is based on my understanding of the universe
I think about the results I want, not the tools
These responses never happen by accident. And it’s not brilliance or genius levels of skill that makes it happen either. Instead it’s the orchestration, the combination of different skills that makes it all come together (or not). You might call this direction, leadership, management or some other word. There might be a person who has the dedicated role for it, or it could be a communal responsibility. But however it happens, it defines our first law:
Law #1: If you don’t apply the right skills at the right time, you will make things that suck.
The trap is that this law applies no matter how good you are at any particular skill. At a certain point the best thing you can do to prevent making bad software is to start learning a skill you don’t have instead of improving a skill you’ll already strong in.
The learning curve myth
Some of the issues from the translation table above are often hidden behind the notion of learning curves. The creator will say “No no no: it doesn’t suck. You just have to get used to it” even if it’s a website with moving blinking yellow neon text or a laptop with a keyboard made from damp urine soaked cardboard.
The truth is that human beings can tolerate lots of stupid annoying things: just because your website forces my brain to rewire itself to work around your incompetence doesn’t mean you’ve designed something well. I admit that to make a new thing possible demands change, but how much that change negatively impacts the user is the designer’s burden: they should be protecting me from unnecessary work.
As a first order principle, the best designs require no learning curve. The thing should be so brilliant that it can improve my life without me having to do anything new (If you turn your imagination on before ranting in disagreement, you can imagine non-intrusive ways to improve many things). Three out of every five times someone speaks of a learning curve, they’re just in denial about a weak design.
The definition of a good learning curve has two parts:
The design returns value beyond the learning cost paid. If I pay 10 hours of learning curve time, but get 20% more productivity afterwards, earning me my time back plus more, it’s a good trade.
The design matches the learning curve expectations of the customer/user. I might be willing to suffer an intense two week learning curve to learn a new language (given my faith in #1), but I’d run screaming before investing that much time just to get $50 out of my local bank machine.
Whether the designer realizes it or not they are deciding how much of a learning curve users will experience. Since most of the time most people are using websites, software and other things made by other people, it’s good advice to assume that people don’t want to invest much effort in learning how to use your particular creation. They’d much prefer you reuse the knowledge they’ve already paid the price to learn.
The expectation gap
Expectations are tricky. When we complain about the world we’re really saying that we don’t like how different reality is from what we expected. When someone says “this sucks” they’re really saying “this doesn’t meet my expectations”.
Since every person is different (some more different than others), good designers spend time trying to understand and work to match or exceed people’s expectations. This is a highly speculative activity (there are methods that help, but that’s not my point). People’s expectations change all the time, and the larger the group of people you’re designing for, the greater the probability that some of their expectations will be in conflict. Which gives us the following law:
Law #2: No matter what you do, someone, somewhere will think your software sucks.
This isn’t a justification for bad software. But it is a reminder that every piece of software in the history of the universe (including Apple products) has someone somewhere that hates them. As a rule, the larger the group of people you are trying to design for, the more complex the matrix of expectations you, as a designer/creator, have to manage. It’s for this reason that many market leading products (music, food, clothes) take safe, conventional approaches to how they look and behave: they’re trying to find a sweet spot, however bland, in the expectation matrix of thousands (or millions of) people.
References & Notes
This essay is a recasting of what I’ve learned over a career. It was presented at Foo 2005 (thanks to those that came).
I did not refer to any books or sources in writing this essay, but several come to mind as references.
The design of everyday things, Don Norman. This is most well known UI design and human factors book in the world. It serves as a fantastic introduction to thinking about the mental processes people use to interact with the world and breaks down why many objects are so prone to causing frustration. It’s well written and filled with pictures. But it does not offer a solution or a process for avoiding failure.
The elements of friendly software design, Paul Heckel. This is an amazing little book. It’s the perfect companion to design of everyday things, since it focuses on how to approach things from the creator’s view, not the analysts view. It’s a hidden gem – few people know of this book (Steve Capps is the only designer I’ve met that had even heard of it).
Flow, By Mihaly Csikszentmihalyi . Here is the best reading about what’s going on when you get lost in your work or play. Good software has the same effect, helping people get lost in the experience instead of struggling with the tools.
The inmates are running the asylum, By Alan Cooper. Be warned: this is a well written but strongly opinionated piece. It excels at capturing many of the underlying reasons bad things are made, breaking down how technologists and businessmen can allow their biases to get in the way. The problem is that almost no practical remedies are offered here. Cooper also tends to blame programmers for just about everything, but the strengths of his points and his writing earns it a place here.