How to migrate your SaaS to cloud with zero upfront costs?
Date: 29 September 2020
Time: 09:30 - 10:30 GMT
This article describes, from a bottom-up perspective, some of the challenges in UX Writing.
The main purpose of UX writing is to ensure that the people who use any software have a positive experience. To create that experience, you use words in instructions, descriptions, error messages, warnings, notifications, titles, sub-titles, buttons, and labels. You also write setup information and how-to content. When writing UX texts, the key thing is to think of those who use software in terms of (fallible) “people”, rather than (robotic) “users”.
Language is the tool we use to write words, but natural language can also be a big challenge on many levels.
At Nordcloud, we have many colleagues for whom English is not their native language. Nevertheless, we all work, everyday, in English, and everyone’s English is at an extremely high professional level. This is not the challenge. In fact, such linguistic diversity is a great benefit. The challenge lies in the fact that, most unusually for a natural language, there is no single, authoritative source which regulates standard English. Unlike the French, who have their General Delegation for the French language and the languages of France, and the Germans, who have their Council for German Orthography, there is no definitive statement of what is, or is not, English.
Every natural language has many different ways to construct and convey ideas, but not all of those ways are equal when it comes to providing the desired experience. Simple grammatical structures tend to work best for most purposes. And those simple structures must be applied in a way which is literal, logical, and precise. The challenge here is how to maximize usability, but without the result being an impersonal, robotic tone. In reality, for a given usecase, you need to choose the sentence structure, and vocabulary, that gives the right balance between usability (clarity, brevity), and personality (conversational style).
To achieve strict usability, the words inside an experience must not get in the way. No UX text is there to be savoured, or read for pure pleasure. And the physical real estate of a screen is a very precious asset. As such, this is another fundamental reason to keep UI texts as short as possible. On the other hand, at times, using too few words, where more words are expected, can block the reader. Either way, the challenge is the total time that it takes to fashion a UX text which is as simple as possible, but not more simple. Or, as Pascal put it, “Not that the story need be long, but it will take a long while to make it short”.
Although punctuation and capitalization are, by definition, small physical elements, they are an important part of UX writing, because the design of a good visual and typographic experience affects the reading experience, and therefore, affects the full and swift understanding of what is written. You’d think that the challenge is to pick one of the many available style guides, and stick with it. In fact, the challenge is that these style guides are huge, and unwieldy. Not only that, but the real challenge is to develop your own style. This has the advantage of making the style easy to remember, and easy to use, for the writers. At the same, having your own style creates a reading experience that is consistent in two ways: the same language items are dealt with in the same way; and language items have a “voice” which is consistent with the product’s brand.
In FinOps, there is a great deal of specific terminology. Obviously, you make it much easier for people to use the product, if you use the correct terminology consistently. Getting terminology right is a particularly acute challenge in the case of a multicloud product. For, even when different Cloud Service Providers provide more or less the same services, how providers name those services can be entirely different. What’s even more tricky is that there is often overlap in how the same words are applied to slightly different concepts. For example, when we consider the concept of instance-lifecycle, the language used to describe the one set of possible states for EC2 instances seems relatively simple compared to the three different sets of possible states in Azure. And, sometimes, a particular feature in a multicloud product should not have a different UX text for each Cloud Service Provider, but needs instead a set of generic labels that covers all possible usecases in the context of that feature.
If you’re planning on localizing your product, you must remember that you’re not just writing for other English speakers. You’re also designing the writing in a way that makes it easier in the future for the translators to convey the same message, but in accordance with how their native language works.
Stephen Eastham, Technical Copywriter, Platform & Tools
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.