You wake up at 4 am and decide to look at your email, and even though you know you shouldn’t, for so many reasons, it’s almost a reflex. You see a few messages—not many, maybe three or four, which is an okay number, not enough to make you think that some catastrophe has hit your server or one of your clients’. You could decide not to read any of those and go back to sleep, but you have no power against temptation at 4 am. Not to mention that at least one of the subjects starts with “Fw: R: Re: R: Re:” and you already know someone must be in trouble.
If you really can’t resist the urge to read the actual content of the email, do so with the full awareness of the fact that your users are fainting goats. Fainting goats—in case you haven’t stumbled upon them, metaphorically or otherwise—are goats that suffer from myotonia, a genetic disorder that makes their muscles go stiff when they’re startled. They don’t actually faint, but either topple over or start hopping around on all four legs for a few seconds. When the scare passes, they can get up and go on their merry way. Distressing as it may sound, it can also be quite entertaining to watch.
Receiving alarmed emails from users who suddenly believe they can no longer get anything done, or that the system you built has decided it doesn’t like them at all, can easily cause you to do an epic, Liz Lemon-style eye roll, and immediately jump on a response in which you explain, not without some snark, how they did something wrong, and how their expectations were simply misdirected, and how they should think logically before they send support requests drenched in despair. You, from the height of your knowledge of the system you built, can clearly imagine your users’ entire thought process, and can almost see them bang their heads against that specific feature that for you is so blatantly obvious.
But logic doesn’t work in the face of fear. Machines, even something as well-designed and most certainly pretty as that website you made, can be intimidating. Let’s face it: you, as a digital designer, should always assume that anything you make scares the crap out of most people who interact with it. A simple hiccup that may or may not depend on the code you wrote can make your users’ brains go into defense mode, their muscles spasm, their fingers automatically type that email in which they blame themselves for all that’s ugly in the world. As with fainting goats, that moment will pass. You can rest assured that in a few seconds everything will be back to normal. In most cases, they won’t sit there anxiously waiting for your response.
Make sure you resist the temptation of taking care of the matter right away. It’s maybe 4:15 am now, and you should go back to sleep, and leave your response for the morning. Your main goal in writing it should be to prevent or minimize the next scare. Ask for more information if needed—you know that a fainting goat in distress forgets to take screenshots and transcribe error messages. Explain what went wrong, reassuring them that it wasn’t their fault. Even if you believe it was their fault, consider that they didn’t build the system, and they don’t know it as well as you do. What may seem logical and sensible to you may appear arbitrary to someone else. Also, the web is a bitch, and can’t be trusted to behave consistently, which is precisely why we love it. (Now, where did I leave my Stockholm syndrome pills?)
No amount of user testing will prevent the fainting-goat effect, so there is no place for frustration at users’ requests for help. In-person training is useful and necessary, but most of that information will be forgotten in a heartbeat, and you can’t possibly do that for every single one of your potential users. What alleviates future scares is documentation. Writing documentation aimed at people (on top of code documentation, which you obviously always write) should be part of any web project, no matter how small. If after a day of coding you’re too exhausted to spend another hour describing everything you just did, make it the first thing you do tomorrow.
Documentation should be more than just a list of features and commands. It should be, above all, a narrative device that puts people back at the center of the action, helps them make sense of their work, and shows them that what you built for them is not a disconnected cluster of dumb tasks, but a structured process. Turning machine logic into narrative logic forces you to lower the camera angle and see your work from your users’ perspectives. It will also help you discover possible plot holes in what you’ve built. If the narrative works well, you’ll have spared your users a scare or two, and saved yourself some extra sleep.