This XKCD Chart is Crap
Do you have any colleagues who treat this chart like it’s Gospel truth? I call BS. Now, obviously I don’t call BS on the simple math at play. I call BS on using this as The Bar for whether or not to tackle an improvement. So fine, it’s not total crap; it’s just really easily abused, misinterpreted, and misapplied.
As a sometime UX (and product manager) guy, I coined and became fond of this thing I called #littlebigthings. It speaks more to the qualitative impact of a particular design (and the corresponding potential improvement of that design). If users, or you, or a colleague finds doing X extremely annoying, it will seem like a much bigger deal than it is. Little things that are perceived as annoying can have a very disproportionately big impact on experiential satisfaction (happiness).
There are many improvements that, considered in themselves, seem like “no big deal.” And many of those would fall under the “not justified” calculus in the chart above. They may not “sell the product,” but they may ultimately destroy a product through user attrition and low customer satisfaction, and for internal/dev experience, they may contribute to losing good people if ignored and deprioritized.
I want to make an important distinction that this chart — and most calculations of ROI considered in isolation — fail to make. ROI should not be considered in isolation. If you stack up enough little big things that are ignored (or even enough little things, plain and simple), they add up to an overall bad experience. This is as true of product management and product experience as it is of dev management and dev experience.
Put another way, details matter. Every design, framework, and process choice you make that is “good enough” or “not awful” in themselves add up. If you’re speaking of dev experience, it matters if you have a lot of little non-standard ways of doing things, especially when they are frustrating or simply not as good as the current state of the art. And if you let things that were “good enough” in the moment go, you may never get around to justifying fixing them in the future, especially when those things become very embedded and widespread in a codebase. It becomes harder and harder to improve such things over time.
So the next time you or your colleague is tempted to use this chart or something like it to assert that “it’s not worth the effort,” keep this in mind and give it at least a second thought, if not a third and a fourth thought as well.
