Product
Writing for product
Tone, jargon rules, and how we talk about E-FACTS to execs and shoppers
Writing for product
Words are part of the product. Prefer clarity over cleverness.
Audiences
| Audience | Tone | Avoid |
|---|---|---|
| Exec / founder | Short, outcome-first, one metric | Implementation digressions |
| Shopper (in-app) | Plain, calm, actionable | Internal codenames, API talk |
| Retail partner | Precise, integration-aware | Hype without contracts |
| Engineers (specs) | Explicit flows + data | Vague “delight” |
Company voice
- Accurate — do not claim eco impact you cannot source.
- Direct — lead with the job (“Find your receipt”), not the stack.
- Respectful of money — currency formatting is a trust signal (
tabular-nums). - Human — returns and warranties are stressful; copy should reduce anxiety.
Jargon rules
| Instead of… | Prefer… |
|---|---|
| “Leverage our POS ingestion pipeline” | “Your store receipt shows up in the app” |
| “UCI bind orchestration” | “Link your receipt ID” (then explain what you need) |
| “Omnichannel wallet synergies” | Say nothing — rewrite the sentence |
Internal docs may use precise terms (UCI, JWT, snake_case) when the audience is engineering — still define them once.
UI copy checklist
- Verb-first buttons (“Save receipt”, not “Receipt submission”)
- Error states say what happened and what to do next
- Empty states teach the next action
- Eco / ESG strings cite a real field or are removed
Docs on this site
- Product section: company-readable, link out for code depth.
- Engineering section: deep enough for implementers; still skimmable at the top.
- Never paste secrets, tokens, or production credentials into MDX.