> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dforms/respondent-experience.md). # What respondents see What a respondent sees when they open your public form: Slides vs one page, screens with several questions, the cover, progress styles, keyboard shortcuts, the Back button, validation errors, spam pro This page walks through the public form from the respondent's side, so you know exactly what your visitors experience before you share a link. Everything here is the live behavior of a published form; the screenshots come from demo forms in the **Slides** and **One page** layouts. *** ## Slides: one screen at a time In the **Slides** layout the respondent sees a card with the form title, a progress indicator and one screen of the form: usually one question and its input, or several questions you grouped on the same screen. Answering moves them to the next screen.

A published Slides form showing the form title, a progress bar and a single choice question with four options — Step 1 of a Slides form: title, progress bar and one question. Tapping an option moves on automatically.

How each input advances on a screen with one question: | Question type | How the respondent continues | | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Single choice**, **Dropdown** | Tapping an option advances automatically. No button needed. | | **Multiple choice** | Pick several, then press **Next** (or **Enter**). | | **Short text**, **Email**, **Phone**, **Website**, **Slider** | Type or slide, then press **Enter** or the button. | | **Long text** | Press the button (Enter adds a new line). | | **Name** | Two inputs on one screen. **Enter** hops from **First name** to **Last name**, then submits the step. | | **Message** | Text with no input; a **Continue** button moves on. | | **Reveal screen** | Plays for a set time and advances by itself. | | **Scheduler** | The respondent picks a time in the embedded calendar; booking counts as the answer. | The button reads **Next**, or **Submit** on the last screen. You can replace both words for the whole form in **Design → Button text** (see [Language & button text](/dforms/design/language-and-button-text.md)). A **Message** keeps its own **Continue** in every language. *** ## Several questions on one screen When you group questions on one screen (see [Several questions on one screen](/dforms/builder/screens.md)), the respondent answers them together on a single card: * Every required question is marked with an asterisk. * There is one button at the bottom. Picking a single choice or dropdown option records the answer but does not move on: the button does. * **Enter** in a one-line field jumps to the next field, and submits the screen from the last one. * When they press the button, every question on the screen is checked at once. Each invalid question shows its own message, the summary **Check the highlighted questions above.** appears above the button, and the cursor moves to the first problem. * A question that depends on an answer on the same screen appears or disappears while the respondent answers.

A published Slides form showing one screen with three questions on a single card and one Next button at the bottom — A screen with three questions and one **Next** button.

*** ## Back button From the second screen on, a **Back** arrow appears in the top-left corner of the card. It returns to the previous screen with the answers still filled in. On the first screen, **Back** returns to the cover screen when the form has one. *** ## Validation errors If the respondent tries to continue without a valid answer, the input is outlined in red and a message appears under it. The form does not move on until the problem is fixed.

An email step with the Back arrow highlighted in the top-left corner and the error This field is required shown under the empty input — The **Back** arrow (top left) and a validation error under the input.

| Message | When it appears | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **This field is required.** | A required question was left empty. | | **Enter a valid email address.** | The Email question got something that is not an email. | | **Please use your work email address.** | **Require work email** is on and the address is from a personal domain (Gmail, Hotmail, Yahoo and similar). | | **Enter a valid phone number.** | The number is too short for the minimum digits or not a real number for the selected country. | | **Enter a valid website address.** | The Website question could not be read as a URL. (Typing `acme.com` is fine: it becomes `https://acme.com` on blur.) | | **Enter a number.** / **Value is too low.** / **Value is too high.** | Slider or numeric input outside its range. | | **Choose one of the available options.** | A choice or dropdown value is not one of the options. | | **Your answer is too short.** / **Your answer is too long.** | A **Long text** answer is under the minimum or over the maximum length you set. A live counter under the box shows the length as they type. | | **Upload a file to continue.** | A required **File upload** question has no file yet. | | **Could not submit. Please try again.** | The final submission did not reach the server. The answers stay on screen so the respondent can retry. | | **Too many attempts from your connection. Wait a moment and try again.** | Too many submissions came from the same connection in a short time. | | **One of your answers is longer than this form allows. Shorten it and try again.** | A **Long text** answer over its maximum length reached the server. | *** ## Attaching a file A **File upload** question shows an upload area reading **Choose a file**, with the accepted types and the size limit on the line below. Respondents click it to pick a file, watch **Uploading 42%**, and end up with the file's name and a **Remove** link. One file per question. A file that breaks a rule never uploads: the message sits under the control with a **Try again** link, and the respondent stays on the question. See [File upload](/dforms/builder/question-types/file-upload.md). *** ## One page: every question on one screen In the **One page** layout the respondent sees all questions at once and one **Submit** button at the bottom. Logic still runs live, so questions appear and disappear as answers change.

A one-page form with the cover rendered as a header (eyebrow, headline, subheadline) and the counter 0 of 3 answered in the top-right corner — A one-page form. The cover becomes a header at the top and the progress reads **0 of 3 answered**.

* **Cover:** when the form has a cover screen, it renders as a hero header at the top (eyebrow, badge, headline, subheadline). There is no **Start** button; the questions follow immediately. * **Progress:** the top bar shows **{answered} of {total} answered** and fills as the respondent answers. * **Submit** validates every question at once. Invalid ones are outlined in red with their own message, the page scrolls to the first problem, and a summary reads **Check the highlighted questions above.**

A one-page form after pressing Submit with empty fields: each field shows This field is required and a summary reads Check the highlighted questions above — Submitting a one-page form with empty required questions: every field gets its own error plus a summary above **Submit**.

*** ## Spam protection check If the form owner turned on [spam protection](/dforms/connect/spam-protection.md), a check sits right above the button that sends the form: above **Submit** on a one-page form, above the last screen's button on a Slides form (or the button of a screen that ends the form early). When the last screen has no button (a single choice or dropdown that advances on tap, or a reveal screen or scheduler at the end), the check runs on the **Submitting…** screen instead. * **Automatic**: most people see nothing. A checkbox appears only when the traffic looks suspicious, with the line *Confirm you’re human to send your answers.* * **Strict**: everyone sees the check before sending. While the check runs, the button reads **Submitting…**. If it does not pass, the answers stay on screen and the respondent reads one of these messages: | Message | When it appears | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | **We couldn’t verify that you’re human. Please try again.** | The check did not pass. | | **This form now checks that you’re human. Refresh the page and submit again.** | The page was opened before the owner turned protection on. | | **We couldn’t complete the security check. Your answers are saved. Please try again.** | The check could not run, for example because it did not load. | *** ## Cover screen In the **Slides** layout, a form with **Show a cover screen** on starts with an intro screen: optional banner, eyebrow, badge, headline, subheadline, a **Start** button (you choose its text), an optional trust line and, if you added client logos, a "trusted by" marquee. The cover is off on new forms; turn it on in **Design → Cover screen**. In the **One page** layout the same content renders as the header shown above. ## Progress styles You choose how progress is shown in **Design → Shape and controls → Progress**: | Style | What the respondent sees | | ----------- | ---------------------------------------------------------------------------- | | **Bar** | A thin bar under the title that fills screen by screen (the default). | | **Dots** | One dot per screen, the current one highlighted. | | **Counter** | The text **Step 2 of 3**, counting screens. | | **Hidden** | Nothing visible (a progress indicator is still announced to screen readers). | Progress is computed over visible screens only: questions hidden by logic or by a hidden-field setting do not count, so the count never jumps unexpectedly. *** ## Reveal screens A **Reveal screen** is a short, timed interstitial: a loader, a headline and a subtitle, playing for the duration you set (2.2 seconds by default) before advancing on its own. Use it to build a pause before a result, a booking step or the ending. In the Slides layout it is a step you drop anywhere in the question list; in the One page layout it plays once after **Submit** when **Reveal screen before results** is on.

A reveal screen with a spinner, the headline Reviewing your answers and the subtitle One moment while we match you with the best next step — The default reveal screen. Headline, subtitle, loader style and duration are all editable.

*** ## Booking step When your form includes a **Scheduler** question (a Calendly event picked from your connected account, or pasted as a link), the respondent sees **Pick a time** and the embedded calendar for that event. Answers from earlier questions (name, email and any mapped fields) are filled in for them. While the calendar loads they see **Loading the calendar…**; if the embed cannot load there is an **Open the scheduling page** link, and you can allow **Skip for now**. Once a time is booked, the form continues, submits, or jumps to a later step depending on the **After booking** setting. Booking details are stored with the submission. *** ## Ending and redirect After the last step (and any reveal or booking), the respondent sees the ending screen: a check mark, a heading and a message. By default they read **Thank you!** and **Your answers were recorded.** (in Spanish on a Spanish form); you can replace them in **Design → When the form ends** and insert answers with `[field]` placeholders (for example `Thanks, [firstname]!`). Outcomes (score ranges) can override the heading, message and redirect for the people who land in them.

The ending screen with a check mark, the heading Thanks, Jane! and the message Your answers were recorded — An ending with a personalized heading. The name comes from the respondent's own answer.

If you set a **Redirect URL**, the respondent is sent there either immediately or after the delay you set in **Show the thank-you first for (ms)**. When the form includes a booking, the redirect only happens after the booking is made, so nobody is pulled away from the calendar. > **💡 Tip:** Refreshing the ending screen does not create a second submission. One submission is kept per form and browser tab. *** ## Inside an embed When the form is embedded in your own page with the **Embed** snippet: * The frame grows and shrinks with the form, so there is never an inner scrollbar. After the last step it shrinks to fit the ending. * When a whole new screen appears (the next Slides screen, the submitting screen, a reveal, the booking step or the ending) and the top of the frame is out of view, your page scrolls it back into view. It never scrolls when the page first loads, and it skips the smooth animation for visitors who ask their device for reduced motion. * A redirect at the end opens the destination in the whole browser tab, not inside the frame. See [Embed on your website](/dforms/share/embed.md). *** ## Mobile Public forms are built mobile-first: one column, large 44 px tap targets, a sticky progress bar and the same keyboard behavior. There is nothing extra to configure. The **Preview** in the editor lets you check any screen on **Mobile**, **Tablet** and **Desktop** before you publish.

The Slides form on a phone screen: title, progress bar and four stacked options — The Slides layout on a phone.

The one-page form on a phone screen with the cover header, the counter 0 of 3 answered and the first questions — The One page layout on a phone: cover header, counter, then every question.

*** ## Language The form's chrome (buttons such as **Next** and **Submit**, error messages, the default reveal and ending copy) appears in English or Spanish: 1. A `?lang=es` or `?lang=en` added to the link wins. 2. Otherwise the form's own language applies (**Design → Language**). 3. When the form is set to **Auto (visitor’s browser)**, the visitor's browser decides: Spanish browsers see Spanish, everyone else sees English. New forms start in the language you use dForms in; forms created before the language setting existed are on **Auto**. Your own question text is shown exactly as you wrote it, so write the questions in the language of your audience. See [Language & button text](/dforms/design/language-and-button-text.md).

The same email step with Spanish chrome: the error Este campo es obligatorio and the button Siguiente — The same form opened with `?lang=es`: the button reads **Siguiente** and the error is in Spanish. The question itself stays as written.

*** ## Prefilled answers and campaign data If the link carries a parameter that matches a field key (for example `?email=ana@acme.com`), that question arrives already filled in; hidden questions are answered silently from the URL. Any `utm_*` parameters are captured separately as campaign data on the submission. See [Hidden fields & URL prefill](/dforms/builder/hidden-fields-and-url-prefill.md). ## Privacy A public form makes no third-party requests unless you add tracking IDs in **Connect → Tracking & pixels**, add a **Scheduler** (it loads Calendly) or turn on spam protection (it loads Cloudflare Turnstile once the respondent starts, and sends the visitor's IP address to Cloudflare to run the check). Each submission stores the answers, score, timestamps and UTMs, plus the page the form was answered on (its address and title; your page when the form is embedded). When a webhook or the HubSpot integration on the form can use it, the submission also keeps that page's HubSpot visitor cookie, if the page runs your HubSpot tracking code. Submissions do not store the IP address, device or location. See [Landing page & HubSpot attribution](/dforms/connect/hubspot/attribution.md). ## No resume after closing the tab A respondent's session lives in the browser tab. Refreshing the page keeps the same session (a partial submission is updated in place rather than duplicated), but the typed answers are not restored: the form starts again from the first step. Closing the tab and opening the link later is a brand new session. Once a submission is confirmed, the next load of the form in the same tab also starts fresh: a second person at a shared computer gets a response of their own, with its own emails, webhooks and CRM delivery. If you want to keep what people typed before they finish, add a **Partial submit point** so the answers are saved as they go. ## What's next * [Several questions on one screen](/dforms/builder/screens.md) * [Cover screen & banner](/dforms/design/cover-screen-and-banner.md) * [Reveal screens](/dforms/logic/reveal-screens.md) and [Ending screen](/dforms/logic/ending-screen.md) * [Scheduler step & Calendly](/dforms/connect/scheduler-and-calendly.md) * [Spam protection (captcha)](/dforms/connect/spam-protection.md) * [Partial submissions](/dforms/builder/partial-submissions.md) * [One-page layout](/dforms/builder/one-page-layout.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dapta.ai/dforms/respondent-experience.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.