With software in consumer electronics it can be reasonable assumed that stuff will crash.

In theory, with enough care, testing and enough time, this shouldn’t happen, but the reality is that it does.

Now, we could just ignore this fact and say “our software doesn’t crash!”. Admitting that it does would be saying that you’re not offering a premium product. You could say “just don’t buy lesser products” while the reality is that the lesser products are less likely to crash because they have less features that were crammed into it in the last minute.

It’s a given that stuff breaks. I’ve had the most “premium” products with embedded software that just freeze or reboot on me. When the companies notice, they’ll push software updates, but that doesn’t fix the fundamental issue.

The problem isn’t a bug or multiple bugs that freeze your device. The problem is the approach.

My Bose QuietComfort 35 Headphones do freeze occasionally and just continue playing the same half-second sound in a loop over and over again.

High-end MacBook Pro and iMac Pro need to be reset every now and then because macOS freezes up.

What these have in common is that they have an obvious way to easily reset them. The headphones have a physical on/off switch that, when turned off and on, will reset and re-connect the headphones to continue playing whatever you were listening to before. Macs have a physical button (that needs to be held for a few seconds to shut down) and persist what apps have been open so, even if the system doesn’t shut down properly, attempts to re-open all windows (Applications need to support the last state, though).

While I would prefer for those devices not to freeze in the first place, my situation would be way worse if…

1. I didn’t know how to reset them
2. They wouldn’t come up with the last state.

As experience has shown, it can never be assumed that things don’t crash in the first place, unless you’re torturing your developers and finance department with a ISO 26262 process or similar.

Assuming that it’s a given that things will freeze, the user experience problem isn’t that things freeze (although we can reduce the likelihood to a certain extent), but that some products aren’t designed with the reset procedure in mind.

Let users easily reset stuff!

I used to drive a 2009 Mercedes-Benz CL where the satnav sometimes froze. The first time this happened, I didn’t know how to reset it. In order to reset the system, one needs to hold down the eject key of the DVD changer!

The design problem isn’t that the system freezes.

The design problem is that:

• The reset isn’t obvious. Having to read up on how to hold the least obvious button that’s hidden behind a panel while driving down the interstate isn’t a great user experience!
• As a bonus, when you do that and your changer is loaded, it will spit out a disc. I ended up putting a dummy CD into the drive that I didn’t care about being scratched so I could reset the system and easily discard the CD it produces into the passenger footwell if necessary.

Another example is my iPhone XS. Last weekend, I was walking on the beach, trying to take a photo while the device froze. The screen stayed on, showing the last picture of the camera. The only devices I had on me were my iPhone and Apple Watch (GPS), so since the iPhone froze, there was no way for me to look it up. Luckily, this happened to me before and I remembered how to reset it.
While older iPhones with home buttons could be reset by simply holding the home button and off button for a few seconds, iPhones without home buttons require a procedure that involves pressing the volume up button, volume down button and then the side button. This is anti-obvious. When someone has an emergency while this happens to them for the first time, this is potentially dangerous and makes iPhone effectively unreliable as a phone! To make it safer, Apple should either etch reset instructions ion the back of the device or simplify the reset procedure (how about holding side button and volume up?).

Again, what happens here is probably that someone at Apple will find the bug that freezes the device in some cases and they’ll fix it. UX designers might say “it’s a premium Apple device, so our goal is to not have users want to reset it in the first place, plus the developers said that they already fixed the bug”.

But that doesn’t solve the underlying design problem because there will always be new bugs! The only way to actually solve the problem is to admit that the device will freeze under normal use and give users an obvious and fast way to reset it.

Persist the last state!

When the navigation system in my 2018 Volkswagen Tiguan recently froze during route guidance, I instinctively held down the on/off button to reset the system and it indeed rebooted.

Good.

However, after rebooting, it wouldn’t resume the route guidance! To maker matters worse, it prevented me from entering a destination while driving and even forgot where I was going before it froze (the destination doesn’t show up in the list of recent destinations).

Bad.

The state of what the user is doing at the moment needs to be persisted at any time. Even if a navigation application uses a gigabyte of RAM, the actual information of what the user is doing (the position of where the map is scrolled, zoom level, current route guidance etc) Is only a few KB and can be easily persisted. When we restart the system, this information can be loaded again along with the rest of the application.

This goes for the state of the entire system.

Part of UX design is defining the possible states and relevant data throughout the system and to implement fail states to ensure:

1. There must be an obvious way to reset the system
2. User must lose as little data as possible when resetting the system