![\"A](\"https:\/\/miro.medium.com\/max\/700\/1*UiKEaORudYdyIFepvRKDnQ.jpeg\")
<\/p>\n<\/p>\n
<\/p>\n
In the world of software, you often hear about the \u201chappy path<\/strong>\u201d of a product. A \u201chappy path\u201d 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.<\/p>\n Builders of software use this \u201chappy path\u201d as a marker of how the system should expect to be handled.<\/p>\n In the real world, we know such an idyllic use case won\u2019t plausibly cover all or even most scenarios. And it then seems reasonable to ask this: If we know the \u201chappy path\u201d won\u2019t suffice, why do we so commonly explore, support, and even depend on it?<\/p>\n 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.<\/p>\n 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!).<\/p>\n 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\u2019t ship a broken product, but you won\u2019t gain customers if you never ship the product in the first place.<\/p>\n Thus the \u201chappy path.\u201d 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).<\/p>\n This \u201chappy path\u201d method of balancing disparate needs doesn\u2019t 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 \u201chappy path,\u201d it\u2019s all but guaranteed to let down some<\/em> user, someone trying to bend the tool to work in a way that wasn\u2019t originally thought of.<\/p>\n When you, as a consumer of a software product, try to do something in a novel and different way, thinking you\u2019ve found a smarter method to accomplish a task, and then the software breaks, the \u201chappy path\u201d tradeoff is probably at fault. Congratulations, you\u2019ve gone off the \u201chappy path\u201d and have encountered your own unique \u201cscrappy path\u201d \u2014 one of many edge cases that are difficult to predict and time-consuming to plan against.<\/p>\n You\u2019re not wrong to get upset that the software isn\u2019t working; if an interface allows you to perform some sequence of actions, it is essentially making a commitment that such actions will do<\/em> something (besides crash the product). And I\u2019d be willing to bet there\u2019s a UX engineer sitting somewhere at the company that produced that software who would agree vehemently<\/em> 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\u2019t be able to apply that interesting workaround you found.<\/p>\n What\u2019s the lesson here? Certainly the average software development team can\u2019t prepare for every \u201cscrappy path\u201d 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 \u201chappy path,\u201d and the few unfortunate edge case users who find their broken \u201cscrappy paths\u201d are out of luck.<\/p>\n But it\u2019s a shame we, as designers, developers, and solutions architects, don\u2019t think about software this way more often. On the development side of the software world, we often say \u2018it\u2019s a feature, not a bug\u201d when we\u2019d like to claim that some unforeseen action is actually beneficial. Why can\u2019t we lend the end user the same leniency? The user didn\u2019t \u201cbreak\u201d 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\u2019t make it any better a result. Though I try to strike a good balance, I can\u2019t pretend I\u2019m not also guilty of this oversight, especially when the pressure\u2019s on.<\/p>\n 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\u2019s 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.<\/p>\n A \u201cscrappy path\u201d is also a \u201chappy path\u201d for one particular user. If you build a system right, it\u2019s also a chance to make that person\u2019s day a bit better.<\/p>\n","protected":false},"excerpt":{"rendered":" In the world of software, you often hear about the \u201chappy path\u201d of a product. A \u201chappy path\u201d is the optimal use case, the ideal journey a user takes to accomplish a goal in a piece of software, from […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[125,147],"tags":[9,229],"class_list":["post-2066","post","type-post","status-publish","format-standard","hentry","category-programming","category-software-engineering","tag-design","tag-ux"],"_links":{"self":[{"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/posts\/2066","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/comments?post=2066"}],"version-history":[{"count":1,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/posts\/2066\/revisions"}],"predecessor-version":[{"id":2067,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/posts\/2066\/revisions\/2067"}],"wp:attachment":[{"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/media?parent=2066"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/categories?post=2066"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mberlove.com\/blog\/wp-json\/wp\/v2\/tags?post=2066"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Getting to the Happy Path<\/h1>\n
Error: You\u2019re Too Clever<\/h1>\n
The Case of Scrappy v. Happy<\/h1>\n
Understand, Build, Deliver<\/h1>\n