Mycelium

IV · Character

The System's Voice

What does it sound like when it talks?

Somewhere in nearly every product there's a button that says Submit.

I think it's the worst label in software, and not because it's ugly. It describes what the machine is about to do with a form: submit it, to a server, for processing. It describes nothing the person is doing. They're not submitting. They're creating an account, sending a message, publishing a template, saving their changes. The label is the one place where the system could say here's what will happen when you press me, and instead it says I will perform the technical operation.

That one word is the clearest case of something that runs through every screen: the system has a voice, whether anyone decided what it should sound like or not, and the voice is where character actually lives for most people. Not in the mascot. In the words.


What does it sound like when it talks?

Read a product's copy out loud, all of it: the labels, the empty states, the confirmations, the errors, the fine print. You'll hear a person. Sometimes it's a confident host. Sometimes a nervous clerk. Often it's five different people, because five different people wrote it on five different days and nobody was listening for a voice.

The earlier chapters argued that character is consistency aimed at who rather than what. The voice is where that consistency is most audible, and most often broken. A product that's warm and plain on its landing page and turns into a legal department in its error states hasn't modulated; it's changed identity, and the person feels the stranger arrive.


The error is the system's apology

Nowhere does voice matter more than when something goes wrong, because that's the moment the person is least sure of you.

Invalid input. This field is required. Something went wrong. Those aren't messages to a person. They're system states, reported as if the reader were a developer tailing a log. They name the validation failure, not the person's task. And something went wrong is the system mumbling at its shoes: it admits a failure and declines to say which.

A good error does what a good apology does. It says what happened, it takes the responsibility that's its to take, and it says what happens next. Enter an email in the form name@example.com beats please enter a valid email, which beats invalid email, and the difference between them is exactly the difference between a person who helps and a person who points. The test I use for any error is simple: can the reader, having read it, immediately know what to type? If they have to interpret what "invalid" means in this context, the message has failed at its only job.

Where the error appears is voice too. Next to the field that caused it, in the same column, where the problem is. An error at the top of the form, or in a passing toast, is spatially lying about where the trouble is and leaving the person to map the sentence back to the box.


Emotion isn't a sticky note

There's a way of "designing for emotion" that I think misses the point entirely: writing user feels stressed in the margin of a flow and considering the job done. Emotion isn't a keyword you annotate a step with. It's the lens you look through at every decision.

What put the person on this screen? What are they expecting to find, where, in what form? What do they expect to do next? What are they feeling before they even opened the app? Those questions aren't an empathy step added to the process. They're the process, and the voice comes out of the answers.

Which also makes emotions requirements, not flavor. The person feels confident is a requirement. The person doesn't feel anxious about making a mistake is a requirement. The person feels closure when the task is done is a requirement. If a feature leaves the person anxious or confused, I'd call it broken, even with every test green.


One self, at different volumes

The earlier chapter in this part made the argument about fit: the banking app that jokes at the overdraft, the owl that goes quiet for the serious moment, intensity modulated and identity kept. The voice is where that discipline is most tested, because words are the fastest thing to change and the first thing a new writer changes. Before a sentence goes on a screen, the question isn't is this on-brand. It's what is this person feeling right now, and does this sound like us speaking to that? Sometimes the most respectful voice is the one that gets out of the way.


Where this bends

Good voice is like good perfume: you notice it, you appreciate it, it doesn't fill the room. The failure on the other side is the product that won't stop performing. The copy straining to be clever, the empty state doing a bit, the error with a joke in it when the person has just lost ten minutes of work. That's personality performed instead of had, and it's exhausting the way the person who keeps telling you how quirky they are is exhausting.

So I'd rather a product be plain and sure than warm and trying. Plainness is a voice too, and it's a trustworthy one. The warmth can come later, in the corners, once the person has stopped bracing.


Questions to carry