Question—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 hand raises, 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 bigger and more capable, the harder they are to learn, and the more necessary it becomes to read a manual. 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.
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!
When it comes to usage and adoption, incident management software is something of a special case:
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.
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 👇
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:
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!
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.
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:
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.
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.
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.
Enter your details to receive our monthly newsletter, filled with incident related insights to help you in your day-to-day!