UX writing interface copy and store pages
UX writing is the copy a person reads inside an app: button labels, field hints, error messages, onboarding screens, empty states, push notifications. Our UX writing services cover this microcopy for mobile apps and web products, the App Store and Google Play descriptions, and a glossary, so that one thing has one name on every screen.
01 Definition
UX writing is the work of writing the words inside a product so that a person can do what they installed it for: place an order, pay a bill, book a doctor, send money. An ad persuades someone to install the app. Interface copy guides them once they are in.
When it works, nobody notices it. A person taps a button and gets what the button said. The copy becomes visible when “Next” leads somewhere unexpected, an error says “Something went wrong,” and an empty screen says “No data.” Then the team doesn't get conversions. It gets support tickets and uninstalls.
People search for “UX writing,” “UX copywriting” and “microcopy,” and inside product teams you'll hear “content design” as well. For the purposes of an order they all mean the same thing: short, functional text on screens. We use all the names on this page because clients look for us under different ones.
We write for iOS and Android apps, and just as often for web products with a login: customer accounts, booking forms, admin panels, internal tools. The principles are the same, and so is the price per screen.
02 The difference
Clients often ask for “copy for the app” and receive advertising language on their buttons. Below are three different jobs that are easy to confuse.
| Job | Where the text lives | Goal | Length |
|---|---|---|---|
| UX copy | Buttons, fields, errors, onboarding, push | The person knows what to do next | 1 to 15 words |
| Store listing | App Store, Google Play | The person installs the app | up to 4,000 characters |
| App advertising | Social media, search ads | The person clicks the link | depends on the format |
These jobs share one rule: the words must be plain and honest. Everything else differs. A button has no room for a metaphor, and a store listing has no room for the team's internal jargon. Whoever writes the interface has to see the screen, not just a brief, so we work from mockups and flows rather than from a description in words.
Who needs this: teams about to release, where the copy was written by a designer and a few developers between other tasks; products that are entering a new market and need the interface in a second language; companies whose support team answers the same question every day, when one line on a screen could have answered it.
03 Examples
Six screens from an invented food delivery app. The app doesn't exist, but the wording in the “Before” column is typical: you can find lines like these on your own phone.
Error. Transaction declined (code 05).
Your bank declined the payment. Check your card limit or pay with another card.
why: the message says what happened, who did it and what to do next. The error code stays in small print at the bottom, because support needs it and the user doesn't.
Confirm
Pay $24.50
why: “Confirm” could mean the address, the order or the charge. A button with a verb and an amount leaves no doubt about what happens after the tap.
Allow notifications so you never miss anything important.
We'll tell you when your courier leaves and when they're five minutes away. No promotions, ever.
why: iOS shows its system permission dialog once, so the explanation before it has to be specific. Many people read “important” as “ads” and decline.
No data
Your orders will show up here. Your first one takes a few minutes.
Button: Browse meals
why: a new user sees this screen first. Instead of a report on the state of the database, they get an explanation of what will appear here and a button to start.
Welcome to FoodGo. We built the most convenient delivery experience for you and your loved ones.
Lunch in 30 minutes. Enter your address and we'll show what we can deliver.
why: the first screen doesn't greet, it names the benefit and asks for the one action that matters. There's no point praising the service before the person has seen a single dish.
Invalid input format
Add your country code and use digits only. Example: +1 415 555 0132
why: a form error shows the rule and a sample. The user doesn't have to guess what exactly is “invalid.”
04 Scope
You can order everything at once or a single part, for example only onboarding or only error messages. The second column says where each kind of text lives.
05 Principles
Bad UX copy is easy to recognize: it talks about the system instead of the person. These are the five rules we check every screen against, and the usual ways they get broken.
| Rule | How it's broken | How it should read | Where you see it |
|---|---|---|---|
| One action, one word | “OK,” “Next” and “Confirm” used in three different meanings | “Save address,” “Pay $24.50” | buttons |
| Talk about the person | “Transaction failed” | “Your money wasn't taken. Try again” | errors |
| Main thing first | A long intro before the single action | The action in the headline, the explanation below | screens |
| No jargon | “Authorization failed,” “invalid token” | “Please sign in again” | system messages |
| One voice | A cheerful joke on the first screen and bureaucratic wording in the error | The tone from the glossary on every screen | whole product |
Imagine a banking app where entering the SMS code wrongly produced this message: “Error 4012. Invalid OTP.” Part of the users decide the app is broken and call the helpline. Rewritten, it says: “That code didn't work. Check your text messages and enter all six digits again. You can request a new code in 30 seconds.” The example is illustrative, a typical case and not one of our projects. The difference is that the second message closes a question that would otherwise end up in the support chat.
06 Tone of voice
A tone of voice is a set of answers to questions that a team usually re-decides every time: formal or casual, jokes in error messages or none, which technical terms are fine, what to call money, orders and accounts. We put them on a single page, and any new screen is written against it without new arguments.
The glossary sits next to it. It lists the terms: “cart” and not “basket,” “sign in” and not “authenticate,” “account” and not “profile” for the same thing. Developers, support, marketers and translators all work from it, particularly when the app ships in another language.
07 Stores
The same features have to be described twice, because the fields differ and search works differently in each store. The limits below were correct when we wrote this page. Check them against the stores' current rules before publishing.
The name takes up to 30 characters and so does the subtitle. A separate keywords field holds 100 characters that the user never sees. These three fields do the work for search.
The description can run to 4,000 characters, but the page shows only the first lines and hides the rest behind “more.” So the main point goes into the first two sentences.
The title takes up to 30 characters, the short description up to 80 and the full one up to 4,000. There is no keywords field: search takes words from the title and descriptions.
So we work the search phrases into ordinary sentences. Google Play treats keyword lists as spam, and a page can be rejected for them.
In store results a person first sees the icon, the name and the screenshots. Not everyone reaches the description. A short caption on each screenshot says what the app gives the user: “See your courier on the map in real time,” not “Convenient interface.”
Weak: “FoodGo is an innovative next-generation platform that connects restaurants and users.” It tells a person scrolling through results nothing. Better: “Order lunch from restaurants nearby and follow your courier on the map. Delivery from 20 minutes, pay by card or on arrival.” The app is invented. The second version has an action, a benefit and facts that can be checked.
08 New area
When an app gets a chat assistant or smart suggestions, it needs words in places where no human wrote the answer in advance. What it needs is rules for how the system speaks. That is UX writing for AI features.
What we write:
This helps when a team has connected a model and notices the answers sound like someone else. The tone rules from the glossary then become the basis for the model's instructions. The screen copy itself is still written by people. We don't hand over neural network output as authored text.
09 Working with your team
UX copy isn't written in an empty document. We need to see the screen where a phrase will sit, and your developers need to receive it in a form they can paste into code without rewriting.
View and comment access to your Figma files, or a test build. A list of flows: sign-up, ordering, payment, returns. A few words about your users: who they are and in what situation they open the app.
A table where every string has a screen, the current text, the new text and a note for the designer: length limit, a shorter variant for small screens. If you prefer, we leave the copy as comments right in the mockup.
Separately, we deliver the glossary: what sections, actions and statuses are called, whether the product addresses people formally or casually, and whether it jokes in error messages.
We write in a table or a document and don't enter text into Figma or code ourselves: your designer or developer does that. If another arrangement suits you better, we agree on it at the start.
10 Prices
We price by the screen. Onboarding, sign-up and checkout across 12 screens come to $1,080 with the glossary. A small app with 30 screens comes to $2,700. A store listing is quoted separately, because the price depends on the number of languages and fields.
| Service | What's included | Turnaround | Price |
|---|---|---|---|
| App and UX copy | Interface copy, term glossary | depends on scope | from $90 / screen |
| Email copywriting | Subject line, preheader, body copy, call to action | 2–3 days | from $180 / email |
| Copywriting in other languages | Copy, review by a language editor | 4–5 days | from $0.22 / word |
| Translation services | Translation, editing, term glossary | from 2,000 words a day | from $0.10 / word |
On freelance sites an interface string is cheap, but nobody there is writing for a screen. At our price, an author and an editor both work on each screen: the author looks at the mockup and the flow, the editor checks terms against the glossary and length against the constraints. You are paying for the button on the first screen and the button at checkout speaking in the same voice, and for your developer getting a clear table instead of a file with ten versions. For a product whose support team answers the same question every day, that costs less than another release.
11 Choosing a writer
12 Questions
UX writing is the short text in an interface: buttons, hints, errors, onboarding. A UX writer writes it for a specific mockup so that people can complete an action without effort. A copywriter writes to persuade: ads, product pages, store listings. We do both, and on this page we separate which job is which.
The headline, field labels, buttons, hints, error messages, the empty state, the loading state, and push notifications if they are tied to that screen. A screen is counted together with all of its states, and you don't pay extra for them.
Yes, the glossary is in the price. It's a document of one or two pages: names of sections, actions and statuses, how the product addresses people, and rules for jokes and technical terms. Developers and support work from it.
Yes. We write to the length limits in the mockup. For buttons and headlines we also give a short variant, since text in other languages often runs longer than English. The designer makes the final check in the layout.
We ask for view and comment access. We hand the copy over as a table or as comments in the mockup, and your designer enters it. We don't change anything in Figma ourselves.
Yes, and you can order only that. We need a list of features, two or three competitors and an idea of the words people use to search for the app. If the page is needed in both stores, we write two versions, because the fields and the search rules differ.
English and Ukrainian are written from scratch. German and French are translated and adapted from your existing copy, with a check by a language editor. Details are on the page about copywriting in other languages.
Yes. We go through every screen, bring the terms into one glossary, and rewrite what is unclear or sounds like several different voices. Lines that already work stay as they are.
The price is from $90 / screen. We count the scope in screens or flows: sign-up, ordering, payment. We name the exact number after reviewing the mockups.
Yes. The principles are the same: a customer account, an order form or a CRM needs clear buttons and errors just as a mobile app does. The page that sells the service is written differently; that is covered in the section on website and landing page copy.
13 Related
Roholeva is a copywriting, promotion and web development studio. The copy, the landing page for the app and the ads can come from one team, so terms and tone match at every stage.
Get a quote
Two sentences are enough: what the product is and what you need — copy, a website or marketing. We reply within one business day.