Hi, I'm Elmi, a content & UX writer.

Sample 01

Payment Failed

Context: The user taps Pay Now and the payment fails. Their single biggest fear in this moment: "Did I just get charged?"

There is no cause, no next step, and the only button is a dead end. Worst of all it never answers the money in question. Almost always, the user leaves the app to check their bank balance, and the sale is lost.

Why it works

• Reassure first. "No money was taken" answers the top fear before anything else. No anxiety, no leaving the app.
• Plain cause, no blame. The next instruction explains without making the user feel stupid or accused.
• Two real exits. Primary action assumes the method was the problem (most common fix); secondary lets the confident user retry. No dead-end "OK."
• Title states the fact, not "Error." "Payment didn't go through" is understood in one glance; "Error" lets the user assumes what went wrong.

Sample 02

Empty Cart

Context: The user opens their cart and it's empty. An empty screen is a missed moment, it can be a wall or a doorway.

A full stop. It describes a state and offers nothing to do next.

Why it works

• "still empty" reframes emptiness as temporary, not a failure.
• It adds action words. The action word "add here" recovers intent the user already showed; "Browse deals" gives a fresh start. Both point to a path forward.
• One primary action. Empty states should make the next tap obvious, not offer a menu.

Sample 03

Notification Priming

Context: A new user finishes signup. The OS notification prompt is one-shot. If they tap "Don't Allow," it's very hard to recover. So we earn the yes before the system asks.

No reason given, no purpose known. Most users reflexively decline which causes lost opportunity.

Why it works

• Asks in value terms, not permission terms. "First dibs on flash sales" is a benefit while "send you notifications" is a chore.
• Names the two things users actually want: items on sale and order updates.
• "No spam, promise" pre-empts the real objection.
• "Maybe later" keeps the door open. Declining here doesn't burn the system prompt, so we can ask again at a better moment (e.g. right after they place an order).

Sample 04

Inline Form Validation: Wrong Phone Number

Context: The user is typing their shipping address at checkout and leaves the phone field in a bad format. A confusing error here stalls the single most important flow in the app.

Which field? Why invalid? How do I fix it? It tells the user they're wrong without telling them how to be right.

Why it works

• Guidance is clear. Says whats needed, not what's wrong.
• Gives the reason ("so the courier can reach you"). It's easier for people to follow rules they understand.
• Shows the format with a real example instead of describing it. An example parses faster than "must be 10-13 digits."
• No red "Invalid" shouting unless the user actively submits a broken value.

Sample 05

Variations of Order - Status Notifications

Context: A push series across the order lifecycle. The craft here is consistency and rhythm so the messages should feel like one voice guiding you through every step.

Why it works

• One arc, one voice. Each message picks up where the last left off, so the series feels like a person, not a system.
• Every message earns the next open by adding a small piece of value like a track link, a heads-up, a new estimate.
• The delay message leads with honesty and ownership ("we're on it") and ends with the one thing the user wants: a new date. Bad news handled well builds more trust than good news.
• Emoji used sparingly and only where the moment is genuinely positive (confirmed, delivered). Never on the delay to avoid raising fear or uncertainty.

Sample 06

Search: no results

Context: The user searches for something with no match. A blank "0 results" is the fastest way to lose a shopper who came with intent.

A dead stop that blames the search. 50:50 chance the user bounces and leaves the app.

Why it works

• "yet" softens the miss and hints the catalog grows.
• Three concrete recovery moves (spelling, broaden, browse) cover the real causes of a zero-result search.
• It still offers product, not just advice. Phrase "related items" keeps the shopping going instead of ending the session.

Sample 07

Voucher Won't Apply: Constraint Feedback

Context: The user pastes a voucher code and it's rejected. A hot moment. They expected to save money but failed. Vague copy here feels like a bait-and-switch.

"Invalid" could mean expired, wrong code, minimum not met, or wrong category. The user can't tell if they made a typo or if Shopee tricked them.

Why it works

• Names the exact reason (minimum not met) instead of a catch-all "invalid."
• Does the math for them ("Shop Rp32,000 more") and reframes the gap as an unlock. A clear reward after a task.
• Turns a stall into momentum with a forward action.

For an expired or wrong code, the same pattern applies: state the real cause "This code expired on {date}", so the user knows clearly what the issue is.

Sample 08

Cancel Order - Destructive Action Confirmation

Context: The user taps "Cancel Order." This is destructive and often irreversible. UX writing's job here is to make sure they mean it without nagging the people who do.

"Are you sure?" carries no information. "Yes/No" forces the user to map the question back to the action which is basically a classic source of mis-taps. And it states no consequence.

Why it works

• Buttons name the action, not Yes/No. The user can act on the buttons alone without re-reading the question. Also the safe choice ("Keep my order") is phrased to feel like the easy default.
• States the real consequence: refund amount, where it goes, how long. Exactly what the user needs to know.
• "This can't be undone" sets the right weight. An honest friction on an irreversible action.

Sample 09

OTP Verification: entry + error

Context: The user is logging in and must enter a one-time code sent by SMS. OTP screens are pure friction, the writing's only job is to remove confusion fast.

"OTP" is jargon many users don't know. "Wrong OTP" doesn't say what to do: re-type? Resend? Wait?

Why it works

• "6-digit code" instead of "OTP": plain language anyone understands.
• Shows where it went (masked number) so the user knows which phone to check, and sets the expectation that it's not instant.
• The resend timer in button to help the user navigates the help in an obvious way so the user won't get stuck.
• The error says what to do, not just that they're wrong.