Insights
Write your homepage promise down, then check that onboarding, empty states, errors and the first email repeat it in the same words and voice. Write your homepage promise down as one sentence.
Write your homepage promise down as one sentence. Then check that the welcome screen, the first task, the empty states, the error messages and the first email each repeat that promise, call things by the same names and speak in the same voice; only the tone should shift with the user's situation. Where the first session cannot deliver what the website promised, change the step or change the claim, because no amount of copy covers that gap.
Why the product stops sounding like the website
In the second episode of Beyond the Interface, the Tcules podcast, Jatin Leuva put the question to Alex Napier Holland, a conversion copywriter and former salesperson. Messaging, Jatin argued, has to stay at the centre "not just on your … advertisements and on your landing pages but also during the onboarding and later on when the customer is actually experiencing the product".
Alex, who writes landing pages and homepages, answered from his own work: "I engage with people in UX, but the relationship between people who are handling conversion and UX is pretty weak. … there is still a huge amount of disconnect in the industry when it comes to the tone of voice and … the experience and the values communicated during a purchase process and then the actual product that you use afterwards." He went on: "I honestly don't get a lot of requests for me to engage with people inside the company to align the product with the actual purchase journey."
That is the mechanism worth taking seriously. In the set-up Alex describes, the homepage is written by someone whose job ends at the sign-up button. The welcome screen, the empty project and the "Something went wrong" message are written by whoever builds each screen. Nobody decides that the two should sound different; nobody owns making them the same. The drift is organisational before it is a writing problem.
Why it costs you in the first session is better explained by research than by taste. Anol Bhattacherjee's expectation-confirmation model (MIS Quarterly, 2001), tested in a field survey of online banking users, found that people's intention to keep using a system depended on their satisfaction and on how useful they found it, and that satisfaction depended on how far their earlier use had confirmed what they expected. The study did not measure websites or onboarding copy. The inference is ours: your website is one of the places a new user forms the expectation, and the first session is where it is confirmed or not. To take a hypothetical case: a homepage that promises setup in minutes, followed by a long form before anything works, has disconfirmed its own promise before the user has done anything.
What has to stay the same, and what should change
Three product companies that publish their content guidelines draw the same split between voice and tone. Mailchimp's content style guide puts it simply: "You have the same voice all the time, but your tone changes," and tone follows the reader's emotional state. Shopify tells app builders to keep one voice "consistent everywhere in your app" and to adjust tone, because "an error message calls for a more direct tone than an onboarding tip". Atlassian's design system asks writers to "tone down the boldness by being more prescriptive" for new users, trial users and anyone meeting a new concept.
Building on those guides, our recommendation is to hold four things constant from homepage to product, and let one vary:
- The promise. The outcome the homepage headline offers should be the outcome the first session moves the user towards.
- The names of things. If the site sells "workflows", the product should not ask the user to "create an automation".
- The voice. The handful of traits your brand sounds like (plain, warm, direct, whatever yours are) apply to a tooltip as much as to a hero.
- The reason the product exists. A new user should be able to see it again on the first screen after sign-up.
- What varies is tone. A welcome screen can carry some of the homepage's energy; an error message should drop it and get to the fix.
The GOV.UK Design System's error message guidance shows how far "the same" should go. It asks for the same message next to the field and in the error summary so they "look, sound and mean the same", and suggests reading a message out loud to hear whether it sounds like something you would say. That is a useful test for every surface in the audit below.
One promise, traced through a product
Illustrative. Described from Todoist's public homepage and help centre as published on 14 October 2026; we have not reviewed the signed-in product, and Todoist is not a Tcules client.
Todoist's homepage leads with "Clarity, finally." Its first section is headed "Clear your mind", with the line "Capture tasks at the speed of thought" and a promise of "easy-flowing, natural language".
Todoist's own getting-started guide shows the same promise carried into the product in three places:
| Surface | What the public guide says | Same promise? |
|---|---|---|
| Inbox | "the home for tasks without projects (yet), and the perfect way to get things out of your head" | Yes: "clear your mind" becomes a named place to put things |
| First task field | For new users, the empty field shows example tasks such as "Read history chapter 5 in 10 days" so they can see how Todoist understands natural language; the examples stop after 15 completed tasks | Yes: the natural-language claim is taught inside the empty field, then retires |
| Today view | Shows "all the tasks scheduled for today in all of your projects" | Yes: "clarity" is delivered as one list for today |
Two things are worth copying. The product repeats the homepage's own idea in plain words ("get things out of your head") rather than inventing new ones. And the empty state of the very first input does the homepage's job: it shows the claim working instead of restating it, then gets out of the way.
The trace also shows where a public review stops. The guide's first step is "Start with a project", while the homepage leads with capture; whether the signed-in first run starts with capturing or with setting up a project is exactly the question the audit would answer inside the product. Error messages and the first email are not described on the homepage or in the guide.
The audit: five surfaces against one promise
Do this with a fresh account, on the device most of your sign-ups use, and put everything in one document side by side.
- Write the reference. Copy your homepage headline and sub-headline, then write the promise as one sentence a customer would say ("I can stop chasing invoices by email"). Alex made the related point later in the episode: in a crowded market, buyers line similar tools up side by side looking for a reason to close a tab, and "there are too many people who are still having these drawn out processes where it takes the entire page to explain why their product exists when they should do that in the headline". If you cannot write the sentence from your own homepage, fix that first; the product has nothing to repeat.
- List your nouns. Note the five or six words the homepage uses for the things a customer works with (projects, clients, workflows, reports).
- Note your voice in three or four words, from your style guide if you have one, or from the homepage if you do not.
- Collect each surface below with screenshots, and mark every check as same, drifted or missing.
| Surface | What to capture | Same promise? | Same names? | Same voice, right tone? |
|---|---|---|---|---|
| Welcome screen (first screen after sign-up) | Heading, body, primary button | Does it point at the outcome in your promise sentence, or at setup? | Are the objects called what the site calls them? | Recognisably the homepage voice, a little more instructive |
| First task | The first input, its label, placeholder and button | Does completing it move the user towards the promised outcome? | Do labels use the site's nouns, not internal or database names? | Plain and prescriptive; no marketing adjectives |
| Empty states | Every list or dashboard a new account sees empty | Does each one say why it is empty and what to do next, in terms of the promise? | Same nouns as the site and the first task? | Encouraging, short; one action |
| Error messages | Trigger the three most likely: wrong format, missing field, failed connection | Does the message help the user back to the task the promise is about? | Does it name the thing the user was working on? | Same voice, direct tone; says what happened and how to fix it |
| First email | The welcome or first onboarding email | Does it restate the promise and the next step towards it? | Same nouns as site and product? | Same voice as the homepage; one next step |
Atlassian's empty state guidance gives a reasonable floor for that row: give the reason for the empty state and where to go next, in one or two sentences.
The pattern of marks matters more than any single one. A row of missing under "same promise" points to a product question. A column of drifted under "same names" points to a vocabulary nobody has decided. Drifted voice across every product surface suggests that no one writes product copy deliberately.
What to change when a surface drifts
The promise is missing from the first session. If the product does deliver it, but later, move the step that delivers it earlier, or have the welcome screen say plainly what the user will have when they finish setup. If the product does not deliver it, change the website's claim. Onboarding copy cannot make up for a promise the product does not keep, and, on our reading of the expectation-confirmation research above, trying to only sets up another expectation the first session will not confirm.
The names differ. Pick one word per thing and use it on the site, in the product and in email. Choose the customer's word, not the team's. Alex warned about websites that group features by the categories developers use, which "reflect the way that a developer views the architecture of a product and that could have absolutely nothing to do with how a customer sees it"; the same risk applies to labels inside the product. To find the customer's word, ask the people who hear it daily. Of all the teams he talks to on an enterprise project, Alex said, "customer service is some of the most valuable. They actually know what the customers care about more than anybody and that's a really untapped resource."
The voice differs. Write the three or four voice traits down once, where marketing and product writers both work from them, with one example per surface: a hero line, a welcome heading, an empty state, an error. Then let tone vary by situation, as the guides above describe, rather than by whoever happened to write the screen.
Nobody owns it. In the episode, Jatin said of good copywriters: "you give them all the error messages you give them all the success messages you give them all the growth messages and they will really do phenomenal job". He called the work "a low-hanging fruit" whose problem is that "it doesn't get prioritised". The fix is less about hiring than about assignment: whoever writes the homepage should review the welcome screen, the first task and the first email, and whoever writes product copy should have read the homepage.
Where this sits
This page is about the words. For the structure of onboarding itself, roles, steps and the first moment of value, see SaaS onboarding strategies to increase customer retention. If the audit above turns up more questions than it answers, Who can audit your SaaS onboarding flow? covers who should run a fuller review and what it should hand back. If the homepage promise itself is the weak link, the landing page design guide starts there.
When your team can see new users leaving in the first session but cannot agree why, the Tcules UX Product Audit examines representative workflows, roles, states and implementation evidence to identify what should be fixed, researched, redesigned, modernised or accepted. Its findings can draw on support material and analytics as well as the product itself.
The full conversation with Alex, S1 E02 of Beyond the Interface (each quote above links to its moment in the video), also covers customer research, positioning in crowded markets and how copywriters and designers should work together. More episodes are on the Tcules podcasts page.