Here are some real-life examples of features that save users from themselves. They prevent chaos and keep your product frustration-free.

Software is a funny industry. You can start your business from your couch, with a laptop, an internet connection, and your coding skills only.

The motto of any startup is “build fast and break things”, which enshrines the picture of the indie developer on the couch. Ship feature after feature, with each feature opening the door to yet more customers.

It’s not that simple. I’m the Founder & CEO of Yonder, a B2B SaaS company. Yes, we also started out of nothing. Yes, we also shipped feature after feature in the early days. But after a while, a strange old friend visited us: Reality.

Besides evergreen improvements such as performance, usability, and bugfixing, we had to build functionality to guardrail our users. No offence to our users, but they do all sorts of things with your software product that you would never have imagined when you first sat down on your couch and started coding.

What Does Our Product Do?

To understand the guardrail examples I will explain in this article, you need to know what our product does.

Yonder is a fully integrated document management solution for XML-based documents in highly regulated industries. Think aircraft manuals for airlines, operating procedures for air navigation service providers, or aerodrome manuals that are linked to a set of underlying regulations.

Our solution consists of an authoring solution in a web client and a viewer solution for the iPad. In this way, technical authors can edit and customize their documents before they are distributed to the end users, who are typically pilots, flight attendants, or control center operators.

Now let’s dive into some examples from our experience.

Guardrail 1: Connectivity in the Tunnel

There is a good reason our authoring solution is available only in the web client. Authoring complex technical documents is not something you should do on the go. Additionally, the authoring framework offers numerous options for typical Airbus or Boeing manuals, requiring a large screen to work efficiently.

Nevertheless, a few years ago, an author user was on a long-haul bus in Southeast Europe and decided he wanted to edit that Airbus manual while on the go. He opened the browser on his iPad and logged into the authoring web client. Remember, that’s the component that’s built for large screens in an office.

Don’t ask me about the details of what exactly he did on that bus, but we know for sure that at some point, he decided he’d finished all the modifications to his Airbus manual, and he’d pressed the “publish” button.

Whilst on a bus, with a hotspot internet connection.

And just at that moment, the bus drove into a tunnel.

Connectivity dropped.

The publication job was lost somewhere in space. Getting it back was difficult, laborious, and didn’t exactly benefit customer satisfaction.

In the aftermath of this episode, we built a feature to check connectivity before saving the edits you made to your documents. This feature would have saved our poor author on that bus in the tunnel.

Guardrail 2: The iPad with Limited Storage

Change of scene. We’re in the headquarters of one of the largest airlines on the planet. The authors have been busy creating and customizing hundreds of documents, and now they are ready for users to view on their iPads.

But on some iPads, the synchronization didn’t complete.

No, it wasn’t a bug. It was much simpler. The airline I am talking about doesn’t manage their iPads, meaning that users work with their company iPads like they do with their private iPads: Downloading apps and games, storing photos and videos, etc.

And for some users, their iPads were so full of private stuff that there wasn’t any space left for (safety-critical) data such as Airbus manuals.

What did we do? We implemented a feature that checks for available storage before synchronization is started. If there is not enough storage available, a big fat red banner saying “storage almost full” appears. And you can’t click away. You can only make it disappear by freeing up storage in other applications on your device.

Patronizing? Maybe. But this guardrail feature saves us from mandating Mobile Device Management (MDM) solutions with our enterprise customers. Because we know that some of them don’t manage their iPads.

Conclusion

Guardrail features are not flashy. But they are needed for a stable product. As a product owner, you have to give guardrail features the priority they deserve, even if your developers would prefer to work on a flashy new feature.

The secret to developing guardrail features? You can’t plan them in advance. Because what your users will do with your product was beyond your imagination when you sat on that couch and started to hack away at the first features.

But when there is a case like the ones described above, it’s in your best interest to change the priorities and get the guardrails implemented to avoid repeated cases of user frustration.