Worst Assistant Ever
If you hire an assistant who is really talented at a couple of things, but every once in a while pokes you in the eye, how many times would you let that happen before firing them? What if they don’t poke you in the eye, but they do this kind of stuff:
- Interrogate you when you first meet
- Berate you every time you make a mistake
- Mumble incoherently when unsure of what you want
- List a bunch of skills on their resume for things they can only do badly
- Never bother to remember anything about you or any of your previous conversations
- “Accidentally” destroy your work when you push them too hard
In the face of that kind of behavior, would it matter that 80% of the time they do a good job? Unfortunately, most software products do some or all of the above (including the digital equivalent of giving you a good poke in the eye now and then). What’s worse is that many software companies knowingly create products that do these things and not only think it’s okay, but that it makes good business sense (because the ROI is too low to build products that don’t do these things).
The Little Stuff
Recently I’ve been thinking a lot about the importance of the “little stuff” in digital product design. Whether from a design, product management or engineering perspective we sometimes become focused on making sure that the primary scenarios are well served at the expense of the little things, and the overall experience suffers. This often comes out of a misapplication of the Pareto principle (the 80-20 rule) which leads people down a slippery slope that goes something like this:
- Since people spend 80% of their time using 20% of the product, it’s really important to nail that 20%.
- Since people only spend 20% of their time using that other 80% of the product, it’s okay if those parts of the product aren’t as good.
Once you take a stance that only 20% matters, it can become easy to rationalize away lazy design and implementation. More likely than not caring, this happens out of a need to prioritize time and effort under the pressure of deadlines and feature lists. In that environment, product teams will focus on the important features and just cram in the rest.
Bad Rationalizations
There are all kinds of rationalizations for doing the wrong thing and building a sloppy, confusing, and/or painful UI:
- Very few people will use that feature anyway.
- It’s an edge case.
- It’s a one-time setup, so it’s not a big deal.
- That shouldn’t happen.
- Only people who really know what they are doing should use that.
- We don’t have a choice because (fill in the blank: the lawyers, our partner, the business people) said it has to be that way.
- We have to have the feature because our competitors have it.
- We can’t be late to market.
- We can fix it in the next version.
Certainly the primary paths through a product should be well thought out, and you don’t want to organize your product around edge cases, but that’s no good excuse for knowingly doing a bad job. The reality is that people’s overall experience of a product is a collection of their smaller experiences.
Windows Vista
Using Vista is a great example of this. There’s actually a lot that’s great about Vista, but it doesn’t matter, because it beats you down with the little stuff. Here’s just one example (and I’m definitely not the first to harp on this): in the name of security, I am bombarded with dialogs asking for my approval to do things that I just told the system I want it to do. Most of the time, these aren’t confirmation dialogs like “Are you sure you want to reformat your hard drive?” but more along the lines of “Was that really you that double-clicked that icon?” This is worse than the security theater practiced by the TSA at airports, which at least arguably has some deterrent effect. Instead, I start to become inured to the dialog boxes, stop reading them and now just blindly click “OK” when they pop up. This of course has the opposite of the intended effect, reducing the level of security because I stop paying attention. Annoying and ineffective by design!
Apple
By contrast, I think this whole topic has a lot to do with why Apple’s products are often lauded:
- They get the first part right of focusing on the 20% of stuff that’s important.
- They craft the smaller experiences as carefully as the big ones. Even though you only open the box and set up a product once, it’s a pleasure.
- Instead of including features that aren’t well done, they don’t include them at all.
Now, on that third point they often spin the intentional lack of certain features by claiming that people don’t want those features. Sometimes that’s just cover for “it’s not ready yet” (and hats off to them for being pretty disciplined about getting things right before releasing them to the public). More often, though, there actually is a desire for those features in the marketplace, but Apple knows that adding them, no matter how well done, will detract from the overall experience. They have done a good job of sorting out what people need to satisfy their goals rather than directly accepting feature requests from the user base as a work list of things to add to the product.
By the way, I don’t for a minute think Apple is perfect or gets it right all the time (iTunes? that program is kind of a mess), and will gladly dig into that in future posts.
Do It Right or Don’t Do It at All
How many ways can I say that I don’t think it’s okay to make products that you know are bad? What you don’t put in your product is at least as important as what you do put in. If 80% of your features aren’t important enough for you to pay attention to, don’t include them. If you are building your product to a feature list, being “feature complete” isn’t good enough. If you do include something, make sure it is well designed, well built and doesn’t poke your users in the eye.
