Building better SaaS products with UX Writing (Part 3)

More challenges in UX Writing

This article describes, from a top-down perspective, some of the challenges in UX Writing.

Making choices

At a low level of abstraction, UX writing is the challenge of making a zillion choices about language structure, terminology, voice, brevity, punctuation, capitalization, etc. The voice of an experience is made up of those many choices in the text. That filtering process begins with the ideas we choose to include or exclude, even if those words don’t seem, on the face of it, to make a difference to the action to be taken. It continues with the words we choose, how many we use, and how we organize them. The smallest change (one character) can make all the difference. I remember making a request to a former manager, to change the time of a meeting. She replied that, “I just resent the message”. And I couldn’t understand why she might be offended by my request to change the time. Then I realised that the message that she intended to convey was: “I just re-sent the message”.

When an organization prefers everyone to work in a way which is responsible and independent, it might seem logical that all the choices related to UX texts should be the sole responsibility of the UX writer. But, UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as it’s best for organizations to resist the temptation to hand that sole responsibility to the UX writer. The UX writer’s main goal is to develop multiple, good options for a given UI text. Sometimes, there may be only one logical choice; at other times, it may be necessary to choose between a number of good candidates. In the worst case, it’s necessary to choose between several candidates, where the structure/terminology differs significantly between those candidates. The experience that UX texts create will reflect the people who choose the UX texts themselves. So, ideally, the minimum team to take part in creating good UX texts include representatives from product, design, sales, marketing, research, development, leadership, and support. In this scheme, the UX writer is responsible for shepherding the team through the process of defining texts, preferably ending in a final decision by consensus.

Fixing the words

If I had a penny for every time that someone said, “We need to fix the words”, I’d be rich indeed. But fixing the words is like fixing the walls of a house which is falling down. Fixing the words (the walls) will never be enough. 

If only one wall is broken, but the rest of the house was built properly from the ground up, and the hole in the wall doesn’t affect the electrical, plumbing, or architectural support the building needs, then we can fix the wall. When an experience is built with consistent terminology, voice, information architecture, and ways to find, maintain, internationalize, and update its content, then we only need to fix the words.

If you take a close look at any software product, language is everywhere. The challenge is how to introduce a more strategic approach to fixing the underlying experience created by the language. To fix the walls (and support the house), we need to apply some engineering principles to UX writing itself, and to how the UX writing process fits into the overall engineering process.

Author:
Stephen Eastham, Technical Copywriter, Platform & Tools

Get in Touch

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.








    Building better SaaS products with UX Writing (Part 2)

    Challenges in UX Writing

    This article describes, from a bottom-up perspective, some of the challenges in UX Writing.

    What is 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

    Language is the tool we use to write words, but natural language can also be a big challenge on many levels.

    What is English?

    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.

    Finding a balance

    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).

    Verbosity

    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”.

    Punctuation and capitalization

    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. 

    Terminology

    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.

    Translations

    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. 

    Author:
    Stephen Eastham, Technical Copywriter, Platform & Tools

    Get in Touch

    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.








      Building better SaaS products with UX Writing (Part 1)

      What is UX writing?

      Well, UX writing is writing. Ugh, I hear you say! Writing, who needs it? You probably still feel traumatized from your experience of writing at school. You know how it went: you had to read all that old literature stuff (I’m thinking, Mickiewicz, Molière, Shakespeare, et al.); and then regurgitate it back. You probably wrote exactly what your teachers wanted you to write, and the more words you used, the better! When you wrote, you had to follow the “rules” of grammar: you had to know when to add a comma; and when to not add a comma. And, finally, there was the horror of being given a creative writing assignment, an assignment for which you were often given little or no “scope”. Instead you were simply told to use your imagination, and so this was probably the most painful task of all …

      What is UX writing really about?

      But UX writing is a bit different, because UX writing is action-oriented. Yep, UX writing is the “OO7” of writing! That is, UX writing aims to aid the user in taking the right action in a given context. In fact, UX writing is the process of creating all the copy and content of a digital experience. You may find it useful to think of UX writing deliverables in terms of these two categories:

      • microcopy in the UI (button labels, descriptions, explanations, error messages, notifications, etc.)
      • macrocopy (instructions, transactional emails, etc.)

      Long, long ago, in a far-away, much simpler universe …

      For a long time, creating copy for the UI was an after-thought for product teams. Usually, the task of writing microcopy was an extra job for front-end developers, because, well, someone had to fill the gaps, just to release the software. But, to be honest, front-end developers were a rather good choice to have the task of thinking up UI strings. It wasn’t because they were familiar with the latest functionality, although of course they were. But, rather, it was because front-end devs were very aware of the most important aspect of UX writing, the element of context.

      You know, natural, human language is a strange, slippery kind of beast:
      “When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean – neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master – that’s all.”

      Context is everything

      Of course, as you’d expect from an anthropomorphic egg, Humpty Dumpty was talking rubbish. In truth, with language, context is the master. With language, context is everything. We will come back to the subject of context later. Anyway, in many cases, the approach of dumping the task on the already hard-at-work front-end devs worked well enough, way, way back in the pre-SaaS era …

      Why is UX writing so important for SaaS products?

      To answer this question, let’s think about the very nature of SaaS products.

      Maybe your SaaS product solves an old problem in an innovative way. It’s great that you have a new solution! But, as you’re solving an old problem, then, by definition, this probably means that you’re fighting with serious competition in a crowded market. To survive, you must distinguish yourself by providing a top-class customer experience whenever your product is being used. Of course, a positive customer experience comes both from the fact that your software is good (the software works as it should), and from the fact that your users have a good experience whilst they use your good software.

      Let’s say that you’re developing a new email marketing platform, the next Mailchimp. In this case, you don’t need to explain the value of such a platform. But, you must show (not tell) why your platform is better than all the other, existing platforms. You need a clear unique selling point (or even more than one) in terms of functionality, and great UX. The bedrock of UX is certainly good graphical, interface design. And this will suffice for short, simple, linear, limited functionality. But, beyond such a limited scope, even the best graphical design struggles to communicate a message in a way which is unambiguous. And, seriously, how many SaaS products stick to providing simple functionality? In fact, most SaaS brands are seen as innovators.

      Have you noticed a subtle, but important, change in the meaning of the term SaaS? We’re no longer treating SaaS as meaning Software-as-a-Service. No, Sir! Now, SaaS means Software-as-a-Strategy, which is a quite different beastie …

      The whole point of SaaS is that the product is not stuck in a rut, and that changes are easy (well, easier from a technical point of view than pre-SaaS). But, notice that SaaS is a double-edged sword: on the one hand, yeah, terrific, we, the software company, can pivot at will; on the other hand, all customers (both old, and new, customers) expect an SaaS product to be customized perfectly to their individual, and constantly changing, needs. In reality, SaaS products must provide an ever improving customer experience.

      Or, maybe your SaaS product solves a new problem, because you’re a real “trailblazer”. That’s also great. Perhaps even better than just “great”. But, “better than great” means that, on a whole new level, you have to make sure that your software is super, and that your users have an out-of-this-world positive experience whilst using your super software. Plus, you have an extra problem compared to the SaaS products which solve an old problem: if you’re offering something your target audience has never heard of before, or has never used before, then you’ll need to do a lot of explaining. And, in most cases, and most of the time, why shouldn’t the user be able to operate software well enough by taking cues from within the UI itself? But, for this to happen, you need to stick to good UX practices, which includes good UX writing practices.

      In part 2 of this article, I’ll describe some of the challenges in UX Writing.

      Author:
      Stephen Eastham, Technical Copywriter, Platform & Tools

      Get in Touch

      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.