> If devs follow certain simple rules while writing UI text, it would make a tremendous difference for translation quality

As a UI Developer that has accidentally focused my whole career in building (complex) forms, I can tell you there is a night and day difference from when I worked alongside User Assistance professionals vs when UX designers had to come up with the texts. These “User Assistance professionals” were usually English/Language-majored that would exclusively take care of how to properly write the texts on the screen for the users. From help texts to button labels, to release notes and RCA, and especially taking care of how to write texts in English so the app would be easily translatable, they would own all. The apps that had that sort of handholding with the devs were extremely easier to use and input data to, even when the UX itself was subpar.

I used to think it was standard to have English-focused professionals helping UI teams to deliver easy to understand products, only to find out that that company was kinda odd in that regard, and having UX or even product people coming up with labels is quite common. I do miss being able to fire an email when I need a quick text reviewed to be sure that a button is well labeled for the user and translation.

▲

eru 7 hours ago | parent | next [-]

> I used to think it was standard to have English-focused professionals helping UI teams to deliver easy to understand products, only to find out that that company was kinda odd in that regard, [...]

Which is a bit of a shame, because English/Language-majored people's time is cheaper than techies' time.

Google is another outlier in a related way: they have dedicated tech writers to produce internal documentation.

	▲	SoftTalker 24 minutes ago \| parent \| next [-]
		> English/Language-majored people's time is cheaper than techies' time. Which is odd, because it's harder to communicate unambiguously in English than it is in code.
	▲	robertlagrant 4 hours ago \| parent \| prev [-]
		> they have dedicated tech writers to produce internal documentation The trick with tech writing is retention!

▲

ivan_gammel 7 hours ago | parent | prev [-]

The role you are describing is UX copywriting. In companies working on international markets it’s common to have it assigned to a dedicated team responsible for localization, but it’s also perfectly normal and common for UX designers to do it - it’s part of their job. Product managers can do it too, but ideally shouldn’t.

Edit: Also have to note that education in language or literature doesn’t make person a good UX copywriter automatically. It’s a cross-domain job with multiple career paths towards it. You were lucky to work with someone who really excelled in it.

▲

Stratoscope 3 hours ago | parent [-]

I am a mere programmer, not any kind of UX writer.

A company I worked for some 20 years ago had writers who mostly thought about the "happy path". When things went wrong, the error messages were left up to the programmers.

I discovered this when I tried to install our product on an old Mac and got this message:

Your hard disk is too small

Wait? My what is too small?

Later, on Windows, I got this popup:

You are not here

WTF?

I searched for this message and found it came from a function called CantHappen(), which was kind of like an assert(false). Something you throw into a code path just to note a place that you really know the code can never reach. Until it inevitably does.

I went on a rampage through our code, finding all these crazy messages and updating them - and when possible, fixing the code so the error messages wouldn't be needed.

My manager and his manager, to their credit, knew how bad our messages were, and they helped me pull together a little team with a writer and translators to fix these up. And we did. Our messages got a lot better, easier to understand and more helpful.

All because our Mac installer told me my hard disk was too small.

	▲	ivan_gammel 3 hours ago \| parent [-]
		Great story and exemplar attitude from you and your manager! Too often such issues are eternally deprioritized, but you have got it into the pipeline and the team committed resources for fix. Ideally this should not happen, but that would require end-to-end collaboration of the entire team where UX people are involved on later stages of development process, adapting design and copy based on feedback from engineers. Many modern product designers just work based on „shoot and forget“ principle.