
Overview
Challenge
Much of MBrain's microcopy had been added by developers as features were built, often under time pressure. This resulted in an inconsistent tone, technical language, and messages that didn't always provide users with enough information to understand an action or its consequences.
The challenge wasn't simply to make the language sound friendlier. The copy still needed to be technically accurate while making actions, system feedback, and consequences easier to understand.
Approach
I reviewed the existing microcopy using a small set of questions to evaluate clarity, context, risk, and consistency:
Project Examples
I focused on three recurring areas where clearer language could make interactions easier to understand:
The examples below show how I applied the same principles across different types of interaction.
Error Messages

Original MBrain error message, recreated for presentation.
Explain the problem clearly
An error message should tell users what went wrong in terms they can understand, rather than exposing technical system details.
Where possible, it should also give enough context to help them resolve the problem.
Before

After

In this representative example, I replaced a generic configuration error with the specific problem, the affected machine, and guidance on what to do next.
Balance Clarity With Security
Before

After

Being specific is usually helpful, but login errors need more care. Saying whether the email or password is wrong could reveal whether an account exists for the email entered.
Instead, I kept the message intentionally general, without revealing which credential was incorrect. I also included a clear next step so users know what to do.
Confirmation and Destructive Actions
In an MES, actions can affect complex workflows, so users need to understand what they're confirming before they commit.
Match The Language To The Action
Clear labels and confirmation messages help users understand what will happen before they commit.

I changed “Delete” to “Remove” because the step wasn’t being permanently deleted from the system; it was being removed from the process.
I also replaced the generic “OK” with “Remove Step,” so users could see exactly what they were confirming.
Set Clear Expectations
Before users confirm an important action, they should understand what will happen next.

The updated dialog swaps technical and generic terms for labels that describe the actions directly.
“Execute” becomes “Start,” “Close” becomes “Cancel,” and the generic “OK” is replaced with “Start Process.”
The message also explains that the process will use the current settings, so users know what they’re confirming before they commit.
Action Labels and Terminology
When working on label microcopy, I kept these principles in mind:
Use Meaningful Labels
I replaced generic or technical wording with labels that described the action more directly.
Rely on surrounding context
I used the surrounding interface to provide context rather than repeating information in the label.
Keep Labels Simple
I trimmed out any words that didn’t add clarity, keeping each label as straightforward as possible.
Examples in Practice
On the Control Plan Containers page, the button label used to read “Add New Control Plan Container,” which was already clear from the surrounding context.
I changed it to “New Container.” The action stays clear without repeating what people already know.
Before
After
On the SPC page, “Add new” was too vague. Since the action created a subscription, I changed it to “New Subscription,” making it immediately clearer what the button would do.
The goal wasn’t always to make labels shorter, but to give people the right amount of information for the context.
Outcome
The microcopy became clearer, more consistent, and better aligned with the actions people were taking in the interface.
Across error messages, confirmation dialogs, and action labels, I replaced vague or technical language with copy that gave people clearer information about what was happening, what they could do, and what to expect next.
Reflections
Working on a complex enterprise system was a good reminder that effective UX writing is shaped by context. Sometimes the best choice is to cut a few words. Other times, it means adding enough detail to help people understand what’s happening or what to do next.
Good microcopy isn’t simply about saying less. It’s about giving people the information they need, when they need it.
UI Design • Enterprise UX • Enterprise UX • Manufacturing Execution System
Design Systems • Enterprise UX • Manufacturing Execution System
UX Design • UI Design • Public Sector • Försäkringskassan









