A story of a message in 5 images

“Hey, Wojtek! In the error message, should we write that there was an authorization or authentication error?” Karolina, a product manager, suddenly asked me one day. She then added, “The developer says these are two different things, but I still hear everyone using them interchangeably. Can you help us decide what to put in the error message?” She was hoping for a quick fix.

Freeze-frame.

What should Wojtek do? Should he open the dictionary, look up the definitions, and categorically conclude which word is correct? Or should he simply agree with the developer, since this is a technical dispute anyway? Knowing Wojtek, he would not be himself if he chose one of the above options, so he looks at the screen, and there (Fig. 1)…

Figure 1. The designer's mind raises several questions beyond “authentication” vs “authorization” on this page.        

…he finds a heap of troubling questions.

What caused this page to appear?

What type of request is it?

Who will handle it, and how?

Additionally, there is an issue with the style. “Authentication error” is repeated twice, and the writing is nothing but technical jargon. The curse of knowledge is evident, resulting from the assumption that technical explanations will be understood equally by all product users.

This needs to be cleaned up!

Wojtek starts by investigating where the message comes from. It seemed unusual to appear in the middle of an interaction. A quick investigation on Slack reveals that the user was inactive for too long and was logged out. Ha! So it’s the “session expired” classic. By the way – kudos to the team for not using this message.

Let's get going. Wojtek is about to create a human-readable messaging. He uses the browser developer tools and checks whether the text can be changed without affecting the page layout. He starts with a simple edit to introduce direct language to clarify the message (Fig. 2). Although this is a step forward, it still is not perfect.

Figure 2. On the first attempt, there was some improvement, but not great. The error message is still somewhat confusing. Why does it say "login error" when there was no attempt to log in? The user can only assume that the system had logged them out, hence the need to log in again. Where should you enter the correct password? Why only the password? Wojtek, keep trying!        

An extra challenge springs up: how to say that the data is safe, but without saying that the data is safe? “Your data is safe” is annoying. This phrase often triggers thoughts of potential data loss scenarios, and it has become overly overused. Wojtek writes a new message from scratch (Fig. 3). It now transparently informs what happened and what you need to do to return to the state before logout (“continue your work”).

Figure 3. Another version. The text appears informative and straightforward. It is requesting to log in and clarifies that the system’s action is deliberate and is related to security. The phrase: "continue your work" hints that the data is safe without saying so.        

The product manager is satisfied. The modifications are logical and there is no need to modify or add code. The new text fits perfectly and sounds sensible. It's just that we're working on a positive experience… Does going to the login page resolve the issue? Not really. A person is interrupted and their task remains incomplete.

The group decides to keep on fixing.

The team sets a goal to streamline the interaction so that the user does not have to wade through the entire system to get to the login page. Perhaps they should add a link to the login page? Or maybe a button would be nicer as it is easier to spot? (Fig. 4). Unfortunately, this would require additional conditions in the code and new scenarios to test. The system needs to know where the user logged out to return them there after the login form is submitted. This costs too much.

Figure 4. A slight change in the text indicating that nothing has gone wrong, and an additional login button. It's not great yet and, as it turns out, complicated to implement.        

Could it be any simpler?

Well, sure! The best thing is to allow you to log in immediately, almost without thinking, and get on with your work. So the team adds the login form to the error page.

The component already exists, and the code's modular structure allows for seamless embedding into the error page. Since the error page duplicates the code from the normal login page, you can even reset the password, and the error handling works in full. Additionally, Wojtek does not need to further modify the message (Fig. 5). The content above the login form makes it clear what has happened and what to do next. The calm and matter-of-fact tone does not raise suspicion that something serious has occurred. Users do not need to navigate anywhere. They need to fill in login details and that's it.

Figure 5. The final version has improved text and flow. The second line is structured to emphasize the most important information. "You can continue..." comes at the beginning because it implicitly says "your work is waiting behind the login screen." Everything else is less critical. The header highlights the need to log in and the login and password form cannot be ignored.        

The job is finished. Yay!

Sigh, a meaningful message requires effort… It started with a dilemma on terminology and ended with a completely rewritten screen content and a new page layout.

That's more or less what content design and UX writing is all about.

This is an opening excerpt from my book UX writing. Moc j?zyka w produktach cyfrowych (Eng. UX writing. The power of language in digital products).

• The book is published in Polish.
• You can read this fragment in Polish for free on the publisher's page.
• The book is available in print, ebook format, and as an audiobook.

The images in this fragment were prepared using Fisamiq - Low-fidelity UI Kit from Figma Community resources.