The price of shipping is imperfection. If you wait for your product to be perfect, you’ll never finish it. Fortunately you can decide which features should be closer to perfect and which can slack off a little. The Kindle DX is a good case in point. Reading and flipping pages on the Kindle is a wonderful experience. On the other hand, using the keyboard is painful. The keys are hard to press. The modifier keys are confusing. Mistakes are easy to make, slow to spot and hard to correct. Yet despite all these problems, I still love the device.
A good way to square the great overall experience with a bad feature is the “suckage to usage” ratio. You can take any feature and say “it sucks,” but that doesn’t tell you anything about the whole product until you factor in how often you use the feature. Have a look at this unscientific chart.
| Feature | Suckage (1-5) | Usage | Contribution (1-5) |
|---|---|---|---|
| Reading | 0 | 90% | 0 |
| Typing | 5 | 3% | 0.15 |
| Switching books | 1 | 7% | 0.07 |
| Total suckage | 0.22 | ||
Suppose reading on the Kindle doesn’t suck at all (0 out of 5), typing sucks maximally (5 out of 5), and switching between books sucks a little (1 out of 5). Considering I spend 90% of my time just reading on the device, the contributions add up to a total suckage of only 0.22 out of 5. Inverted, that’s 4.78—basically a 5-star product.
It’s rational for the Kindle designers to skimp on the keyboard when every feature takes time and time is scarce. Maybe the third or fourth generation Kindle will change such that keyboard input becomes more important. Pressures do change over time. But for now, it’s a fair trade.
It’s easy to accept in theory that some parts of your own product won’t be up to standard. In practice, it’s hard to drop the sword. Nobody wants to release a feature that you know could be better. When this happens, try adding a factor of usage to the equation to see if perfection is really worth its price.
Grant
on 29 Dec 09I use the “suckage to usage ratio,” as you call it on Backend/Admin features as well. Stuff that isn’t public-facing and, while annoying, isn’t impossible to do manually in an app will probably not be implemented when the app first ships. Once the pain-factor is high enough, then the feature gets incorporated into the app.
Maxime Brusse
on 29 Dec 09That’s why I love Apple products. Their suckage to usage ratio is super low.
Laurie
on 29 Dec 09Its why I hate Apple products, every day something about them annoys me. Yet they are the only choice for the industry I work in. So I’m happy to use Apple gear for everything, however also more than happy to express my annoyance at the weaknesses.
Christopher Meeks
on 29 Dec 09Perfection is impossible. Literally impossible. Once people understand and appreciate that, they learn to live with that “one tiny thing that is a little off.”
I agree with you obviously, and to break it down further… Developers/engineers should focus on what something is supposed to do. Fundamentally the purpose of the Kindle is to read stuff. Make that as absolutely awesome as it should be, focus most of your energy on it. With your example, they should spend 90% of their time developing the reading experience and 10% on the other stuff.
Dylan Hafertepen
on 29 Dec 09Reminds me of the Usability Formula:
Maybe with the Nook and improved Sony eReader on the market, Amazon will spend some time improving the keyboard.
Tyler Hayes
on 29 Dec 09I like how you even applied the suckage-to-usage ratio on your unscientific chart. Sure it may not be the best way to compute the ratio, but it successfully gets the point across and my experience tells me it’s trustworthy enough.
I only wish many more people could read this article.
Dylan Hafertepen
on 29 Dec 09Yikes, images aren’t allowed? Formula:
Usability = Success(Satisfaction/Time)
Jack Kinsella
on 29 Dec 09This post highlights something that design has in common with politics: both are about making hard decisions. Design inevitably involves trade offs: the sharper the knife, the less safe.
What I like most about the suckage to usage ratio is that it calms the perfectionist within me – it reminds to forget the few ugly knotted trees and look at the forest as a whole.
Nick
on 29 Dec 09So what happens if you go for perfection every time?
Read about just that in this amazingly relevant article:
Learn to Let Go: How Success Killed Duke Nukem
Brian Wetjen
on 29 Dec 09What about when the features that work so well become such an established part of the user experience that the minor issues take on greater “suck” significance? If 99% of your product works all the time, people will take that part for granted and focus on the 1% as a reason to hate it.
This is why I think having some known improvements to make and communicating a road map of what’s to come, as well as at least accepting suggestions, whether taken or not, can keep users satisfied enough to remember that you’re always working on it and that their experience does matter.
Ricardo
on 29 Dec 09Yes! exactly my point. It is worth to mention that in your example of the Kindle, the reason amazon does not care too much about perfecting the keyboard is for that same reason you explained… not many people use it… and some (myself included) have not used it yet after months of owning a Kindle and using it almost every day.
Yes, they’ll probably will do something about it in a future release… and I am thinking it might be a new keyboard-less kindle ;-)
Jagath
on 29 Dec 09Good guideline for deciding what should go into the “release early, release often” feature list.
Companies who miss this release products that users reject -resulting in total failure.
Joel Spiro
on 29 Dec 09I wonder if the usage factor is so low because the feature sucks? Perhaps you would have to use “desired’ usage .. but then again sometimes you don’t really know how useful a feature is until it is well designed.
Todd Nichols
on 29 Dec 09I like the suckage to usage ratio. Appies well to startups who are trying to stay lean and get their product to market quickly. Combining good usage of the ratio to the feedback received by early customers can also shed a good amount of light on to what the next step in product design should be.
George
on 30 Dec 09That makes sense. It is important to focus on the features and functionality that really matter. If we focus on every detail that doesn’t matter we will never finish and nothing gets shipped.
Also, we never really know exactly what is important or how the product or service will be used until after it is shipped. So, despite the best planning, there are always improvements to make after it is “finished”.
Eva Kaniasty
on 30 Dec 09I love this formula, and completely agree. I work for a startup where we need to make these kinds of decisions all the time, and it’s great to have an explicit rule like this.
Malcolm Bastien
on 30 Dec 09It’s hard for me to think that understanding what parts of my product suck and how they contribute to the total is the end of the line there. Of course I’m going to take it as if I was someone who worked at Apple. What would the cultural reaction be to a feature we all know sucks. Leave it, fix it, or lose it? They’ve brainwashed me into believing that leaving it would be the cowards way out.
If I designed the Kindle I would have left the keyboard functionality out all together. If we go by that table at the top, that reduces my suckage by 0.15. Maybe less people would buy it, but I would know that the product sucked less.
All in all I’m just wondering about what are the options available after we work through suckage/usage.
Kevin Triplett
on 31 Dec 09The only thing I would add, and I apologize if someone else has already pointed this out, but users tend to expect 0 suckage, so they don’t take suckage 0 with the same emotion as suckage 5.
So even though typing is 3% usage, I feel it should be weighted by some factor, because people tend to magnify the negative experiences. Anything you can do to ameliorate this negative experience (customer support, feedback, wishlist, forum) can help to reduce the weight factor. :)
J Chris Anderson
on 01 Jan 10When writing workflows and UI, I try to focus on the critical path. There are some actions almost all users take (clicking the play button, signup and login) and others (like password reset or editing a comment) that get less visits.
Once benefit of edit-and-reload over automated acceptance tests is that you spend a lot of time running through the popular workflows, refining little details as you go.
I think the new continuous-deployment style is intriguing because it give end users some control of this process, and combines the good things about acceptance tests and having real eyes on the screen.
This discussion is closed.