A brand is not a logo or a colour palette. It is the cumulative impression a product leaves on the people who use it, and most of that impression is built from sentences too small to feature in the marketing material. The microcopy is the brand. Most products do not realise it, and most users could not articulate it, but they feel it.
I try to take this seriously. Every button label, every empty state, every confirmation prompt, every loading message, every tooltip is a sentence the brand is saying. Strung together across a session, these sentences add up to a voice. The voice is the brand.
The default voice problem
When you use a default component library, you inherit its microcopy. "Cancel." "Confirm." "Are you sure?" "An error occurred." These are technically functional. They are also voiceless. Every product that uses them sounds the same, because they all inherited the same voice from the same source.
I rewrote almost every default string in the product. "Cancel" became "Keep editing" in the contexts where that was the actual choice the user was making. "Are you sure?" became "Discard your changes?" because that was the actual question being asked. "An error occurred" became any number of specific, honest sentences depending on what had actually happened.
This is more work than accepting the defaults. It is much more work than writing the strings in the wireframe and never revisiting them. It is also where the brand actually lives, so I keep doing it.
Specific over generic
The single most useful rule I have for microcopy is to be specific. "Saving" is generic. "Saving your draft" is specific. "Deleted" is generic. "Removed from this campaign" is specific. The specific version is almost always shorter to read in the user's head, because they do not have to do the inference of what the generic verb refers to.
This is harder than it sounds. It requires that the writer of the string knows exactly what is being saved, deleted, or moved at this particular moment. It requires that the same string is not reused in three contexts where the specifics differ. It requires that the codebase actually supports per-context strings rather than a centralised glossary of generic verbs.
I pay this cost. There are hundreds of one-off strings across the product, each tuned to its context. Maintaining them is a discipline. The result is that the user is never reading a string that was written for some other situation and pressed into service here.
What I never write
I never write "click here." Click is an interface verb, and the user is doing the interface action regardless. Tell them what they will get, not what they have to do.
I never write "please." It is not a politeness, in this context. It is a hedge. "Please enter your email" is asking permission to ask for an email. Just ask.
I never write "oops" or any other affectation that pretends an error is a small embarrassment. An error is a moment when the user is uncertain whether their work is safe. They do not need cuteness. They need clarity.
I never write strings that praise the user for using basic features. "Great choice" when they pick a template. "Awesome" when they save. The user knows they are making basic choices. Praising them for it is condescending.
The cumulative effect
A user who reads two thousand strings in this product over the course of a month is forming a model of who I am based on those strings. If the strings are specific, honest, and consistent, they form a model of a thoughtful product made by a thoughtful person. If the strings are generic, hedged, and inherited, they form a model of a product nobody really wrote.
There is no shortcut to this. You cannot write a brand guidelines document that produces good microcopy. You can only write the strings, one at a time, in the contexts where they live, with the discipline of someone who knows that this sentence is the brand for this user in this moment.
The work shows up nowhere on the marketing site. It shows up everywhere in the product. People feel it before they can name it, and that is the point.