Getting to Simple – Engineers Have No Idea How Normal Human Beings Interact With Their Environments
One of the best known programming axioms is KISS — Keep It Simple, Stupid [wiki].
It is something I have incredible difficulty with.
This past weekend was filled with reminders of KISS. There were multiple comments on the complexity of my blog design. I was putting together a GUI for a WordPress.com tool even though I usually exclusively program for the command line. I finished off the weekend by reading Cory Doctorow’s “Eastern Standard Tribes” where the main character is a user experience guru with nothing but distain for engineers and computer scientists and their inability to grasp how non-geeks think:
“I spent the next couple hours running an impromptu focus group, watching the kids and their bombshell nannies play with it. By the time that Marta touched my hand with her long cool fingers and told me it was time for her to get the kids home for their nap, I had twenty-five toy ideas, about eight different ways to use the stuff for clothing fasteners, and a couple of miscellaneous utility uses, like a portable crib.
“So I ran it down for my pal that afternoon over the phone, and he commed his boss and I ended up eating Thanksgiving dinner at his boss’s house in Westchester.”
“Weren’t you worried he’d rip off your ideas and not pay you anything for them?” Szandor’s spellbound by the story, unconsciously unrolling and re-rolling an Ace bandage.
“Didn’t even cross my mind. Of course, he tried to do just that, but it wasn’t any good-they were engineers; they had no idea how normal human beings interact with their environments. The stuff wasn’t self-revealing-they added a million cool features and a manual an inch thick. After prototyping for six months, they called me in and offered me a two-percent royalty on any products I designed for them.”
It would be funny if it wasn’t so painfully true. I’d happily add features until I ended up with a monstrosity like this. My subconscious is a hamster in a wheel inside my head. He’s wearing black-rimmed coke-bottle lenses and a pocket protector. This is what he’s thinking:
I like coding.
Adding features means more coding.
Tweaking existing code that already works fine means more coding.
If I let something be finished then that means I’ll have to stop coding.
I like coding.
My favorite post I’ve ever read on the subject of simplicity is Joel Spolsky’s critique of the Windows Vista start menu: “each additional choice makes complete sense until you find yourself explaining to your uncle that he has to choose between 15 different ways to turn off a laptop.”
But even he notes that the answer to simplicity isn’t having less features. Having a sparse highly usable design is a feature in itself. The key is to have robust features without confronting the user with multiple choices. Simplicity is actually quite complex — which makes sense because otherwise Apple and 37signals would be the rules, not the exceptions.
John Maeda’s Laws of Simplicity provides some rough guidelines for Getting to Simple:
- Reduce – The simplest way to achieve simplicity is through thoughtful reduction.
- Organize – Organization makes a system of many appear fewer.
- Time – Savings in time feel like simplicity.
- Learn – Knowledge makes everything simpler.
- Differences – Simplicity and complexity need each other.
- Context – What lies in the periphery of simplicity is definitely not peripheral.
- Emotion – More emotions are better than less.
- Trust – In simplicity we trust.
- Failure – Some things can never be made simple.
- The One – Simplicity is about subtracting the obvious, and adding the meaningful.
Part of the reason why I blog is because it forces me to work on soft skills like this. It’s a subject I need to learn more about.
Subscribe to comments with RSS.
Comments are closed.