Product Prototypes
Publishing · Landing Pages

Subscribe Form Field Management

Creators can already add, reorder, and delete fields on their subscribe forms — but today's interface buries these controls in a sidebar panel. The form field list itself gives no direct affordances: no drag handle, no inline add, no delete. Every operation requires selecting a field first and navigating to a remote panel.

This prototype explores moving field management controls directly onto the field rows via hover interactions. The goal is to validate optimal placement for the drag handle, the add-field affordance, and the delete trigger — and to decide whether delete belongs in this layer or stays panel-only.

Open prototype
What's in this prototype
↕️
Drag to reorder
Hovering a field row reveals a six-dot grip handle on the left edge. Grab it and drag to reorder. A ghost origin marker stays in place while dragging, and an insertion line shows exactly where the field will land. Drop anywhere in the list.
➕
Insert field between rows
Hover into the gap between any two fields (or below the last) to reveal an in-place "+ Add field" affordance. Clicking inserts a new field at that exact position — no post-add reorder needed. A type picker (First name, Last name, Phone, Custom text) appears inline.
🗑️
Delete from the row
A trash icon appears on the right edge of any deletable field on hover. Clicking removes the field immediately with a collapse animation. An undo toast gives a 5-second window to recover. The email field is locked — hovering it shows a tooltip explaining it's required.
🔒
Required field lock
The email address field is always present and cannot be deleted or moved. In this prototype it renders with a lock icon in place of the drag handle and delete controls, reinforcing that the constraint is intentional — not a missing affordance.
✏️
Inline field type picker
After triggering "+ Add field", a simple type picker appears inline below the insertion point. Four options cover the common cases. Selecting a type commits the field and auto-focuses the label for immediate editing. Pressing Escape or clicking away discards it.
Design & product decisions
Hover-reveal controls over always-visible
The current sidebar panel keeps all controls permanently visible but requires navigating away from the list to act. Always-visible inline controls (buttons on every row) would work but clutter short forms and compete visually with field labels.
This prototype bets on hover-reveal: controls appear on row hover, keeping the list clean at rest. This is the established convention across Typeform, Webflow, Notion, and Linear. The risk is discoverability — creators who don't know to hover will never find the controls. The hypothesis being tested: creators who are actively in edit mode (already focused on the field list) will hover naturally, so the controls don't need to announce themselves. If engineering feedback suggests this feels too hidden, the fallback is a persistent row of muted icon buttons that become full-opacity on hover — discoverable at rest, not visually dominant.
Typeform form builder · Webflow Designer · Atlassian DS
In-place add between rows, not append-only
Kit's current form builder appends new fields to the bottom, requiring the creator to then drag them to the right position — two steps for every field in a non-last position. This is an assumed friction point based on the current interaction model; whether creators frequently need mid-list insertion (vs. always building top-to-bottom) is a hypothesis, not confirmed by session data or support tickets. This prototype tests that assumption.
This prototype uses in-place insertion: the "+ Add field" affordance appears between existing rows, inserting at that exact index. The tradeoff is a smaller hover target between rows — the interaction expands the hit area on hover to ~24px to compensate. Webflow and Squarespace both ship this pattern. If engineering feedback or creator testing shows the between-row target is too fiddly, a persistent "+ Add field" button below the list is the fallback — simpler to implement and still eliminates the sidebar navigation step.
Webflow Designer · Squarespace form block · Assumed friction — needs validation
Immediate delete with undo toast, not a confirmation modal
Confirmation modals ("Are you sure?") add friction that compounds across a session. A creator editing a form multiple times pays the confirmation cost every time, even for fields they just added themselves.
This prototype uses immediate delete with a 5-second undo toast — the same pattern Mailchimp, Notion, and Gmail use. For standard fields (label + required toggle), accidental deletion is easily recovered from. A confirmation dialog is reserved for fields that have collected live subscriber data, where deletion is genuinely irreversible.
Mailchimp audience field manager · Google Material Design · Product scope decision (live-data confirmation is a fast-follow, not in this prototype)
Delete is in scope — placed on hover, not gated to the panel
The current editor requires selecting a field and navigating to the sidebar to delete it. Whether delete should also be accessible directly from the field row (in this hover layer) is an open question for this prototype.
This prototype includes inline delete on hover to make the interaction testable. Keeping delete panel-only is a valid alternative — it's less discoverable but reduces accidental deletions. This prototype is explicitly testing whether inline delete feels appropriate at this layer, or creates anxiety about mis-clicks.
Open question · Prototype hypothesis
Questions for the team
Things to explore and validate