In the world of software, you often hear about the “happy path” of a product. A “happy path” is the optimal use case, the ideal journey a user takes to accomplish a goal in a piece of software, from start finish. In such a conception, we expect that the user acts intelligently, provides reasonable input to forms and other controls, performs tasks in a sensible and predictable order, and does not stress the system.

Builders of software use this “happy path” as a marker of how the system should expect to be handled.

In the real world, we know such an idyllic use case won’t plausibly cover all or even most scenarios. And it then seems reasonable to ask this: If we know the “happy path” won’t suffice, why do we so commonly explore, support, and even depend on it?

Getting to the Happy Path

A quality software system endures many levels of testing before being released to the user. In a proper release flow, even the least plausible cases have been considered, tested against, and either disallowed from the user or elegantly avoided: the system is robust, and the builders are confident in its ability to handle whatever a user may throw at it.

In practical reality, we often lack the time and resources to handle all edge cases (there are so many!) or to ensure the soundness of each component of the software and how those components relate (the connections are practically infinite!) or to plan against every improper use of the software (users are very creative!).

So when it comes down to the wire and a project deadline is looming, we look at the software, at all its moving parts, and we ask where the line should be drawn. We consider how best to trade off between what ought to be done and what may realistically be accomplished. You can’t ship a broken product, but you won’t gain customers if you never ship the product in the first place.

Thus the “happy path.” It is the core use case, the key way we expect a feature or tool to be used. It is this flow, over any other, that must be supported, prove strong, stable, flawless (or appear so).

Error: You’re Too Clever

This “happy path” method of balancing disparate needs doesn’t always bear out well for an individual user. When someone purchases a piece of software, that person will naturally leverage their new tool however best suits the needs of the moment. But when software is built primarily around a “happy path,” it’s all but guaranteed to let down some user, someone trying to bend the tool to work in a way that wasn’t originally thought of.

When you, as a consumer of a software product, try to do something in a novel and different way, thinking you’ve found a smarter method to accomplish a task, and then the software breaks, the “happy path” tradeoff is probably at fault. Congratulations, you’ve gone off the “happy path” and have encountered your own unique “scrappy path” — one of many edge cases that are difficult to predict and time-consuming to plan against.

You’re not wrong to get upset that the software isn’t working; if an interface allows you to perform some sequence of actions, it is essentially making a commitment that such actions will do something (besides crash the product). And I’d be willing to bet there’s a UX engineer sitting somewhere at the company that produced that software who would agree vehemently with you and has been begging the team lead for permission to fix the bug you stumbled onto. But chances are strong that your bug, that rarely-seen edge case you found, will keep getting pushed off as new and more crucial work is discovered, and so you still won’t be able to apply that interesting workaround you found.

The Case of Scrappy v. Happy

What’s the lesson here? Certainly the average software development team can’t prepare for every “scrappy path” a user can discover. At some point, realistic tradeoffs must be made, and of course, the bottom dollar comes from the majority of customers whose base needs are being met by the “happy path,” and the few unfortunate edge case users who find their broken “scrappy paths” are out of luck.

But it’s a shame we, as designers, developers, and solutions architects, don’t think about software this way more often. On the development side of the software world, we often say ‘it’s a feature, not a bug” when we’d like to claim that some unforeseen action is actually beneficial. Why can’t we lend the end user the same leniency? The user didn’t “break” the system; they used inputs they were given by the builders of the software to accomplish a task, and the software let them down. This gap is understandable, but that doesn’t make it any better a result. Though I try to strike a good balance, I can’t pretend I’m not also guilty of this oversight, especially when the pressure’s on.

Understand, Build, Deliver

The effectiveness of software in a human world stands to make a much better impact if we think of an end product not as a tool for accomplishing specific goals we proscribe, but as a collection of controls handed to our users. Software gives people a means through which to more easily accomplish their tasks, whatever they may be. It’s less the job of a builder to predict such tasks, and more so to think about how to build a system that allows a user to navigate a conceptual space without fear. A beneficial product gives the user their data and a means to control it, lends enough guidance to keep things secure and running smoothly, and then gets out of the way.

A “scrappy path” is also a “happy path” for one particular user. If you build a system right, it’s also a chance to make that person’s day a bit better.