Form Optimization

form_strategy_questions:

  what_action:
    examples: "Lead capture, signup, purchase, application, contact, feedback"

  what_data_essential:
    rule: "Only ask what you actually need to act"
    test: "Can the user be served without this field?"

  what_data_nice_to_have:
    decision: "Worth lower completion for richer data?"
    pattern: "Often: collect minimum first; ask more later"

  who_responds:
    requirement: "Internal process must be ready"
    rule: "Don't capture leads you can't respond to"

  response_time_promise:
    define: "How fast will user hear back?"
    display: "Tell them on form"

field_count_strategy:

  minimum_field_approach:
    fields: "Email only, sometimes name"
    pros: "Highest completion rate"
    cons: "Lower lead quality; more sales effort to qualify"
    use_when: "Top-of-funnel; building list"

  moderate_field_approach:
    fields: "Name, email, company, brief context"
    pros: "Balance of completion and quality"
    cons: "Some abandonment from extra fields"
    use_when: "Most B2B and service business contexts"

  rich_field_approach:
    fields: "10+ fields with detailed qualification"
    pros: "Highly qualified leads"
    cons: "Significant abandonment"
    use_when: "High-value engagements where qualification matters"

  progressive_profiling:
    pattern: "Collect minimum first; ask more in subsequent interactions"
    benefit: "Best of both worlds over time"
    requires: "Marketing automation supporting it"

form_engagement_levels:

  contact_form:
    intent: "User actively wants response"
    completion_rate: "Higher (motivated users)"
    fields: "Can ask more"

  lead_magnet_download:
    intent: "User wants resource; trade contact info"
    completion_rate: "Moderate"
    fields: "Minimum (just for delivery)"

  newsletter_signup:
    intent: "User wants ongoing value"
    completion_rate: "Variable"
    fields: "Email only typical"

  passive_lead_capture:
    intent: "User has not actively decided to engage"
    completion_rate: "Lowest"
    fields: "Absolute minimum"

label_design:

  label_above_field:
    standard: "Most accessible, mobile-friendly"
    pattern: |
      <label for="email">Email Address</label>
      <input type="email" id="email" name="email">
    benefit: "Clear association; doesn't disappear when typing"

  label_left_of_field:
    when: "Desktop forms with consistent label width"
    challenge: "Mobile responsive complexity"

  floating_label:
    pattern: "Label inside field, animates up when typed"
    pros: "Compact; modern feel"
    cons: "Accessibility challenges; small text when raised"

  placeholder_as_label:
    avoid: "Reduces accessibility; disappears when typing"
    rule: "Never use placeholder as only label"

  helper_text:
    purpose: "Additional clarification"
    pattern: |
      <label for="phone">Phone Number</label>
      <input type="tel" id="phone" name="phone" 
             aria-describedby="phone-help">
      <span id="phone-help">For urgent inquiries only</span>

<!-- Email — triggers email keyboard on mobile -->
<input type="email" id="email" name="email" autocomplete="email">

<!-- Phone — triggers numeric keyboard on mobile -->
<input type="tel" id="phone" name="phone" autocomplete="tel">

<!-- Number — triggers numeric keyboard -->
<input type="number" id="age" name="age" min="0" max="120">

<!-- Date — triggers date picker -->
<input type="date" id="birthdate" name="birthdate">

<!-- URL — triggers URL keyboard -->
<input type="url" id="website" name="website" autocomplete="url">

<!-- Search — adds clear button on some browsers -->
<input type="search" id="search" name="search">

<!-- Password — masks input -->
<input type="password" id="password" name="password" autocomplete="new-password">

<input type="text" name="name" autocomplete="name">
<input type="email" name="email" autocomplete="email">
<input type="tel" name="phone" autocomplete="tel">
<input type="text" name="address" autocomplete="street-address">
<input type="text" name="city" autocomplete="address-level2">
<input type="text" name="state" autocomplete="address-level1">
<input type="text" name="zip" autocomplete="postal-code">
<input type="text" name="country" autocomplete="country">
<input type="text" name="cc-number" autocomplete="cc-number">

required_field_marking:

  visual_indicator:
    standard: "Asterisk (*) next to required field labels"
    color: "Often red but with text fallback"

  semantic_marking:
    html: 'required attribute on input'
    aria: 'aria-required="true" for screen reader emphasis'
    example: |
      <label for="email">Email <span aria-hidden="true">*</span><span class="sr-only">required</span></label>
      <input type="email" id="email" name="email" required aria-required="true">

  preference:
    if_most_fields_required: "Mark optional fields ('optional')"
    if_most_optional: "Mark required fields (*)"
    rule: "Whichever has fewer marks"

<!-- BAD: placeholder as label -->
<input type="email" placeholder="Email Address">

<!-- GOOD: label + helpful placeholder -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" placeholder="you@example.com">

<!-- GOOD: format example -->
<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone" placeholder="(555) 123-4567">

validation_timing:

  on_submit_only:
    pattern: "Errors shown only when user submits"
    cons: "User may have to scroll back; multiple errors at once feels worse"
    when: "Acceptable for very short forms"

  on_blur:
    pattern: "Validate field when user moves to next"
    pros: "Catches errors quickly without interrupting typing"
    standard: "Most common modern pattern"

  on_input:
    pattern: "Validate as user types"
    pros: "Immediate feedback"
    cons: "Can be annoying if error shows too early"
    use_for: "Password strength, character counts"

  hybrid_approach:
    pattern: "On blur for validity; on input for some checks"
    standard: "Most polished modern pattern"

error_message_design:

  specificity:
    weak: "Error"
    strong: "Please enter a valid email address (you@example.com)"

  location:
    pattern: "Adjacent to the field with the error"
    avoid: "All errors at top of form (forces user to scroll)"

  visual_treatment:
    - Red color (with non-color indicator like icon)
    - Border on offending field
    - Icon
    - Text explanation

  semantic_treatment:
    - aria-invalid="true" on field
    - aria-describedby pointing to error message
    - role="alert" on error message for screen readers

  example: |
    <label for="email">Email</label>
    <input type="email" id="email" name="email" 
           aria-invalid="true" 
           aria-describedby="email-error">
    <span id="email-error" role="alert">
      Please enter a valid email address (you@example.com)
    </span>

success_feedback:

  inline_success:
    pattern: "Green checkmark when field validates"
    benefit: "Confirms correct input"

  submission_success:
    requirements:
      - Clear confirmation message
      - What happens next
      - Reference number if applicable
      - Email confirmation as backup
      - Thank you for taking time

  thank_you_page:
    benefits:
      - Tracking conversion in GA4
      - Opportunity for next step (related content, follow social, etc.)
      - Reset expectations and next steps

  no_redirect_pattern:
    when: "Lightweight forms, popups"
    requirement: "Replace form with success message in same location"
    accessibility: "Move focus to success message; announce to screen readers"

multi_step_decision:

  use_multi_step_when:
    - 8+ fields total
    - Distinct logical groupings exist
    - Some users need only some sections
    - Conditional logic required

  use_single_page_when:
    - Few fields (under 8)
    - Users want to see total scope upfront
    - Quick completion expected
    - SEO benefit from form being on landing page

multi_step_form_principles:

  progress_indication:
    requirement: "Show step X of Y"
    pattern: "Progress bar with step labels"
    benefit: "Reduces uncertainty about scope"

  navigation:
    - Allow back navigation
    - Preserve data when going back
    - Clear next/back buttons

  step_groupings:
    pattern: "Logically related fields per step"
    examples:
      - "Contact information"
      - "Project details"
      - "Budget and timeline"

  start_with_easy:
    pattern: "Easy questions first; harder later"
    psychology: "Sunk cost; commitment increases as steps complete"

  validation_per_step:
    requirement: "Validate before allowing next step"
    benefit: "Catch errors immediately; don't lose progress"

<form class="multi-step-form">
  <!-- Progress indicator -->
  <div class="progress" role="progressbar" 
       aria-valuemin="0" aria-valuemax="3" aria-valuenow="1">
    <span class="step active" aria-current="step">1. Contact Info</span>
    <span class="step">2. Project Details</span>
    <span class="step">3. Confirmation</span>
  </div>

  <!-- Step 1 -->
  <fieldset class="step-1">
    <legend>Contact Information</legend>
    <!-- Fields -->
    <button type="button" class="next-step">Continue →</button>
  </fieldset>

  <!-- Step 2 -->
  <fieldset class="step-2" hidden>
    <legend>Project Details</legend>
    <!-- Fields -->
    <button type="button" class="prev-step">← Back</button>
    <button type="button" class="next-step">Continue →</button>
  </fieldset>

  <!-- Step 3 -->
  <fieldset class="step-3" hidden>
    <legend>Review and Submit</legend>
    <!-- Review fields -->
    <button type="button" class="prev-step">← Back</button>
    <button type="submit">Submit</button>
  </fieldset>
</form>

trust_at_submit:

  privacy_assurance:
    pattern: "Brief privacy statement near submit"
    examples:
      - "We never share your information with third parties."
      - "Your information is secure (HTTPS encrypted)."
      - "View our privacy policy."

  response_time_commitment:
    pattern: "Set expectation for response"
    example: "We typically respond within 4 hours during business days."

  what_happens_next:
    pattern: "Tell them the next step"
    example: "After submitting, we'll email you within 24 hours to schedule a call."

  alternative_contact:
    pattern: "Provide non-form alternatives"
    example: "Prefer to call? Reach us at 505-512-3662."

  recent_social_proof:
    pattern: "Brief reminder of trustworthiness"
    example: "Trusted by 130+ small businesses since 2020."

submit_button:

  text:
    weak: "Submit"
    weak: "Send"
    strong: "Get My Free Quote"
    strong: "Schedule My Consultation"
    strong: "Send Message"
    pattern: "Specific to action and benefit"

  visual:
    requirement: "Distinguishable from other elements"
    typically: "Brand color, prominent size"
    state: "Disabled state when validation incomplete"

  loading_state:
    pattern: "After click, show loading state"
    benefit: "Prevents double-submission"
    example: 'Button text changes to "Sending..." with spinner'

  position:
    pattern: "Below all fields, easily reachable"
    mobile: "Full width or large enough to easily tap"

spam_prevention:

  honeypot:
    description: "Hidden field that should be empty"
    pattern: "Bots fill it; humans don't"
    benefit: "Invisible to users; effective"
    example: |
      <input type="text" name="website" tabindex="-1" 
             autocomplete="off" style="position:absolute;left:-9999px;">

  recaptcha_v3:
    description: "Invisible scoring of user behavior"
    benefit: "No user interaction required"
    pros: "Better UX than visible captchas"
    cons: "Privacy concerns; some users blocked"

  recaptcha_v2:
    description: 'Visible "I am not a robot" checkbox'
    use: "When v3 isn't sufficient"
    accessibility: "Audio alternative for visually impaired"

  hcaptcha_or_turnstile:
    description: "Privacy-preserving alternatives to reCAPTCHA"
    benefit: "Better privacy stance"

  rate_limiting:
    description: "Server-side rate limiting on form submissions"
    implementation: "Per IP, per session"

mobile_form_optimization:

  field_sizing:
    requirement: "Touch-friendly target size"
    minimum: "44px tap target (Apple HIG)"

  input_types:
    requirement: "Use semantic input types"
    benefit: "Triggers appropriate keyboard"
    examples:
      - email triggers @ keyboard
      - tel triggers numeric keyboard
      - number triggers numeric
      - date triggers date picker

  autocomplete:
    requirement: "All standard fields have autocomplete attributes"
    benefit: "Mobile autofill saves significant typing"

  field_layout:
    pattern: "Single column on mobile"
    avoid: "Side-by-side fields that compress small"

  buttons:
    sizing: "Large enough to tap easily"
    typically: "Full-width or near-full-width"

  placement:
    avoid: "Submit at bottom requiring scroll on small screens"
    pattern: "Sticky submit or visible immediately after final field"

// Form view event
gtag('event', 'form_view', {
  form_id: 'contact-form',
  form_name: 'Contact Form'
});

// Form start (first interaction)
gtag('event', 'form_start', {
  form_id: 'contact-form',
  form_name: 'Contact Form'
});

// Field-level tracking (advanced)
gtag('event', 'form_field_complete', {
  form_id: 'contact-form',
  field_name: 'email'
});

// Form submit
gtag('event', 'form_submit', {
  form_id: 'contact-form',
  form_name: 'Contact Form',
  form_destination: '/thank-you/'
});

// Form abandon (when user leaves form section)
gtag('event', 'form_abandon', {
  form_id: 'contact-form',
  last_field: 'phone'
});

form_analytics_tools:

  hotjar_forms:
    features: "Field-level analytics, time per field, drop-off"
    cost: "Included with Hotjar"

  formisimo:
    features: "Detailed form analytics specifically"
    cost: "Paid"

  zuko:
    features: "Form analytics suite"
    cost: "Paid"

  mouseflow_forms:
    features: "Session recording with form focus"
    cost: "Included with Mouseflow"

form_metrics:

  view_to_start_rate:
    formula: "Form starts / form views"
    benchmark: "30-60% typical"
    improve: "Reduce friction to start; visible value"

  start_to_completion_rate:
    formula: "Submissions / form starts"
    benchmark: "20-40% typical, varies widely"
    improve: "Reduce field count; better validation; trust signals"

  view_to_completion_rate:
    formula: "Submissions / views"
    benchmark: "5-15% typical"
    improve: "Optimize entire flow"

  field_drop_off:
    measurement: "Where users abandon"
    insight: "Specific friction points"
    action: "Address that field specifically"

  time_to_complete:
    measurement: "Median time from start to submit"
    insight: "Forms that take too long abandon more"