UX Editor: True Story, Rial Life
Hi, this is Natasha, the lead editor at UX Yandex.Money. I am writing this text because I can no longer be silent about my work.
Previously, they thought about us that we are copywriters. We write better than managers. We are able to check literacy. Editing to make it clearer. We remove the extra words.
Now they think that we are microtext writers. We invent the right button for the button. Check whether the link is called correctly. We cut everything that is bad.
So what don't you like, Natasha?
I do not renounce buttons, links, labels and tooltips. I love them, cut them with a jigsaw, fold and fold them, except that I don’t drive to bars.
But all this is about the sixth part of my (our) work. Last one When passed five sixths. Somehow: first I went to the grocery store, washed the vegetables, took off the peel, cut it into cubes and straws, made broth, once every ten minutes I ran to see if it had run away. And finally, add salt, pepper and Lavrushka. Buttons, links, tooltips. Letters
I (we) have a hell of a lack of people who understand that a specific text is super important, but still the last stage in the work of the UX editor.
You can not just take and "write one button," or "come up with a headline here," or "correct the letters on the layout." A layout is not a separate picture in a frame: it is almost always part of a process. And the process is part of the product for which we all (designers, editors, analysts and product managers) are working on the UX.
At the very beginning, at the level of meaning
The editors in Money have such a conditional layout:
- first you work at the level of general meaning,
- then you decide how to decompose this meaning by steps and priorities,
- at the end you go to the wording and tonality.
The first stage - about the meaning - implies that the UX editor connects to the project at the very beginning. And when I say “at the very beginning,” I’m not talking about the “designer begins to work on mock-ups.” I’m talking about a real start: there is a justification, an idea and a general concept;
This is where a small UX-team comes into play: a designer and editor.
What does the technical solution
I am not an analyst, not a developer, not a product manager. I will not go into how the components of the system should communicate with each other or how the new technical scheme will affect business performance.
But we together with the UX-designer will get into another - for example:
- what user states should be taken into account on the form : you can immediately send these people to pay, others need to be sent through a personal data questionnaire,
- what data to pull up on a specific page : here the balance of the loan debt is important, and there is the address of the post office where the bank card will arrive,
- what logic should be laid for status messages : here we definitely need a separate page with details (and there, by the way, we need to forward data from the first step), and there it’s more logical to simply return to the section and hang up a little hint to a specific item.
This does not mean that apart from us there is no one to think about the logic and nuances. This means that the editor and designer always discuss the technical solution to make sure that we need the data, statuses, parameters in place. So you can continue to work.
From technical to human
There is a man, and a man wants to do something. There is a system that can do this: but first, it needs something in return.
One of the main tasks of a UX editor is to remember that it works for a person. Therefore, everything that the system wants from a person, the editor translates into human language. First - at the level of meaning, then at the level of the text.
About the general meaning
A huge part of our work goes under the sign of the constellation "Why". This is probably a favorite question from the UX editor.
- Why do we think that this is important for people, the editor will ask the product manager.
- Why is it necessary to guide a person through this point, he will ask the analyst.
- Why do we validate these data in different ways, ask the developer.
“Why do we even want a person to indicate this, ask someone else.”
My perfect meeting shirt
Some “because” will be simple and understandable: the person and the system want about the same thing, they simply formulate it differently. Next is the matter of the text.
Others will be tied to complex internal logic or system constraints. But after the “why” series it may well turn out that the logic can be changed and the restrictions avoided. So the editor will affect the script, and instead of five screens (seven buttons) there will be two screens (buttons - three). Tru story, rial life.
About the text
Offhand, if not very deeply immersed, it seems: interface texts must follow strict rules. Button - the verb. Toggle switch - on / off. Link - an indication of the place. It seems simple.
We believe in other things: interface texts are a reflection of the human manner of dialogue.
- The system wants the user to “read the terms and conditions” and click “Confirm”. As a person, I want to tell her that I "understand."
- The system wants to say: error, wrong number. I want to see: here is a typo - check the number again.
Of course, this is not always possible, and it does not always work. Among other things, also because the humanity of the text is a damn subjective thing.
For example, it seemed to us for a long time that there was an excellent heading for technical errors - “Something went wrong.” Suitable for any case, indicates the fact of error, while in it not a drop of robotization. But time and feedback showed that people are very annoyed when “something goes wrong.” What, they ask, what exactly? In general, in the new errors “something” is no longer present (and we are gradually catching the old ones).
It will never end (hello, chat)
I used to think: you started the project, you worked, you got to start - you can breathe out and switch to the next task.
Now I know that this does not happen.
The editor (and designer) remains in the mode of chronic support, because: a) the product changes all the time, b) users come up with new questions or even c) some feature did not work the way we expected.
For example, I have two chat cards with a team of bank cards. One product: there is PO, PM, an analyst, a person from support and we are a designer from UX. The second chat with the front-end: there we are again with the designer, PM and the developers.
Grocery chat is needed so that all grocery does not pass by. For example: support signals that people began to come often with a similar question. We immediately discuss how to treat it: design, text, modifications on backups (or in general, all at once).
In the chat with the front-end, we solve streaming tasks: there is not enough clues for the field, somewhere the alignment has gone. Or even - what kind of back-up testing is better to use from the point of view of UX in this particular place: synchronous or asynchronous (they explained the difference to me, now I show that in the subject at every opportunity).
As a result, the whole team is at your fingertips. And you are at hand. Conveniently.
Collective Intelligence +1
UX editors are not ideal data processing machines. We are mistaken, stupid, forget to take into account something important. Or vice versa, we are so deeply immersed in the context that it is almost impossible to emerge and look at our own work with the fresh look of the user.
There are obvious ways to deal with this. Let me see a colleague who does not know the details, watch the user on the study, switch to another task and come back when you lose the context a little.
There are less obvious: collect successful solutions in the library, deduce algorithms that you can rely on in new projects.
And there is also a team - as a collective brain. And this team needs more UX-editors: study technical solutions, think about the meaning, grind out words (and periodically blunt, where without it).
If you have such a person in mind, or you yourself are such a person, see our vacancy .