Key Skill: being able to Lovingly "Chifle" (Quarrel) with Developers

In our previous article "UX Writing – Who, what, and above all, why?" we described which competencies UX Writing requires and what the mission of this field is. I’d like to explain an example of use cases of UX Writing processes, how they can look, and how the Technical Editorial department could become involved in a specific customer project that I’ve been able to support for almost a year now.

My first (and previously, my main) project as a UX Writer was a kind of gentle introduction to the work. I accompanied the development of an internal software for the device service. "Hmm, but for internal software, the effort for UX optimisation seems hardly worth it", may be a relevant thought here now. In the case of my customer, the decision also came only after a painful experience. The predecessor of the new piece of software gave many Service Technicians headaches and wasted a lot of time. Especially in countries where the programme’s interface hadn’t been translated into the respective local languages, errors occurred, due to complicated instructions (in English) and unnecessary process loops. The money that had been saved on UX was then lost because of needed support. Therefore, in addition to a simpler architecture, a UX Writer from the Technical Editorial department (i.e. yours truly) was used for the new version. For this project, I concentrated purely on the GUI texts, which I checked for linguistic correctness, comprehensibility and usability.

Advantages of UX Writing

Even with this comparatively manageable programme there was enough to do, because the fact that a team of developers, usually consisting of several people, works on a software programme quickly leads to inconsistencies, and in the worst case scenario, almost contradictory wordings. The whole thing is made even more difficult if the texts are written in English, but this language is a foreign language for the vast majority of those involved.

Luckily for me, reviewing GUI texts at the customer site is no longer a brand new idea that would have taken a lot of convincing from R & D. Rather, UX and review processes were integrated into the development work a few years ago and are appreciated by Project Leaders and Product Management, as they represent a clear increase in quality, and thus better saleability of products.

The process basically looks like this:

Developers write GUI texts ⇒ UX Writer parses texts in Localisation Tool ⇒ UX Writer checks texts ⇒ UX Writer initiates translations

Within agile projects, however, this is of course not a rigid, one-time process, but iterative and continuous. So I always parse the latest texts from the repository during the whole development time and clarify a lot of things continuously. We also arrange for the translation to be staggered, so that possible weak points can be ironed out between the individual translations.

Work Accompanying the Process

My next project will be the control software for the division's most prestigious (and therefore most expensive) line of devices, where the UI must of course not only keep up with the high quality of the hardware, but also represent a selling point in its own right. During this project, I'm kind of moving up a level, because I'm already involved in the creation of the mock-ups (i.e. digital designs). In the future, I will therefore regularly (and lovingly) “quarrel” (or “chifle”, as it’s referred to here in Switzerland) with my colleagues from GUI Design about details within the user interface texts and architecture that may seem trivial at first glance, but are important in the application.

Points that are very important for both projects are the following:

• Linguistic Correctness
• Adherence to Terminology (and Corporate Communication Guidelines)
• Consideration of the Target Audience
• Comprehensibility and Simplicity of the Texts
• Optimisation of the Usability
• Optimisation of texts for Translation

It's easy to see: For Technical Editors, these are all everyday topics that we have in our blood and which we already apply throughout our daily work. With the knowledge that we already implement in the documentation, we can also make Operating Manuals and instructions that are embedded in the software more user-friendly, and thus significantly improve the overall user experience. Of course, we also benefit from the fact that we’re used to gathering information from absolutely everywhere.

The Practical Side

The tools for a smooth integration of UX Writing are already available. For my customer, for example, I work with SDL Passolo, which allows GUI source texts from the repository to be managed as in a CAT Tool (this also ensures consistency of texts across multiple projects). Only the target texts have to be included in the code in a one-time process. In order to check the texts for usability, the demo versions of the programme are made available to me on my computer, and I can call up the latest build in each case. In case I still get stuck and don't know exactly where a text is used, I work closely together with the developers (who conveniently sit right across the hall from me). So my the relationship with the people from the Development department is pretty relaxed, and we enjoy taking the time to have a look at something together. Over a cup of coffee, they sometimes discuss Terminology with me.

I really enjoy my work, and it’s been very instructive for everyone involved. For the products, too, this process — which may initially be perceived as a detour, is only advantageous. After all, the same applies to software: if something isn’t understood, then it won’t be followed.