When writing labels for productivity software, labels should be clear, concise, and neutral. The goal is to help the user complete a task, not influence them toward your own goals. When writing for such experiences, I think about the process of following a recipe.
In both software and a recipe, someone is focused on achieving a specific goal that has multiple steps. Some folks will have memorized (or will ignore) all the steps and can find their way around by feel alone. Others will read every instruction twice.
Language in a user experience guides users through the steps they need to take to complete a task. There are two broad categories of language in a UX: instruction and information. Instructions can be complex and narrative. They bring the user from one mental state to another.
Information is perhaps less complex, but still challenging to write. Especially labels. Labels are signposts that inform users what they are looking at and provide clues as to how it will work.
Just like in a recipe, labels should be clear, concise, and neutral. Neutral means the labels don’t make assumptions about what the user values or what they are trying to do. Users could be using your software for all sorts of unexpected uses. Well-designed software enables all kinds of unforeseen use cases. (This is kind of what folks mean by “timeless” design.)
Users don’t need branded terms in labels. They are distracting and they can imply a specificity that isn’t necessarily required. Consider a recipe that looks like this:
It’s too specific. It also feels a little smarmy, but we see this in software products all the time.
Users also don’t need buzzwordy value-props. These are appropriate in marketing copy to differentiate features. Within the product, however they are distracting and often disconnected from the user’s immediate goals:
Users don’t need all technical details or capabilities either. Remember that when the user is engaged in the task, they are not ready to learn complex concepts. Technical details are appropriate for instruction before a user gets started or in documentation when a user is stuck.
Here’s what a too technical recipe looks like:
Of course, if detailed specifications are critical for success, include them early in the experience (in recipes, the ingredient deck is appropriate), but make sure to use simpler versions through the experience.
The best labels are clear, concise, and neutral. A user baking a cake needs to know the basics.
The shorter the better since these labels will be used in the method too. In the method, you can remove modifiers (like 2% or all purpose) to keep it short and scannable.
“Separate eggs, then add to the flour. Add milk.”
Compare this to:
“Separate Grade AA, CA SEFS compliant eggs, then add to the dry ingredients. Grade AA, CA SEFS compliant eggs should be added one at a time.”
But business software does this all the time:
To enable Omnibuzzword Filtering go to Omnibuzzword Filtering Power Settings > Omnibuzzword Filtering and choose Activate Omnibuzzword Filtering.
They’d probably jam a damn trademark sign in there if you let them. Gross.
Keep labels simple. When in doubt, think cake.