Your homepage button says, “Start your website.”
The next screen asks the visitor to create an account. After that, it opens a workspace with a dozen tools and no obvious website task.
This is an illustrative scenario, not a report about CORA’s current onboarding. It exposes a useful design question: does the product continue the job the page offered, or ask the visitor to work out a new one?
Yesterday, we covered how to test whether people understand your homepage. Today, follow the promise through the click.
Write a promise card
Nielsen Norman Group’s link-label guidance recommends labels that describe destinations honestly and set appropriate expectations. A more exciting verb cannot repair a destination that does something else.
Before changing the button, write a small promise card:
Job: what does the visitor want to begin?
Label: what does the button say will happen?
Destination: what opens immediately?
Prerequisite: what must happen before the visitor can start?
First useful output: what can they leave with?
Be specific about the output. “Access to the platform” describes availability. “A saved homepage draft I can review” describes work. Pick an outcome your product actually supports.
Keep one job across three moments
Use this example:
Button: “Start your website.”
First working screen: “Name the website you want to create.”
First useful output: a saved homepage draft the user can review.
The visual describes a hypothetical flow, not a verified CORA feature. It deliberately ends at a reviewable draft, not a live website or a guaranteed business result.
If account creation comes first, say so near the button: “Create an account, then begin your website draft.” After sign-in, return the user to that task. Do not quietly replace it with a general product tour.
If the destination only shows examples, use a label such as “Explore website examples.” If it opens a conversation, say “Discuss your website.” An honest smaller promise beats an ambitious label that the next screen cannot fulfill.
Audit the handoff, not just the button
Walk the path in a clean session using an appropriate test account. Avoid touching real customer records. Check the path a new visitor sees, not the route your existing founder account remembers.
Before the click: can someone tell what opens and whether an account is required?
During sign-in: does the page explain why this step belongs to the task?
After sign-in: does the intended task remain visible and reachable?
At the first output: can the user tell what is saved, what is still a draft, and what requires review?
Record the exact screen where the job changes or becomes unclear. A screenshot and one sentence make a better repair brief than “onboarding needs work.”
For example: “The button offers a website draft, but after registration the page shows an empty dashboard. Add a visible route to start that draft.” This remains a proposed repair until someone verifies the implemented path.
Give your AI assistant the whole path
Do not ask AI to optimize a button in isolation. Give it the page copy, the actual next screens, known prerequisites, and verified product capabilities. Remove personal or confidential details from screenshots.
Try this prompt:
“Audit this button-to-task path. List each expectation the page creates and compare it with what the next screen delivers. Suggest the smallest copy or routing change for each mismatch. Use only the capabilities I supplied. Label anything that needs product work rather than a copy change. Do not invent a conversion improvement.”
A copy change can clarify a sign-up step. It cannot make a missing editor exist. Keep those two kinds of work separate.
Ask what they expect, then watch what they do
Invite a few people with the relevant problem to try the path. Before the click, ask: “What do you expect this to open?” Then let them proceed without coaching.
Afterward, ask: “Where would you begin the task?” and “What do you think you have created or saved?” Keep their words alongside the screen where they said them.
These observations can reveal mismatches. They do not prove a conversion lift. Track actual task starts and completed first outputs separately if you already have suitable measurement; if not, begin with a manual test log. Do not count an account as a finished website.
The CORA connection
Explore CORA’s website-and-workspace direction. A broad workspace can support many jobs while giving a new visitor one concrete place to begin.
This issue proposes a design discipline. It does not claim CORA already preserves every entry path through sign-in, creates the illustrated output, or measures this journey automatically. Verify those behaviors before promising them.
Do it today: choose your primary homepage button. Fill in its promise card, follow the actual path, and fix one mismatch. Change the destination or narrow the promise—whichever the evidence supports.
The button starts a relationship. The next screen needs to keep its word.
— Dravya Bansal
