Why good designs fail as early as possible in the userjourney.Theres a principle in design that doesnt have a nameat least, as far as I knowbut can make or break products and services due to the intense frustration and rage elicited from users when the principle is violated. Ive taken to calling it failing early because I keep seeing it pop up everywhere.Just to clarify, Im not referring to the fail fast principle in startup culture in which its preferable to spend minimal resources to test an idea, but its a tangentially relatedconcept.At first glance, failing early doesnt sound like a good thing. Why would I want my service to fail at all? you might be thinking.But hear meout.Why is it important to failearly?Whether your product is software, or a retail operation, or any other service, you cant fulfill all customer requests all of the time. You might have geographic constraints that limit your service coverage to certain areas, disruptions to your supply chain that make certain products unavailable, or you might simply get requests that are outside of your core competency.In those situations, its better to let the customer know at the earliest possible time that they cant get what they want. Thats failing early in a nutshell.In a way, failing early is an extension of the UX heuristic visibility of system status, which advises us to present feedback to the user as quickly as possible in order to create trust through predictable interactions.Failing early vs. failinglateConsider the scenario when an experience fails late. Lets say you go to a restaurant. You leaf through the menu, take a few minutes to decide, and finally call the server. The server takes your order. After 15 minutes of waiting, he informs you that the salted fish fried rice is unavailable and asks if you want to have it replaced. You reluctantly agree. After all, youve already spent 15 minutes waitinga sunk cost fallacy, but lets leave that discussion for another time. After another 20 minutes of waiting, the iced tea and beef brisket arrives but the server informs you that the dumplings you wanted are unavailable. By then your frustration is reaching volcanic levels but its too late to back out now. You eat the food you didnt want in the first place, make a payment, and leavevowing to leave a badreview.Compare that to the alternative of failing early. You arrive at the restaurant and take your seat. As soon as you sit down, the server immediately informs you that dumplings and salted fish fried rice are unavailable. You decide to go elsewhere.Flow chart illustrating the fail late vs fail early restaurant scenario we discussedFailing late creates so much frustration and annoyance because it wastes your time and locks you into suboptimal options. Conversely, failing early helps you avoid wasting time and resources and maximizes your autonomy.Applying the fail early principle to a food deliveryappSo how do we apply the Fail Early principle?First, you need to identify your failure scenarios. For a food delivery app, this might include the following:The restaurant isclosedThe delivery address is outside of the serviceareaA specific food item is unavailableExpected delivery delays due to a lack ofridersThen, you need to design your customer journeys and flows so that the failure scenarios can surface at the earliest possible time. This is why its common for delivery apps to ask for your location at the beginning of the journey so that it can immediately filter out all restaurants that dont include your address in their servicearea.Screenshot of the Puregold grocery delivery app which asks for the location so it can filter out grocery items relevant for a givenbranchClosed restaurants can be handled by either hiding them from the search results or showing them from the search results but placing a label and applying visual styling to indicate that theyreclosed.Unavailable food items can be handled similarly by applying visual styling and clear labels to indicate theyre out ofstock.Screenshot of Grab Food delivery clearly communicating unavailable itemsFailing early in digital banking and mobilewalletsUsing the method we discussed earlier, lets first identify a key failure scenario for digital banks: third-party downtime. Mobile wallets and digital banking apps typically integrate with a swathe of other third parties to provide services such as paying bills, adding money to your account, sending money across banks, and so on. Inevitably, these other parties will experience downtime.Now, as weve talked about, we need to push the failure as early as possible in the user journey to avoid frustration.For example, if theres a bank transfer facility and the third-party is down, then we shouldnt let the customer proceed with the transaction at all so that they dont waste time typing the recipients account number and amount, especially if they havent saved those details previously.Screenshot of mobile wallet showing that one of the banks, BDO, is unavailableHow do you actually failearly?We now know how to apply the principle on a high level. Theres still one remaining question, though: how do we actually inform the customer in a digital app or service? Should we show an error? Hide the problematic service or product? Disable theitem?As usual, it depends on the context. The most important thing is clearly communicating why they cant proceed with something.For out of stock products, you could place an Out of stock or Unavailable badge along with subtly greying out some of the colors, though keep in mind your contrast ratios for accessibility.Screenshot of e-commerce app with Sold Out badge on A3 paper item, Out of Stock indicated under Quantity, and button label changed to Add to Wishlist instead of Add toCartFor unavailable services like our bills facility on downtime earlier, we can apply a similar badge along with slightly greying out the icon. Then, show an error message when they tap on theicon.What you SHOULDNT do is just disable buttons or actions without any explanation via copy or error message. Disable buttons is generally bad practice because the user often doesnt know why its disabled.What if you hid the unavailable item instead? Well, hiding has a similar issue: the user doesnt know what happened and why they suddenly cant find a feature or product they wanted. Usually, its only a good idea to hide something in the UI if its irrelevant to the current mode or situation. There are some exceptions.In our example of a food delivery app earlier, you could initially hide the restaurants that are closed, i.e. outside business hours, but provide a filter to show closed restaurants so that customers can order for the next day. Or, you could sort the search results so that the closed restaurants show up at the bottom. That way, the results are more relevant but the customer can still find the closed restaurants.Key takeawaysFailing early means informing customers as soon as possible when you cannot meet their needs, which helps avoid frustration and wastedtimeIdentify potential failure scenarios and find ways to surface them to the user as early aspossibleClearly communicate why the product, service, or function is unavailableFail early: the hidden design principle behind great UX was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.