Get started and the navigation action lead to the same form. The route was checked live on 4 October.
Website · Observed01 / The question
Duna’s demo request should explain the next step
Duna’s homepage says “Get started.” The form says the team will contact me, but its button says “Schedule a demo.” I would make those describe the same next step.
Duna helps companies check the businesses they work with. Its product handles questions that adapt to the business being checked. A sales conversation can be useful here: buyers may need to discuss their policies and integrations. I would keep that step and make it clearer. [1, 2]
The decision I would start with
Check what happens after submission, then use one accurate action name across the homepage and form. If a person follows up, say “Request a demo.” If a calendar opens next, say so.
I’m considering a compliance lead deciding whether to speak to Duna. I would start with the website team and whoever manages the sales handoff.
Review: homepage to demo request. The post-submit step still needs checking.
02 / The evidence
Is this a request, or am I choosing a time?
The explanation describes a later reply. The button sounds like booking. I would check which happens next before choosing the final wording. [3]
Checked live · 4 October 2026
I followed Get started from the homepage to this form and confirmed the Schedule a demo button. Google search was selected before entry. Name and email were required; phone and source were optional.
03 / The journey
Keep the buyer’s question visible through the handoff
The buyer carries a question from the website into the sales conversation. This map shows the three captured steps and the two handoffs I would check next.
The form explains that the team will reply. Its button says Schedule a demo.
Website · ObservedThe supplied filled-form capture shows Google search still selected. Field placeholders disappear after entry.
Website · Captured in original walkthroughNot observed. Check successful receipt, validation, duplicate clicks and whether scheduling opens.
Website · Not observedNot observed. Trace the saved request into the reply and the eventual meeting.
Email / meeting · Not observedBlue: website. Amber: email or meeting. Each card states whether that step was observed.
04 / The first change
Tell me what happens when I send this
If the team replies first, I would use Request a demo on the homepage, in the navigation and on the form. If a calendar opens next, I would explain that instead.
Proposed homepage action
Keep the hero. Use the same wording in the navigation.
Request a demo
Leave your details. The Duna team will contact you to arrange a time.
Name *
Business email *
Phone number (optional)
How did you hear about us? (optional)
Select one
How can we help? (optional)
Try the form prototype ↗ · Component and event notes ↗
Proposed flow: the team contacts the buyer to arrange a time. Confirm that handoff before testing.
Test the wording first, keeping the same fields and follow-up process. The prototype also explores persistent labels, an unanswered source option and retry; those are separate improvements.
I would keep the open message field. Before adding topic choices or company lookup, I would check what buyers already write and what sales needs.
05 / Design beyond the happy path
A clear request also needs a clear failure state
The first change is small. These supporting states show how I would carry the same clear next step through validation, saving and recovery.
| Moment | What the person should see | What needs to hold |
|---|---|---|
| Missing or invalid input | A specific message beside the field; their other answers stay. | Visible labels, linked errors and focus on the first invalid field. |
| Saving | One pending action, with the button temporarily disabled. | Do not show success before the server confirms receipt. |
| Request not saved | A plain explanation and a retry action. | Keep values. Use a request key so a retry can be deduplicated. |
| Saved; reply will follow | Receipt confirmation and the actual next step. | A saved request and a sent email are different events. |
| Saved; calendar unavailable | The request is safe; scheduling could not load. | Offer the real fallback. Do not ask the buyer to resubmit everything. |
I would define one shared field component with a label, help text and error slot. The request button and confirmation panel should read the same flow setting: team follow-up or immediate scheduling. That reduces the chance of copy drifting between screens.
For the source field, start with “Select one.” Store an unanswered value separately from Google. Keep what the buyer says separate from campaign data. Before changing reporting, check which field the sales system actually treats as its source.
One field component, three states
Default: visible label and optional help. Error: keep the answer and explain what to fix. Pending: preserve the form while the request is saved.
06 / How to learn
Measure whether the request leads to a useful conversation
First, ask a few relevant buyers what they expect after pressing the button. Compare their answer with the actual flow. If they already understand it, the copy change may not be the most useful next work.
If the team has enough traffic, compare the current wording with one aligned version. Keep each visitor in the same version on return visits. Leave acquisition, fields and sales follow-up unchanged.
| Measure | Numerator / denominator | Proposed window |
|---|---|---|
| Next-step understanding | Correct descriptions of the actual next step / participants shown the form | Before submission |
| Request completion | Unique visitors with a saved request / eligible unique form visitors | 7 days from first exposure |
| Useful continuation | Unique visitors reaching an attended, relevant meeting with an agreed next step / eligible unique form visitors | 30 days from first exposure |
| Handoff quality | Qualified requests reaching that meeting / all qualified requests | 30 days from request receipt |
Agree qualification before the test. Exclude staff, bots and test traffic. Count people once and compare only cohorts whose observation window has finished. The team should adjust these windows to its sales cycle; current volume and baselines are unknown.
What would make me change direction
Stop or revise if the wording creates false booking expectations, irrelevant requests increase, or sales needs more work to reach the same useful meeting. More submissions alone would not be enough.
The website owner can manage exposure and form events. Sales operations can define qualification and record the meeting outcome. For the separate source-field fix, test that an untouched selection remains unanswered in storage. For persistent labels and recovery, check completion with keyboard use and a simulated failure.
07 / Sources and limits
What this review can support
On 4 October 2026, I rechecked the homepage hero, followed Get started to the contact form and confirmed its Schedule a demo button. The check used Chrome on an existing browser profile. The screenshots are from the original walkthrough; their capture dates were not recorded.
- 1 · HomepageAction labels and the public evaluation route.
- 2 · OnboardDuna’s descriptions of prefill, validation and adaptive journeys.
- 3 · Contact formCurrent field requirements, displayed source and next-step wording.
Not checked: submission, scheduling, sales replies, CRM storage, internal onboarding or conversion data. The source selection was not tested on a clean browser profile. These limits mean the wording is a proposal to discuss, rather than a demonstrated conversion problem.
The form and recovery states are design concepts. They have not been shipped or tested with Duna’s customers. The prototype runs locally without sending requests.
The first conversation I would have
What happens after a buyer sends this form? Once that is clear, I would match the homepage, form and confirmation to that next step.