wensity/wensity-ui-copy

Wensity UI Copy

Words are part of the design. Vague or inflated copy makes a polished interface feel generic; plain, specific copy makes a plain interface feel trustworthy. The test for every string: does it help someone understand or act?

1. Voice

• Plain words. Write the way a helpful person would say it out loud. "Save changes", not "Persist modifications". "You're out of credits", not "Credit balance depleted".
• The user's words, not the system's. "Notifications", not "Webhook dispatch config". Name things by what people do with them.
• Short. Cut every word that does not change the meaning. Then cut again.
• Sentence case everywhere: headings, buttons, menu items, tabs, labels. "Create new project", not "Create New Project".
• Active voice, addressed to the user. "You don't have access to this project", not "Access to this project is not permitted". When the system failed, say so plainly: "We couldn't save your file", not "The file could not be saved".
• Calm. No exclamation marks except for genuine celebrations, no apologies in errors, no jokes in error states.

2. Words that make copy sound generated

Avoid these. They say nothing a reader can check:

• Verbs: unlock, unleash, elevate, empower, supercharge, revolutionize, transform, streamline, leverage, harness, reimagine, skyrocket.
• Adjectives: seamless, effortless, cutting-edge, next-generation, world-class, robust, powerful, intuitive, innovative, all-in-one.
• Phrases: "In today's fast-paced world", "Take your X to the next level", "Whether you're a X or a Y", "Say goodbye to", "Look no further".
• Shapes: three adjectives in a row ("Fast. Secure. Simple."), middle-dot lists (Design · Build · Ship), and em dashes anywhere in the product's text, including the page <title>, meta description and alt text. Use a colon, a comma or two sentences: "Ledgerline: invoices in any currency".

Replace each with a concrete fact: what it does, how fast, for whom, with what result. "Cuts a 40-minute report to 2 minutes" beats "Supercharge your workflow".

3. Headings

• A heading says the point, not the topic. "Invoices get paid 9 days faster" beats "Features". "Your workspace is empty" beats "Workspace".
• No eyebrows. Do not put a small uppercase label above a heading ("FEATURES", "PRICING", "HOW IT WORKS"). Write a heading that stands alone.
• Page titles name the page so people know where they are: "Billing", "Team members".

4. Buttons and links

• Start with a verb and name the result: "Create invoice", "Send invite", "Export CSV". Not "Submit", "OK", "Yes", "Click here", "Learn more" alone.
• Match the button to what happens next. If the button says "Publish", the toast says "Published", and the page shows the published state.
• Primary and secondary must be clearly different actions: "Delete project" and "Cancel", not "Yes" and "No".
• One to three words is ideal. A CTA can go to five if it adds a concrete benefit ("Start free, no card").
• Link text makes sense alone (screen readers list links out of context): "Read the API guide", not "here".
• Destructive actions name the thing: "Delete 3 files", "Remove Sam from team".

5. Forms

• Labels above fields, always visible. Placeholder text is not a label; it disappears when typing starts.
• Placeholders show format, not instructions: [email protected], MM / YY. Leave them out when the label is enough.
• Helper text under the field for rules people need before typing: "At least 12 characters".
• Mark optional fields, not required ones, when most fields are required: "Company (optional)".
• Validate on blur or submit, not on every keystroke. Show the error next to the field it belongs to.

6. Errors

Every error answers two questions: what happened, and what to do now.

Weak	Better
Invalid input	Enter a date after today
Something went wrong	We couldn't reach the server. Check your connection and try again.
Error 403	You don't have access to this project. Ask an owner to invite you.
Upload failed	This file is 24 MB. The limit is 10 MB.
Payment declined	Your card was declined. Try another card or contact your bank.

• Never blame the user ("You entered an invalid email"). Describe the fix ("Enter an email like [email protected]").
• Keep codes and stack traces out of the message. Put a reference ID at the end if support needs one.
• Keep what the user typed. Never clear a form because one field failed.

7. Empty states

An empty state is the first thing a new user sees. Treat it as onboarding:

1. Say what will appear here: "Invoices you send will show up here."
2. Give the one action that fills it: a primary button, "Create invoice".
3. Optional: a link to import, a template, or a short guide.

For "no results" empties, say what was searched and how to widen it: "No results for 'invioce'. Check the spelling or clear filters."

8. Loading, success and toasts

• Loading: say what is happening when it takes more than a second: "Generating report…". Use the ellipsis character.
• Success toasts: past tense of the action, plus the object: "Invite sent to [email protected]", "Project deleted. Undo".
• Offer Undo instead of a confirmation dialog for reversible actions. Ask for confirmation only when the action cannot be undone.
• Confirmation dialogs: the title asks the real question ("Delete 'Q3 report'?"), the body states the consequence ("This removes it for everyone. You can't undo this."), the buttons name the action ("Delete report" / "Cancel").

9. Numbers, dates and units

• Use numerals: "3 files", not "three files".
• Format with the user's locale: Intl.NumberFormat and Intl.DateTimeFormat (or toLocaleString) instead of hand-built strings.
• Relative time for recent events ("2 min ago"), absolute dates for older ones ("Mar 4"), and the full timestamp in a tooltip.
• Pluralize correctly: "1 file", "2 files", "0 files". Use Intl.PluralRules or a helper, never "file(s)".
• Keep numbers and units together with a non-breaking space (10 MB in HTML, "10\u00A0MB" in JavaScript) so they never wrap apart.

10. Realistic placeholder content

When building a design without real content, write content that looks real:

• Specific names and data: "Maya Chen, Product designer at Northwind", "$12,480.00", "Invoice INV-2041". Not "John Doe", "$XX", "Lorem ipsum".
• Realistic lengths, including some long ones, so the layout is tested: a 40-character name, a 3-line description next to a 1-line one.
• Never invent proof. No made-up customer logos, star ratings, user counts or testimonials presented as real. Use marked placeholders ([Customer quote], [Logo]) or ask the user for the real ones.
• Match the product's world. A dev tool's sample data is repos and deploys; a clinic app's is appointments and patients.

11. Accessibility in copy

• Every icon-only button gets an accessible name: aria-label="Close dialog".
• Alt text describes what an image shows when it carries information ("Bar chart: revenue up 24% since January"). Decorative images get alt="".
• Do not rely on color words alone ("click the green button").
• Expand abbreviations the first time unless the audience uses them daily.

12. Check before you finish

• No filler words from section 2, no three-adjective taglines, no em dashes in interface strings.
• Every heading states a point; no eyebrows.
• Every button starts with a verb and names its result.
• Every error says what happened and what to do.
• Every empty state explains itself and offers the next action.
• Sentence case throughout.
• Sample content is specific, varied in length, and contains no invented proof.
• Icon-only controls and meaningful images have accessible text.