Benchwriting | What are our references in UX Writing?
When we talk about processes in Design, it’s essential to look abroad and benchmark to collect inspiration and other perspectives for some solutions. But when the focus is content, how is this (or should it be) done?
Benchwriting is our new neologism to talk about the analysis of Design references focused on UX Writing.
As UX Writers in a cross-role position here at QuintoAndar, we — Karine Lima and Natalia Petrosky — thought it would be nice to share our applications and learnings.
- Why benchmarking for UX Writing?
- How and what format should you use?
- Applications in projects
- What we’ve learned by benchwriting
- What are our UX Writing references anyways?
1. Why benchmarking for UX Writing?
You already know that UX Writing is a discipline full of methodologies and specific techniques. That means the discussion about gender language in digital products, for example, is only the tip of the iceberg.
Adaptations and creations involving content don’t just pop out and consolidate out of nowhere. Therefore, making a compilation of references on how an interaction solves a given problem through content, or how that specific screen can improve the conversion because of a language adjustment is a way to enhance your repertoire as a UX Writer.
But compiling screenshots is useless. Screenshot by screenshot becomes a collage wall.
Understanding the flaws, insights, advantages, and drawbacks of that references is crucial. Use and abuse arrows, scribbles, questions, highlights, and all visual aids for critical analysis. The more we train a keen look for different scenarios, the faster we can develop better solutions for our content — whether it’s textual, iconographic, imagery, or structural.
2. How and what format should you use?
It sounds cliché, but the best format depends on your objective, the level of depth and detail, and who’s the audience.
We tested some options that you can adapt to fit into your reality. These formats aren’t complex, so if you have no familiarity with prototyping tools, fear not!
Google Sheets
Pros: You can document all the screens in the flow format, detail the journey moment, and bring content suggestions.
Cons: It’s a bit tricky to get a clear picture of the screen details and highlight information, as well as more detailed analyses.
Google Slides
Pros: Positive point for visual markings. It’s easier to enhance our analyses through the features of the Slides, such as highlights and arrows. Besides, the format is ready for presentations, and it’s accessible so that people from different areas can collaborate with comments and observations.
Cons: As space per slide is limited, you can’t get a macro view when analyzing the flow of a feature, for example. Maybe it would be more interesting to use the platform for punctual reference compilation.
Figjam
Pros: (it can be a suspicious suggestion since this format is the one that better worked for our team). We were able to take the best of both Slides and Sheets’ worlds in one place. On Figjam, you can document the whole flow and use visual aids to make the analysis clear and detailed.
Cons: There are still some format limitations, especially when compared to Figma.
3. Applications in projects
We chose to share three projects where each benchwriting performed different functions along the Design process.
Discovery Phase
Context: Discovery of a new feature/solution
Goal: Learn from other players’ solutions (competitors or not) and understand what works to prevent mistakes when designing our feature.
Diagnosis Phase
Context: Analysis of the relationship ruler and the flow of recommendation emails
Goal: Map different types of communication, such as real estate and e-commerce, to learn about properties recommendation, information architecture, experience building, language, translation, brand positioning, and unsubscribe flows.
Reference Building Phase
Context: Creating a repository for the UX Writing team
Goal: Gather current examples of UX Writing applications together with the user experience view, considering different brands, areas of expertise, interfaces, and specific journey points.
In this file, were (and are being) mapped: experiences and cases focused on content iteration, specific contexts of application of writing techniques, and evolution of scenarios on standard screens (warning, abandoned cart, checkout, error, action feedback, forms, notification management, login, onboarding, profiling, tracking, password reset, reviews, success and unsubscribe). The archive is live and constantly updated.
4. What we’ve learned by benchwriting
Benching for the content deepened discussions with stakeholders, expanded new possibilities, and even matured our critical view on making some rules more flexible:
“One must first know the rules to break them.” — David B. Agus
I) Never say never
Don’t get attached to rules as if they were immutable. Each case is different, and context is essential when deciding what word to use or what expression is appropriate, for example.
- Jargon
We always hear that we need to make the information clear, without any doubts. And it makes perfect sense. But to say “we can’t use jargon under any circumstances” doesn’t. We need to understand the function of the product and its context before making decisions like that.
Example: If the product is an investment application, why not use terms related to the finance world? We don’t need to discover new terms to make it easier to understand all the time — this can even generate more doubt than clarity. If the person already has familiarity with investment services, why change the expressions that are known? Maybe the best way out has more to do with explaining what the term means and less about creating new nomenclatures.
- Passive voice
As with jargon, passive voice is another topic for discussion and consideration (depending on the context).
Who is making the action? The product or the system? The passive voice can be a possibility to bring information in a lighter way when we are talking about a sensitive subject, such as when the payment is late.
Instead of putting the “blame” on the user and creating a feeling of frustration and discomfort, we can rely on the passive voice to get around this obstacle:
II) Be careful with literal translations
Translating to the letter may seem to be a safe path, but it almost always causes misunderstandings.
Spotify Example 1: The contextualization of the English translation “Listening is everything” to Portuguese is ableist and reductionist. Instead of “Listening is everything” (judgment of value), we have “Listening changes everything” (judgment of fact). In other translations: for French, there’s the use of commas and the reinforcement of the term Spotify accompanied in the call; for Spanish, Spotify Free is translated exclusively for Spotify Gratis.
Spotify Example 2: The Portuguese translation of “Jump back in” would be “Coming back from a jump”. So the contextualization added an emotional charge (“Your songs miss you”). Then it adds familiarity with “Keep liking where you left off” instead of “Pick up your music right where you left off”. It is also more clear and usual to mention “Access the web player”, rather than “Open web player”.
Amazon example: it is common to find pages that are half in English, half in Portuguese, and excerpts of literal translations from one language to another. Amazon itself clarifies that (1) the translation is almost automatic and limited to Brazilian Portuguese, Spanish, “Simplified Chinese” and German, and (2) the definitive version is in the English language. Then what is the perception of experience for not Native English users?
Being used and the best option is not the same
A critical look at the content experience requires going beyond the brand’s popularity and the benefit of the product or service. Making notes in communication does not diminish the value of the object in question.
It’s okay to adopt critical positions about Spotify, Netflix, Amazon, Apple, and Google. They are undeniable references for technology and service quality, but they are not references in UX Writing for Brazil. We know very little about teams abroad and the day-to-day basis of UX Writers in large international companies. Are there teams in charge of localization for Brazilian Portuguese? Native teams? How are culture, customs, and regionalisms in communication studied?
People don’t use a particular service because that company’s microcopy is impeccable. They neither stop using it because it sucks. But yes, the experience can be faster, simpler, more autonomous, and better because of the UX Writer.
5. What are our UX Writing references anyways?
Short answer: no one and everybody.
Long answer: there are companies to be inspired by, but there will never be the only source of truth. Having great content on a particular screen doesn’t mean that all of a company’s communications will be effective in all contexts.
Question things. Critique with a mature and respectful eye to those decisions, stress the possibilities, consider non-obvious examples, include unknown companies, and train the analytical skill of the whole.
Capital letters won’t always be a bad thing. Using a funny tone of voice won’t always fit. Gender won’t always be a problem. And those screens won’t always require text.
When the subject is the communication experience with the user, avoid extremes, simplistic comparisons, and universal conclusions.
In essence, nothing is, everything is. And probably for a good reason.
