When it comes to designing products a modicum of restraint should be employed to ensure a successful result. Sure there are many features that could be added just because they are possible but I ask you to live strictly by the following cliche - keep it simple stupid. The notion of “just because” has been a thorn in my side in nearly every process I’ve participated in. Think of the following story the next time you find yourself mid feature-creep.
Jeff Hawkins is perhaps best known for being at the helm of Palm Computing Inc, the makers of the groundbreaking Palm Pilot. In the early 90s a number of companies attempted to move into the portable computing space and unfortunately crashed and burned. Apple for instance spent five-hundred million dollars to develop the Newton. As history would show Newton was a flop. It was a masterful attempt to cover far too much ground without being excellent at any one thing in particular.
As if a miracle, the first Palm Pilot prototype was developed for a paltry three million dollars. This begs to ask what was different about their process and final creation? The answer you’ll see was both intriguing and head slappingly obvious.
The first product that Palm Computing released would be the little known Zoomer PDA in 1993. It was a seven-hundred dollar portable handheld intended to be sold at Radio Shack. Price aside, though it were high in technology it was mired by a design by committee process. Like the Newton, Zoomer didn’t hit the mark either. Luckily however through means of a savvy business strategy Palm had enough funds to make another go at it. The second time around they conducted research using early Zoomer adopters as their focus. What they found was that surprisingly the vast majority (90%) wanted to marry their handheld to their personal computer. Who knew that being able to sync data seamlessly would be such a huge breakthrough (see ipod+itunes).
In 1994 work began on the second Palm device which would be released as the Pilot but ultimately known as the Palm Pilot. With the learnings from the research in hand and a distinct distaste for design by committee Jeff established a few stipulations.
1. It would fit in a shirt pocket
2. It would run on AAA batteries
3. It would sell for less than three hundred dollars
This is where the story takes a turn towards the quirky. Jeff went into the machine shop and cut a block of wood out to roughly the size and shape that he had in mind. The block fit well in shirt pocket and felt comfortable in his hand. He carried it everywhere he went. He’d take fake phone calls on the block of wood just to see how it felt. If he had to write down an appointment he would jot it on the block. If stopped by someone, in the hallways, whom had an idea for a feature he would take out the block and after hearing their pitch find a place for it. As the block filled up with features it was obvious that cuts had to be made. If a designer was adamant about an addition they’d have to convince Jeff to erase another. Often was the case that the designer/engineer would argue that it was an easy thing to add. Unfortunately, there just wasn’t infinite real-estate on the block. After a week the Palm Pilot was born. The rest, as they say, is history.
What can be divined from this anecdote is that just because something can be implemented easily doesn’t mean that it is in the best interest of the user. I’ve probably pointed to “Clippy” a million times but I’ll once again point to our ironic anti-hero. I’m not advocating the complete abolishment of automation. Though please consider that if the ultimate goal of design is to fade into the background then any frustration caused by assumptions should be avoided.
It’s important to establish what your product does. Don’t fear making a statement that your device is strictly an MP3 player and nothing else. Though if you make this proclamation take all actions necessary to avert a feature creep. The Palm Pilot managed to crack the handheld code, because unlike it’s predecessors it was specific about its intent at the cost of discarding unnecessary features.
Extra Credit: Wired Magazine Article on the Block of Wood - Circa 1999
April 10th, 2010
1 Comment at "Just Because It Can"
I love this analogy, but I’ve been trying to figure out how, in my own little world, to apply it to software development (web or otherwise), where the real-estate is theoretically infinite. One of the normal ways I’ve tried to tackle it is with deadlines and breaking up feature-sets, but that’s easier to do once the software is through the concepting stage and you’ve already planned out your features.
What I really want is something with the physical analogy, early on in the concept process. Maybe a single sheet of paper, or a small-ish white board. Handwrite features on it. Once it’s full, to add a feature or feature-set, you have to remove one?
Comment Now!