The booking widget is the form your website visitors fill out to book with your practice. You design it once in the screen designer, connect what happens after a submission through a workflow, and paste one line of code onto your site. This guide covers the designer itself: how the canvas is laid out, what each part does, and how publishing works so your changes actually reach visitors.
The screen designer has three areas. The canvas in the middle shows the form as a visitor will see it. The left rail holds the blocks you can drag onto the canvas, grouped by what they do. The right rail configures whichever block you have selected, split into a Basic tab for content and behavior and a Style tab for how it looks.
Along the top are the controls that manage the whole screen: the Issues pill that flags anything blocking publish, the Theme dialog for site-wide colors and fonts, and Preview and Publish. A booking form is built from one or more pages, so a visitor can move through steps rather than facing one long form.
Blocks are the pieces a visitor interacts with: text inputs, dropdowns, buttons, headings, and layout pieces that group them. You add a block by dragging it from the left rail onto the canvas, and you reorder blocks by dragging them within a page.
Each block has its own fields in the right rail. A text input has a label and a placeholder and whether it is required. A dropdown has its list of options. A button has its text and, on a multi-page form, which page it advances to. Selecting a block shows exactly what you can change about it, so you rarely need to guess.
The Style tab on each block controls that one block's appearance: spacing, alignment, widths, and colors. The Theme dialog controls the whole form at once: your brand colors, fonts, and the overall look, so every block inherits a consistent style instead of being set one at a time.
Preview opens the form exactly as a visitor will experience it, including moving between pages and filling in fields. Use it before every publish. What looks right in the editor can behave differently when it is interactive, and Preview is where you catch that.
Your work stays in a draft until you publish. Publishing is what copies the current design to the live version that visitors see, so nothing you do in the designer reaches your website until you click Publish.
The Issues pill tells you whether you are ready. It flags problems that would break the form for a visitor, and it blocks publishing until they are resolved. A common one is a form that has no way to submit, so make sure a submit button exists on the last page before you expect Publish to succeed.
The designer decides what a visitor sees and fills out. What happens after they submit, the confirmation emails, the follow-ups, where their browser goes next, is described separately in the booking workflow. The two work together: the form collects the information, and the workflow acts on it.
Once your form is published and your workflow is set, embed the widget on your site with the snippet from the widgets area and send a real test booking through. Watching one submission flow from your website through to the workflow is the fastest way to confirm everything is wired correctly.