Less is more

When writing software, we should approach our own ideas with skepticism. We have more ideas than users have needs.

Features do not guarantee success. If they did, we would line up to trade smartphones for punch cards. Myspace would acquire Twitter. Picasa would be the new Instagram. This doesn’t happen. The history of software is the history of simplicity and elegance winning. We succeed when we attend to what really matters, not when we build every feature imaginable.

So we can’t trust our intuition. Can we trust our users? Not necessarily. Donald Norman summarizes the problem nicely in The Invisible Computer.

Don’t ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated.

Users report immediate concerns but rarely consider complete systems. Designers are needed to put things into context.

We easily detect when engineers make this mistake. Someone re-implements a library. Another asks for help with a complex regular expression. We immediately know something is wrong. “What are you ultimately trying to accomplish?” we ask. “More code may not be the answer.”

So too with product development. Sometimes, less is more.

Remember this the next time someone requests a feature. Rather than adding preferences, try finding better defaults. Rather than writing tutorials, try building simpler controls. Cure the disease rather than the symptoms. Ask yourself if a new feature is really the best solution. The answer may surprise you.

Originally published at blog.openjck.com on May 21, 2015.