Embracing the active user paradox

When was the last time you purchased a new product and sat down to read the manual end-to-end before getting started? Ask this question to a room of 10 people and you’d likely get one or two raised hands, even though reading first could save you time and preempt many of the questions you’re likely to ask.

Herein lies the problem when it comes to creating a SaaS product. As products become more capable, the harder they are to learn, and the more necessary it becomes to read the docs. But because we want to start by doing, we end up failing to get the most out of product.

Here at incident.io, we devote huge amounts of effort to combat that need, by investing in user experience and ergonomics to deliver an beautifully intuitive product. And since it’s something we care passionately about, we thought we’d share a little more about it here.

What exactly is the active user paradox?

The active user paradox creates quite the conundrum for product teams. In short it outlines the bias that users have to start using products immediately, rather than taking the time to read about and understand them first.

This is where the “paradox” part of this comes creeping in.

Users would likely save time and get the task done more quickly by reviewing the help docs and getting everything fully set up first. Understanding how to use the product to its fullest potential should be a huge motivator here, but a “read first, do later” approach simply isn’t expectation that survives contact with reality!

Read a manual for incident management? Sorry, I don’t have time for that

When it comes to usage and adoption, incident management software is something of a special case:

• When you need it, time is a luxury you don’t have, so learning on the go simply isn’t an option
• Unless you’re particularly unfortunate, you’re unlikely to be using it on a daily basis (though we’d advocate for doing so!)

For this reason, it’s especially important that incidents can be declared, run, and closed with minimal cognitive overhead, and without the need to go hunting through the docs.

That’s why we move mountains behind the scenes to build a product that’s both intuitive and ergonomic, regardless of who’s using it and how often they get involved.

How we’ve built incident.io to embrace the active user paradox

We’ve chosen to embrace the active user paradox by accepting the fact that manuals just aren’t a consideration for most users. And here’s how 👇

We ship with sensible defaults

To start, we’ve fully embraced the idea of defaults. On the first go-around, you can absolutely run and end-to-end incident response process only using the out-of-the-box defaults. While you do have the ability to customize much of the incident.io product, when you’re first getting set up, we’ve created defaults that we think will work for most organizations. This includes things like:

• Roles: we assume that company’s will always have an incident lead
• Incident severities: we expect all organizations to have incident severity levels, and we give you a sane starting point
• Incident lifecycle: we think there’s a sensible set of stages for an incident to pass through, and we ship with our opinions

All of these are customizable, but don’t need to be customised or thought about. This allows us to be an ideal plug-and-play solution for time-strapped organizations who just need to confidently get off the ground. It is entirely possible to install incident.io and run your first real incident inside of 5 minutes – and some customers have!

We’re biased towards plain, simple language

One of the biggest issues we come across in our space is that language tends to be highly technical and jargon filled – often geared towards more technical users. While the reality is that most of the folks responding to incidents will have a technical background, we feel it’s quite unnecessary to have language to match.

When things are on fire and you need to make quick decisions, the last thing you want is a process that’s full of hard-to-understand terms and phrases.

Instead, we’ve defaulted to simple language that makes it very clear what’s necessary. Let’s take a look at our incident declaration form:

From the top down, we’ve included fields that are easy to understand and, where there might be any room for ambiguity, we’ve explained exactly what the field means. This makes it actively accessible to the whole organization regardless of technical ability.

And in cases where companies do want more pinpoint language, we allow for customization with your own language and terms. This way, the product feels like it’s a natural part of the day-to-day.

We present the right prompts at the right time

In the heat of an incident, it’s easy for even most experienced of users to forget a part of the process. For this reason, we think a great deal about the connectedness of steps, and presentation of information when it’s most contextually relevant.

Some examples include:

• When you declare an incident, we’ll prompt you to complete common actions immediately in the incident Slack channel. No need to go hunting for what to do, it’s just put right in front of you.
• If you post a link to a Jira ticket or Pagerduty incident, we’ll automatically link it to the incident. And when there are updates on those items, we’ll tell you rather than expecting you to go and look.
• When you close an incident, we’ll help you set up your post incident process, inviting the right people to meetings, ensuring follow-up actions are logged in the right place, and more.
• We allow you to customise and connect prompts that are useful to your business to automated actions, or assistive decision making (something we call Decision Flows).

In general, we put the right information, decisions, and context in front of the right users at exactly the right time, so you can focus your attention on responding.

We exist within Slack

Many organizations use Slack every single day for communication. And many users, even passing users, know how to use Slash command shortcuts to do things a lot faster. Since incident.io is integrated into Slack, a common interface that everyone is comfortable with, we’ve actively lowered the barrier to entry. As long as you know one command, /inc, you can run an incident response process. Better yet, you don’t even need to leave Slack.

And for folks who do want a walkthrough of the product to get going, we have tutorials to help you understand how to own the incident declaration and response process like a pro. All you have to do is type /inc tutorial to get started. Fun fact: one of our favorite tutorial incident revolves around saving a cat stuck in a tree. If that doesn’t motivate you to take the tutorial, we don’t know what will.

So, does leaning into the active user paradox work?

Leaning into the active user paradox is working well for us. We’ve had folks who used us by mistake (someone installed, and others found organically) and they ran an incident end-to-end as designed. No training, no manuals, just simplicity and a great user experience leading them along the right path. We also get countless feedback about the intuitive nature of our product.

Between our sensible defaults, simple language, prompts and the fact that we’re integrated into Slack, we feel like we’ve created the most simple and straightforward solution possible for incident management.