How the f do you write a good alert?

A philosophical pursuit of truth and virtue

Writing copy for in-app alerts is something I usually struggle with. I don’t know what the best approach is, so I kind of wing it and hope for the best. So I’m going to use this post as an exercise in figuring things out.

Okay, let’s start by posing a deep and philosophical question:

Why do alerts exist?

A little existential humour to get things started.

Well, Saaqshi, I guess alerts exist to physically startle and trick users into reading something longer than a few words. But this trickery is not ill-intended because it actually functions to help them make a decision about something.

For example, this might be what went down if apps were sentient beings:

Hey, you’re about to delete everything on your phone. All those pictures of your food, all your selfies, and all the shots of your dog in Halloween costumes will be gone. Are you ready to live with that for the rest of your life? Yes or nah?

I think that makes sense. I could go do some more research on the matter, maybe look into the history of alerts, but I’m going to just pretend like I’m in the ballpark with that explanation.

Ok, moving on the the next question.

What are the elements of an alert?

So you have your header. Your main copy. And your action(s). Bing, bang, boom.

Great. So now the toughest question:

What makes a good alert?

If alerts exist to draw user attention long enough so that they (the user not the alert — I know I mucked everything up by proposing apps could be people) can make a decision about something… then I guess a good alert helps facilitate the decision-making process by providing information.

Good alerts should help you understand where you are in the app, and what’s at stake when you make a decision.

So if we go back to the aforementioned example:

Me: How did I get here?
App: You just hit the “Self Destruct” Button on your phone.
Me: What happens now?
App: If you continue down this path, your phone will self destruct.
Me: Ok.
App: I don’t think you understand. You’ll lose everything. Your contacts, your apps, photos of Dexter dressed as a hotdog…
Me: Oh no!
App: Ya. It’s serious. So what do you wanna do? Do you wanna self-destruct this biatch, or do you want to forget about it?
Me: Abort, abort!
App: Ya. That’s what I thought.

What about in case of errors? Alerts work there too right? I guess the only difference in this situation is that you aren’t taking action within the alert, but being directed to some action elsewhere.

For example:

Me: How did I get here?
App: You tried to view your pictures, but you already deleted all your pictures during the self destruction. So this is an error message.
Me: Oh no, Dexter! What do I do now?!
App: Better start taking more pictures from your camera.
Me:[between sobs] OK.

Or as a more useful example:

Cool. I feel better about this. 1) orient the user 2) tell the user what’s at stake 3) guide the user to their next action.

So how do we put this together in fancy package of header, main copy, and action button(s)?

Header

This is the first thing the user sees, assuming users read top to bottom. So the header should be as clear as possible about what the alert is about.

For example:

Self Destruct Device?

Main copy

This is where you have the most real estate (although not a whole lot), so this is where you can describe the consequence of user action.

For example:

If you self destruct this device you will lose all data such as contacts, apps, and photos on this device.

Action

Here it should be super clear what the action will do.

For example:

Self Destruct

Go Back

So all together, it would look something like this:

A note on ambiguous actions

Be careful not to use “Cancel” or “Continue” ambiguously. If I asked the user if they were sure they wanted to cancel their draft of a message, it would be hard to understand what a “Cancel” button does. Does it cancel my intention to cancel? Or does it cancel my progress in my draft so that I lose everything?

Ahhh what do I do?!

Questions about redundancy and repetition

Sometimes I find myself in situations where I have to repeat the same phrase is the header, body, and buttons of a alert. And I’m not sure how I feel about the repetition and redundancy.

I don’t love this output from a literary or design perspective:

But at the same time, it’s functional and basically fool proof.

If we didn’t go down the redundancy route, we could try an alternative that kind of breaks the rule I set out for headers (make them clear and unambiguous), but this feels fresher to me.

I dunno which I like better. Anyone else out there have thoughts on the matter? Does anything I said make sense? Am I totally overthinking this? What is life, really?