Who writes the words in a new startup product, and when should they be written?

Illustrative situation: five weeks before launch, a founder clicks through the staging build of a new B2B app. The sign-up button says “Submit.” The next screen says “Continue,” and the one after that says “Next.” An empty project list reads “No data.” A declined card shows “Error 402.” The invitation email still starts with “Lorem ipsum.” Every screen was approved in Figma. The scene is invented. It shows what happens when a product is designed end to end and nobody owns the words.

Humbleteam, a digital product design agency, publishes this guide. It covers who drafts and approves product words and when, the strings a launch needs, errors and permission prompts, testing, and the handoff to engineering, with a content inventory worksheet and an invented worked example. Platform and standards guidance is described as of November 2, 2026 and can change.

Who owns the words in an end-to-end engagement?

Our guide to what an end-to-end design agency should own from wireframes to launch puts one question in the UI design row of its ownership matrix: who writes the real interface copy? If a proposal leaves that cell blank, the job lands on the founder by default, and the gap tends to show up only in staging, as in the scene above.

Our suggestion is to split the job into four roles and put a name next to each:

• The drafter, usually the agency’s product designer or content designer, writes every interface string from the first wireframe onward.
• The meaning reviewer, the founder or product owner, checks that each string says what the product does and promises nothing it doesn’t.
• The approver for sensitive text, whoever owns legal, billing or compliance, signs off on pricing, consent, terms and payment messages.
• The keeper of the strings, the engineering lead, owns the string file once text moves into code, and changes go through that file rather than through screenshots.

On a small team one person can hold two roles, as long as the proposal names the drafter.

When should real words go into the design?

Real words belong in the design from the wireframes on. In a 2024 NN/g article on promptframes, Evan Sunwall writes that placeholder content, lorem ipsum in particular, can block useful feedback. He reports usability sessions derailed because placeholders confused participants. He also warns that placeholders left in a design hide requirements that surface too late to fix. NN/g’s video on fake copy in UI prototypes adds that placeholders help early on but cause trouble when real content behaves differently.

Map the words onto the phases the engagement already has. In discovery, collect the words customers use in interviews and support tickets. In wireframes, draft headings, buttons, empty states and the main error messages for the core flow. In prototype testing, test those words with the same participants who test the flow. In UI design, complete the inventory, including edge states. During the build, move strings into named keys. In build QA, read every string in staging. Before release, write the store listing and the transactional emails. For a mobile app, Apple’s App Review Guidelines (section 2.1) ask for final versions with placeholder text and other temporary content removed before submission.

On a fixed date, such as the illustrative plan in our guide to launching a startup product in 8 weeks, that means a first draft by the end of the prototype week, not during the week reserved for release fixes.

Which words does a launch-ready product need?

A launch needs words for many states the pitch deck never shows. A useful inventory covers eight groups:

• Onboarding and sign-up: field labels, hints, the first screen after sign-up, invitation text.
• Empty states: NN/g’s guidelines on empty states say an empty container should communicate system status, teach the feature and offer a direct path to the key task. Apple’s writing guidance adds that empty states are usually temporary, so they should not hold information people need later.
• Errors: form validation, failed uploads, lost connections, payment failures, permission denials.
• Confirmations: saved, sent, deleted. Material Design’s UX writing guidance asks teams to tell users what will happen if they take an action and how they can undo it.
• Permission prompts: on Apple platforms you supply the “purpose string” the system shows in the alert. Apple’s privacy guidance asks for a brief, complete, specific sentence in active voice. It gives a vague passive line about microphone access being needed “for a better experience” as an example to avoid.
• Notifications and transactional emails: subject lines, push text, receipts, password resets, the invitation email.
• Settings: Apple suggests describing what a setting does when it is on and letting people infer the opposite.
• Pricing and billing: plan names, what each plan includes, renewal dates, what happens when a payment fails, how cancellation works.

How should error messages be written?

NN/g’s error-message guidelines by Tim Neusesser and Evan Sunwall (2023) give the core rules. Show the message close to the problem. Use plain language and keep error codes for diagnostics. Describe the exact problem rather than “An error occurred.” Offer a remedy. Avoid blaming words such as invalid, illegal or incorrect, skip humor, and keep what the user typed so they can fix it instead of starting over.

Accessibility standards set a floor. WCAG 2.2 success criterion 3.3.1 Error Identification (Level A) requires that when an input error is detected automatically, the item in error is identified and the error is described to the user in text. Criterion 3.3.3 Error Suggestion (Level AA) requires suggestions for correction when they are known, unless that would jeopardize security or the purpose of the content. W3C’s own example: “Email is not valid” meets the first criterion, and a message that also shows the expected format meets both.

Platform guides land in the same place. Apple prefers “Choose a password with at least 8 characters” to a message that only says the password is too short, and it calls interjections like “oops” unnecessary. Microsoft’s style tips replace “Invalid ID” with an example of what a valid ID looks like. Our suggestion is a two-part pattern for every error string: what happened, then what to do now.

Whose writing rules should a startup follow?

The big guides agree on most points and disagree on a few, so pick your rules and write them down. Apple says button labels should almost always be verbs. Material says all text, buttons included, should use sentence case. Microsoft’s advice is “when in doubt, don’t capitalize.” Apple asks teams to choose a capitalization style for each element type and apply it consistently. On the word “we,” they split: Microsoft encourages contractions such as “we’re,” while Apple advises avoiding “we” altogether, because users may not know who “we” is. Its example replaces “We’re having trouble loading this content” with “Unable to load content.”

So keep a one-page voice and terminology list. Apple suggests keeping a list of common terms and referring to it. The Mailchimp Content Style Guide shows the shape: a voice that stays the same, a tone that changes with the reader’s state, and short rules such as active voice and plain English. Its word list settles details like “log in” as a verb and “login” as a noun. For a startup, 15 to 20 entries are usually enough: the product’s core nouns (workspace, account or team, but only one of them), the verbs for core actions, words you never use, and capitalization rules.

How do you test the words before launch?

Put real words into every usability session, then add a check aimed at the longer passages. Readability formulas rate a text’s words and grammar. In NN/g’s article on the cloze test, Jakob Nielsen notes that no formula can tell you whether users understand the text. The cloze test does: replace every sixth word with a blank, ask people from your target audience to fill the gaps alone, and count synonyms as correct. An average of 60% or more suggests the text is reasonably comprehensible for that audience.

Use it on texts people must understand to decide something, such as the plan comparison or the cancellation terms. For short strings, our suggestion is simpler: before a participant taps a button, ask what they expect to happen. Apple adds a check anyone can run: read the text out loud.

How do words get from Figma into the code?

Words should travel as named keys, not as text pasted into components. Android’s localization guide says not to hardcode strings and to declare them as resources, so they can be extracted, translated and put back without changing compiled code. It also asks teams to describe each string’s context: what it is for, where it appears and how much space it has. Its own example notes that a sign-in button fits 30 characters. Apple and web frameworks have their own formats, but the idea carries over.

Plurals need their own entries. Android’s string resources documentation explains that English separates one from many, while other languages make finer distinctions. The full set it supports is zero, one, two, few, many and other. A string glued together as “1 project(s)” cannot be translated well.

Leave room for growth even if you launch in one language. W3C’s article on text size in translation shows that short strings grow the most. It cites IBM figures of 200-300% expansion for English source text up to 10 characters and about 130% for text over 70 characters, and it advises flexible layouts over small fixed-width containers. It names the usual squeeze points: labels beside form fields, text inside graphics and width-restricted tabs.

Status shows which strings are still placeholders a week before release. Source of truth settles whether Figma or the code is right.

Illustrative worked example: words for a quoting app

Everything here is invented. Bramblequote is a fictional startup that sells quoting and invoicing software to small landscaping firms. Mara Lindqvist is the founder, Theo Okafor is the agency’s product designer and Dana Whitlock leads engineering. The engagement runs 10 weeks.

In week 1, support transcripts from a pilot customer say “job” and “quote.” The founder’s deck says “project” and “estimate.” The terminology list picks “job” and “quote” because customers use them. In week 3, the wireframes carry real strings. In prototype sessions with five landscapers, everyone understands “Send quote,” and three of the five hesitate at “Publish,” so “Publish” goes.

By week 5, Theo Okafor’s inventory holds 140 strings across 31 screens and states, including 18 error messages and one camera purpose string: “Bramblequote uses the camera to add site photos to a quote.” The card-declined message names the problem, keeps the form filled in and offers another payment method. In week 6, a cloze test on the plan-change explanation averages 52%. Mara Lindqvist cuts the text in half, and a retest with new participants averages 68%.

In week 7, Dana Whitlock’s team loads the strings as keys with context notes, such as quote_send_button with a 20-character limit. A staging review in week 9 finds six hardcoded strings and two toolbar labels that clip when lengthened to twice their size for a planned Spanish version. Both get fixed before release.

Where do these defaults stop working?

Regulated text is outside this guide. Financial disclosures, health claims, consent records and legal terms need counsel, and a style guide does not replace that review. Text generated by AI features changes on every request, so it needs separate rules for tone and limits rather than a string inventory. Full translation, right-to-left layouts and locale formats for dates and currency go well beyond leaving room for expansion.

The sources are platform guidelines, W3C documents and NN/g articles. None measures how much earlier copy work improves a launch, and this guide makes no such claim. On a very small team the founder may be the right drafter, provided the drafting starts at the wireframes.

What can you produce now?

Seven things you can draft before the next design review:

1. A line in the agency proposal naming the drafter, the reviewers and the phase when drafting starts.
2. A one-page voice and terminology list with 15 to 20 entries.
3. The content inventory worksheet, filled in for your core flow.
4. A two-part error template: what happened, what to do now.
5. Purpose strings for every permission the product requests.
6. A cloze test on the longest text a customer has to understand before paying.
7. A key naming convention with context notes and length limits, agreed with engineering.

With those in place, staging review becomes a check of words that already exist, and no one is left writing them during launch week.