Product Design — is like painting but the paint never dries

Design is all about Communication. You’re trying to present information to the user, to tell them what can be done, and to show them how to do it. Unfortunately, many programmers don’t realize that because they know so much about their software that they think of it in a completely different way than the user. We can’t remember what it was like to be a novice. This is called the curse of knowledge, a cognitive effect beautifully demonstrated by a Stanford study:

In 1990, Elizabeth Newton earned a Ph.D. in psychology at Stanford by studying a simple game in which she assigned people to one of two roles: “tappers” or “listeners.” Tappers received a list of twenty-five well-known songs, such as “Happy Birthday to You” and “The Star Spangled Banner.” Each tapper was asked to pick a song and tap out the rhythm to a listener (by knocking on a table). The listener’s job was to guess the song, based on the rhythm being tapped. (By the way, this experiment is fun to try at home if there’s a good “listener” candidate nearby.)

The listener’s job in this game is quite difficult. Over the course of Newton’s experiment, 120 songs were tapped out. Listeners guessed only 2.5 percent of the songs: 3 out of 120.

But here’s what made the result worthy of a dissertation in psychology. Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds that the listeners would guess correctly. They predicted that the odds were 50 percent. The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why?

When a tapper taps, she is hearing the song in her head. Go ahead and try it for yourself — tap out “The Star-Spangled Banner.” It’s impossible to avoid hearing the tune in your head. Meanwhile, the listeners can’t hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code.

As a programmer, when you’re designing your software, you’re always “hearing the tune in your head.” Your user, however, doesn’t hear anything. All they have to work with is the user interface (UI) you designed. You can’t expect the user to know what you know and you can’t rely on filling the gaps with documentation or training — as Steve Krug, a user experience professional said, “the main thing you need to know about instructions is that no one is going to read them”. So your only option for building a successful product is to get great at design.

This might sound obvious, but it’s easy to forget it as a programmer because the tools you use to do your job are the pinnacle of bad design. In part, this is because most software designed for use by programmers is also designed for use by the computer, and the computer doesn’t care about usability.

Even if you get past the hurdle of understanding your users, the second question, “What are they trying to accomplish?”, still trips many people up. One of the most common design mistakes is to confuse a user’s goals (what they want to accomplish) with tasks (how they can accomplish it). A classic example comes from the Space Race during the Cold War. NASA scientists realized that a pen could not work in the microgravity of space, so they spent millions of dollars developing a pen with a pressurized ink cartridge that could write in zero gravity, upside down, underwater, and in a huge range of temperatures. The Soviets, meanwhile, used a pencil. This story is an urban legend,2 but it’s a wonderful illustration of what happens when you lose sight of the underlying goal and become overly focused on a particular way of doing things. As Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail”

The first and simplest thing to start with is the user story. Before you dive into the code, you should be able to define a user story. A user story is a short description of what you’re building from the perspective of the user. It should answer three questions:

• Who is the user?
• What are they trying to accomplish?
• Why do they need it?
• Answering these questions could lead to the MVP, even without writing a single line of code!