A blog post by ADAM ROUX (a human)
Everything you use has a voice
All our lives, we’ve received ideas about how things should sound. It’s how we know to use the language most appropriate to a situation, we’re polite with clients, friendly with friends, sort of apologetic when we get pulled over for doing 80 in a 45. We’re socialized to know how these interactions should go.
We’re also getting more and more socialized to how apps and digital tools should sound, too: those we use for work (Microsoft Office) are going to be a little more pragmatic-sounding than, say, Instagram. This is called the app’s voice, and it’s a key part of how the app connects with users.
Sometimes, though, there’s an expectation that tools for working with lots of data or in a technical specialization should reflect the rigor of their material. And how does “rigorous” sound? Stern. Clinical. Official. This is also a voice; it is also a personality, albeit a cold one. We think these tools should sound like soulless machines borne of hard, impersonal data, which, yes, technically, is exactly what they are–unless sounding human is a “feature”, like with LLMs.
But! Given that we, human people, are meant to interact with them, and that we come to them, sometimes, with varying levels of knowledge in that specialized field, is that cold formality the best way for these tools to communicate with us?
Sounding human saves users time & effort
It takes more effort to understand stiff and formal language, and less effort to understand casual language. When creating technical tools, we can mitigate the complexity of material by sounding as much like normal humans as possible, saving end users effort and time.
If users are in the middle of a difficult task, anyway, it’s our job to limit the effort they put into simply understanding what the tool is asking them to do.
You don’t have to flesh out a full brand voice for every app, but there’s a couple of simple things you can do to ensure that you sound human–and help your users get work done faster–in any context.
Use contractions
Contractions like “don’t” or “can’t” not only take up fewer pixels, they’re more casual than the very formal “do not” or “can not.”
Address the user
Imagine how you’d address someone trying to use the app. What instructors would you give them, if you were standing next to them as they used the app? The way you’d say it in that context is probably pretty close to how you should phrase it on the screen.
Say it out loud
Want to check if what you wrote sounds human enough? Read it out loud. Does it feel strange? Unnatural? Where? How? Figure out where you get tripped up and try to smooth it out.
Call things what they are
When we think up labels, actions, and instructions try to be as straightforward as possible. What is the thing you’re trying to get people to do? If you’re dealing with a technical audience, using language they recognize is a sign of respect, but relying on too much jargon–or, even worse, inventing your own–means the user has to mentally translate what you’re asking them to do. It might take a minute, it might take milliseconds, but however long it takes, you can bet the user winds up annoyed.
Limit capitalization
When we read anything longer than a couple of sentences, studies have shown it messes with our comprehension when we encounter too many capitalized words. Long titles where the first letter is capitalized can slow us down. Sometimes, we feel a need to capitalize things to show that they’re important, or that they’re a key concept, but what we’re really doing is adding slight comprehension hurdles for anyone trying to get the information they need.
Human rules are squishy
The caveat: these are not rules. They’re practices that will usually help your users understand what they need to do. Forget all the grammarians and language pedants you’ve come across. The key is to use language in a way that feels natural to you–if you do, you’re making lives easier for everyone who uses your tool.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
