Death by a Thousand Paper Cuts

| Comments

Paper cuts hurt, sure, but they aren’t fatal. However, what happens when you receive hundreds of paper cuts? Well, actually, I’m not sure, but I imagine you’d be in a lot of pain. And suddenly, something that isn’t particularly harmful on its own becomes painfully obvious. This concept ties in well to software engineering, especially to front-end software development.

tl;dr

Paper cuts are minor software usability flaws that can be easily corrected. They add up to cause an appreciably worse user experience and give software an unpolished feeling. Users can perceive them as indications that you don’t care about their experience. Taking time to actively correct paper cuts is a cheap way to make your software better. Dealing with paper cuts is part of an overarching mentality of desiring to make a user’s experience with your software good.

What Is a Paper Cut?

The Ubuntu team classifies a paper cut as—among other things—a small, easily fixed bug or annoyance that a user will experience frequently. And their goal is to heal one hundred of them or so in each major release. This is a very admirable goal and one that I think is extremely important. As a very detail-oriented person, I am frequently annoyed when I encounter UX paper cuts in the software I use. For a given piece of production software, I will write the software off as unusable if I encounter 20 or so paper cuts, even if the software actually does what it claims to do. More companies need to be allocating resources to this end.

Okay, okay, but what is a paper cut? I think all of these are good examples of usability paper cuts:

  • A misspelling or obvious grammatical flaw
  • An error message that contains a bunch of technical output instead of a human-readable description
  • A button that is “almost centered” in the view
  • The screen jumping from one state to another instantly with no sort of “ease in” transition
  • Keeping the app locked in a “waiting” state while loading some data, preventing the user from changing their mind and canceling the operation

These types of mistakes are typically the result of bad judgment or rushed development.

Why Should I Care about Paper Cuts?

“After all, it’s more important to spend time adding new features than it is to waste time on all these little glitches that nobody cares about.” I think many software engineers, product managers, and CEOs think this way. I couldn’t disagree more. Paper cuts add up, and they do cause problems for users.

Consider a simple app with one view. Maybe this app only has a single paper cut. Okay, that doesn’t sound so bad. Let’s say that that single paper cut reduces the overall usability of your app by 10%—for a very simple app, such a large percentage is conceivable. Now your app is at most 90% usable. “90% sounds pretty good to me,” you might say. Maybe so, but you’ve just capped your app’s usability with something that can be trivially corrected.

Now consider a more complex app with tens—if not hundreds—of views. If paper cuts aren’t something being regularly taken care of, it’s feasible that your app could have multiple hundreds of paper cuts. Let’s assume, again, that these paper cuts add up to a total loss of usability of 10%. Only this time, your app is much more complex, so it’s incredibly likely that you’ll have a handful of serious bugs or other usability flaws. So the likelihood that your app’s overall usability will still be at around 90% is probably very low. Maybe now it’s only 70% usable. Paper cuts aren’t to be taken lightly.

The net effect of neglecting to fix paper cuts and other usability flaws is that your user may perceive such inaction as an indication that you don’t really care about their experience.

And really, why wouldn’t you fix something that’s easy to fix? It’s an easy win that can result in a much more pleasant experience for your users. More importantly, though, I personally feel that it leads to an overall state of mind that is honed to identify, be intolerant of, and tackle UX flaws in general.

Okay, So How Do I Identify and Fix Paper Cuts?

This may not always be very obvious. Here are some ideas that immediately come to mind:

  1. At least one person involved with the creation of your software should generally be a detail-orientated person. A software engineer who doesn’t particularly care about design or usability isn’t likely to notice the slightly misaligned text label or even think to offer the user a way to cancel a lengthy operation. And a product manager may be too busy juggling every member of the team to spend extra time hunting for paper cuts. Someone who is naturally detail-oriented can’t help but notice when things “aren’t quite right”.
  2. Real-world usage of your software by a representative member of your target audience—someone who isn’t involved with the creation of your product—is invaluable. It’s far too easy, even for fastidious people such as myself, to become blind to many common usability flaws as a result of spending so much time following “obvious” usage cases while the software is being developed. A fresh pair of eyes will quickly point out what doesn’t make sense, especially if they have very little information up front about how to use your product. I often hear that people want to put their apps out in the wild first and use that as their “real-world user base” testing phase. But that presumes that users who encounter paper cuts will a) actively be aware of the problems they’re encountering and b) will take the time to let you know when something is wrong. I much prefer to vet things out before releasing a v1.0 product.
  3. Keep a list of “things to be aware of” related to common software usage patterns. If you encounter a paper cut, document where it occurred and what the fix was. Even if it’s trivial! Next time the same paper cut arises, you’ll already have your first-aid kit stocked with the necessary treatment. Plus, over time, it should become more obvious what to look for.
  4. Make it a part of your regular QA. Even if you don’t have a formal QA team, surely you test your software before releasing it! (If you don’t, you don’t deserve to be creating software that actual humans will interact with.) So budget time to look for paper cuts and treat them as bugs to be fixed along with any other “more serious” problems.
  5. Leave design and usability to the experts. Don’t forego adding some solid design and usability talent to your team. Just because you’re the CEO and your daughter, who takes art classes at the local community college, already designed some “cool-looking” graphics doesn’t mean you’re finished with that part of the project. Great design and usability talent is just as important as your “ninja iOS developer” and “rockstar Rails guru”.

Wrapping Up

Personally, I am not excited or driven by the mere concept of creating software. In fact, I actually don’t like to say that I create software. I prefer to coin myself as a Software Experience Engineer. I know, it sounds really corny, but I mean it. I don’t brag about such-and-such algorithm or some super complex logic; don’t get me wrong though, I greatly value and respect those aspects of software development. But what I really get fired up over is awesome UI, custom animations, subtle visual transitions, and whatever else enables me to craft something truly special for the user. And if I see something wrong with the experience I’m creating—even if it’s seemingly insignificant—I stop to fix it.

Great user experiences don’t just pop out of nowhere. They are delicately crafted, finely tuned, and well cared for. Before adding on that “next great feature”, are you sure that the features you do have aren’t broken? Certainly, there is much more to making a feature truly great than just fixing little nicks and scrapes here and there, but that doesn’t mean paper cuts are insignificant.

As always, I like to write these posts as a means of sparking dialog. I’m not a usability expert, but I sure know what feels right to me as a software developer. And I know many other people—software developer and layman alike—who feel the same way as I do about this stuff. Maybe I’m wrong, or maybe I haven’t even taken into consideration some other factors. So let me know what you think!

Comments