[psidium]

> 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]

> 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]

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

[eru]

Compensation ain't about how hard something is in an absolute sense. At least that's only one part of it.

Playing an instrument is harder than being a code monkey. On the one hand, you can make good money being a top tier musician, there's almost no money in being a mediocre musician (or even an above average one). On the other hand, it's fairly easy to get by as a mediocre code monkey.

Even as a somewhat subpar software engineer, you can make enough money that you don't have to be waiting tables as your day job.

(Waiting tables itself is a good example at least to contrast with acting or making music or writing novels. None of these aspiring artists and poets is necessarily any good at waiting tables, but it still pays the bills compared to even pretty good acting skills.)

[agos]

It would be nice if they employed some of those dedicated tech writers for external documentation (sorry for the snark, couldn’t help it)

[robertlagrant]

> they have dedicated tech writers to produce internal documentation

The trick with tech writing is retention!

[ivan_gammel]

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]

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]

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.

[LocalH]

What's wrong with "hard disk"? You do realize that is a valid name for an HDD (hard disk drive), even if it's not super common today?

[Stratoscope]

Of course I'm aware of that. After all, I was born before IBM announced the RAMAC 350 Disk Storage Unit. [1] [2]

To understand the problem, consider two things.

First, imagine another word that rhymes with "disk". I will just call it "di*k" here.

Second, the problem wasn't that my hard di*k was too small. I could have the biggest hard di*k in the world, but if it didn't have enough free space, there wouldn't be room to install Acrobat.

So the message had an admittedly slim chance of being misconstrued, but more importantly it was just plain incorrect.

[1] https://www.tomshardware.com/pc-components/hdds/ibm-announce...

[2] https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_d...