Edge Cases: When Users Stray From the Happy Path

Many developers talk about the “happy path.” It’s that perfect journey they’ve designed to take users from start to finish as quickly and painlessly as possible. But no matter how well you’ve designed your software, there will be times when users leave the happy path and take a trip along the cliff’s edge.

Well-designed products will keep most users on the happy path, but there are always cases that are unforeseen or outside of your control. These uncommon scenarios are called edge cases.

In this post, we’ll discover where edge cases occur, why they’re important, and how to mitigate their negative impact so that every user journey has a happy ending — no matter which path they take.

What are edge cases?

We can define edge cases as situations developers do not expect to occur in most situations. Let’s look at some examples of edge cases.

1.    Users don’t understand what to do. They may enter data or click buttons that your design did not anticipate.

2.   Users don’t use the product for the purpose you expected. We’ve all heard the story of the user who thought the CD drive on their desktop was a cup holder. Users come up with innovative ways to break products by using them in ways that are unfit for purpose.

3.   A dependency resource becomes unavailable. This can happen if your product depends on an internet connection and a user loses the signal. This is exactly the case we considered for THAW, whose users are likely to be out and about in extreme conditions.

This could also happen if software depends on a particular library of code, and the provider decides to change or remove it.

4.   Corner cases, where two unlikely events occur together to produce unexpected results. You can handle multiple users registering at the same time and multiple users with the same name registering, but these events happening simultaneously could cause a corner case.

5.   Users trying to use obsolete or innovative technology that you didn’t include in your design. Unforeseen screen sizes, resolutions, and refresh rates have all caused edge case errors in the past.

What do edge cases look like to a user?

One of the most common results of edge cases in digital applications is a complete shutdown of the product with no warning. Users must restart the product and start again. This is bad.

But even worse are edge cases that lock a program in a state that doesn’t even allow a shutdown. In these cases, users have no choice but to perform a hard-close or, as a last resort, a system restart.

Less severe but equally common edge cases are blank screens or screens with missing elements that don’t allow a user to continue or find their way back to the happy path.

And there are even edge cases that users may not recognize but have a negative effect on performance. Slow loading times, wrong or missing information displayed, or unresponsive elements all negatively affect the user experience.

Why are edge cases important to consider?

So, if these edge cases only happen in a few cases or to a small subset of users under unusual circumstances, why are they so important to consider? There are two main reasons.

First, consider that users with a poor experience with your product will likely stop using it. Losing even a percentage of your customers due to edge cases would have a detrimental impact on your business.

Second, if edge cases produce unexpected results or introduce incorrect data, an edge case failure could cascade to impact all your users and leave you with a much bigger problem.

Why test for edge cases before releasing?

It should be clear that you can’t afford to let edge cases into your product’s release version. Leaving edge cases for users to find results in buggy products and bugs result in unhappy users who could leave bad reviews or otherwise damage your brand. 

Users, unlike testers, rarely give clear feedback on bugs and how to reproduce them. Finding and mapping bugs in released software is a chore that needs to be minimized as much as possible through pre-release testing.

If the impact of edge-cases is severe enough, it can result in recalled products and extensive time wasted in redevelopment.

An excellent Quality Assurance team that considers edge case testing during product development can save your business money and time and protect your reputation.

Beyond testing: planning for edge cases from the beginning

Experienced design teams start thinking about edge cases as soon as they consider the “happy path.” They repeatedly ask themselves, “What happens if the user departs from the path at this stage?” At Cheesecake Labs, we do this by wireframing every screen.

In the ideal scenario, the design team can reroute the user back to the happy path, either to the same step or, if necessary, to a previous step.

Let’s consider an example where a customer is on the happy path, purchasing an airline ticket through your product. An unexpected error occurs at the credit-card validation stage, and the purchase fails. A superior design team will have considered the edge case and allowed the user to retry without entering all their information again. Providing the shortest route back to the happy path is usually the most desirable solution.

But what if the credit card company has a problem and returns data in an unexpected or corrupted format? There’s no way to account for all the possible scenarios, but experienced designers can implement catchall solutions, so unexpected inputs cause the product to fail gracefully and still provide a happy journey.

In this scenario, the user could get a message explaining there has been a problem. They also get a number to call to handle the transaction offline and a coupon code to save some money on their purchase to make up for the inconvenience.

The code doubles as a way for the customer service representative to access whatever information was already saved in the system, saving the customer time. It’s not the happy path, but it’s a happy journey.

Eight tips for edge testing in your development

1.    Spend time brainstorming potential edge cases and issues that might arise.

2.    Edge test at each stage of development, not just at the end.

3.    Test edge cases for individual components alone and with other elements to find corner cases.

4.    Validate all inputs and outputs. Edge cases programming validates and handles unexpected inputs. Unexpected outputs result in communication and rerouting to the happy path.

5.    Use rigorous automated testing to check all inputs within and outside the bounds you expect. For example, check what happens when null or negative values or values outside of your minimum and maximum expected values are included.

6.    Don’t only rely on automated testing, have users test on various platforms and hardware in different time zones and languages.

7.    Create user personas for testing, from the advanced power user down to the complete amateur, and don’t forget the bad actor trying to break your system.

8.    Make sure all edge cases communicate clearly to the user what their options are next. Products should never be unresponsive.

Handling edge cases is a team effort

Handling edge cases well comes down to having well-defined roles. Here are some tips for success:

• Product Owner – creates the objectives which the happy path should lead to and considers and documents alternatives if the happy path becomes impassable, which will still result in a happy journey.
• Designers – create the happy path and consider how to help the user reach their desired objective if they leave the happy path.
• Product Manager – Validates that the happy path and alternatives the designers create match the objectives of the business. Product managers also evaluate the possible impact the alternatives can have on other areas like customer support, marketing and sales, and engineering. 
• QA Manager – Responsible for edge case testing. Makes sure edge cases are caught and dealt with according to the documented alternatives validated by the Product Manager.

Don’t fear the edge with Cheesecake Labs

At Cheesecake Labs, we hope for the best but plan for the worst. We avoid surprises by considering edge cases throughout development — staying on schedule and budget.

Our experienced designers, QA teams, and product managers work together throughout design and development to validate, test, and handle edge cases so that every user journey is a happy one.

Chat with us today to learn how we can help your development journey.