Custom fields best practices

---

title: Custom fields best practices
description: Expert guidance for designing effective custom fields that improve data collection without overwhelming users
keywords: form design, custom fields, UX, best practices, conversion optimization
sidebar_position: 7

Adding custom fields is powerful, but poorly designed fields can hurt form conversion and frustrate users. This guide shares battle-tested practices for creating custom fields that collect the data you need without creating friction.

Start with "Why?"

Before adding any custom field, clearly articulate why you need it:

• Good reason: "Department field routes 70% of inquiries automatically, reducing response time."
• Bad reason: "It would be nice to know their company size."

The test: If you can't explain how the field improves the customer experience or your team's workflow, don't add it.

Design for conversion

Guideline 1: Limit to 3 fields maximum (ideally 1-2)

Research shows each additional field decreases conversion. Start small:

• Phase 1: Add 1 field (e.g., Department)
• Measure: Check if submission rate drops
• Phase 2: Add 1 more if needed (e.g., Priority)
• Repeat: Only add more if the data is worth the conversion cost

Exception: Highly motivated users (e.g., existing customers reporting issues) tolerate more fields.

Guideline 2: Make all custom fields optional

Required fields = higher abandonment. The email field is already required, ensuring you can always follow up.

When to break this rule:

• The field is essential to process the request (e.g., "Order number" on an order-specific form)
• You've tested and confirmed the requirement doesn't hurt conversion significantly

Guideline 3: Progressive disclosure

For complex workflows, consider:

• Starting with a minimal form (name, email, message)
• Adding fields later in the conversation via your response
• Using form metadata (URL parameters) to pre-populate fields or route intelligently

Example: Instead of a "Product" dropdown on every form, create separate form URLs for each product and use metadata to capture which product the user came from.

Writing effective labels and options

Labels: Be specific and action-oriented

Good labels:

• "What can we help with?" (clear, friendly)
• "Order number (if applicable)" (clarifies optionality)
• "Which products are you using?" (specific scope)

Bad labels:

• "Info" (too vague)
• "Department" (formal, doesn't explain why you're asking)
• "Data" (meaningless to users)

Options: Keep them concise and scannable

Good options:

• Short (1-3 words when possible)
• Consistent structure (all nouns, all questions, etc.)
• Ordered logically (frequency, alphabetical, or progression like Low → High)

Example for "Priority":

• ✓ Good: Low, Normal, High, Urgent
• ✗ Bad: This is not urgent, Somewhat urgent, Very urgent, Extremely urgent (too wordy)

Avoid overlapping options

Bad example for "Department":

• Sales, Pre-sales Questions, New Customer Questions, Technical Support
  • Problem: "Pre-sales Questions" and "New Customer Questions" overlap; users won't know which to choose

Good example:

• Sales & Pre-sales, Technical Support, Billing, General Inquiry
  • Clear boundaries between options

Mobile optimization

Over 60% of form traffic is mobile. Design for thumb-friendly interactions:

• Dropdowns: Work great on mobile (native UI)
• Radio buttons: Ensure adequate tap target size (handled by default styles)
• Checkboxes: Same as radio buttons
• Short text: Use appropriate placeholders to hint at format (e.g., "e.g., #12345" for order numbers)
• Long text: Avoid if possible; typing long responses on mobile is tedious

Test on real devices: Use the Preview tab or load your form URL on your phone before launching.

Ordering and grouping strategy

Place fields in a natural, progressive flow:

1. Context first: What is this about? (Department, Topic)
2. Details next: Specifics about the inquiry (Order number, Product)
3. Preferences last: How you want us to respond (Priority, Contact preference)

Example order:

1. "What can we help with?" (Dropdown)
2. "Order number" (Short Text, optional)
3. "How urgent is this?" (Radio)

This mirrors how users think: "I have a billing question about order #12345, and it's pretty urgent."

When NOT to use custom fields

Alternative 1: URL metadata

If you need to track source, campaign, or referrer, use URL query parameters instead of a form field.

Example:

• Instead of: "How did you hear about us?" dropdown
• Use: ?source=facebook in the form URL

Alternative 2: Follow-up questions

If the information is only relevant for some users, ask it in your reply instead of upfront.

Example:

• Instead of: "Are you an existing customer?" field on the form
• Ask: "Are you an existing customer?" in your reply if it's relevant

Alternative 3: Integrations

Use Shopify integration to automatically show order data instead of asking users to type it.

Field-specific best practices

Department/routing fields

Purpose: Route inquiries to the right team or tag for filtering.

Best practices:

• Use 3-5 clear, non-overlapping options
• Label customer-facing: "What can we help with?" not "Department"
• Order by frequency (most common option first)

Example:

• Label: "What can we help with?"
• Type: Dropdown
• Options: Technical Support, Billing & Payments, Sales & Pre-sales, General Question

---

Priority/urgency fields

Purpose: Triage high-priority issues faster.

Best practices:

• Use radio buttons (4 options visible at once)
• Don't assume everyone thinks their issue is urgent (avoid bias toward "High")
• Provide context for each level if ambiguous

Example:

• Label: "How urgent is this?"
• Type: Radio Buttons
• Options: Low (I can wait days), Normal (A few hours is fine), High (I need help today), Urgent (Blocking my work)

Note: Adding context in parentheses helps users self-triage accurately.

---

Product/service selection fields

Purpose: Understand which product the inquiry is about.

Best practices:

• Use dropdown if you have 6+ products
• Use checkboxes if users might have questions about multiple products
• Include "Other" or "Not sure" option

Example for SaaS with multiple products:

• Label: "Which product is this about?"
• Type: Dropdown
• Options: Product A, Product B, Product C, All Products, Not sure

---

Order/account identifier fields

Purpose: Reduce back-and-forth by collecting reference numbers upfront.

Best practices:

• Make optional (not everyone will have an order number handy)
• Use short text with a helpful placeholder showing the format
• Clarify when it's needed: "Order number (if applicable)"

Example:

• Label: "Order number (optional)"
• Type: Short Text
• Placeholder: "e.g., #12345 or ORD-2024-5678"

Form length and cognitive load

The 30-second rule

Users should be able to complete your form (including reading, thinking, and typing) in under 30 seconds on mobile.

Estimate for each field type:

• Short Text: +5 seconds (type short response)
• Long Text: +15 seconds (type longer response)
• Dropdown: +3 seconds (tap, scroll, select)
• Radio Buttons: +2 seconds (scan, tap)
• Checkboxes: +4 seconds (scan, tap multiple)

Example:

• Name, Email, Message: ~15 seconds
• • Department dropdown: ~18 seconds ✓
• • Priority radio: ~20 seconds ✓
• • Order number text: ~25 seconds ✓ (still under 30s)
• • Long text "Describe issue": ~40 seconds ✗ (too much)

Reduce cognitive load

Every field should be:

• Self-explanatory (no need to read instructions)
• Clearly optional or required
• Relevant to the user's current goal

Bad example:
A form asking users to fill out company size, annual revenue, and number of employees before they can ask a simple question.

Good example:
A form asking only for department and message, then gathering additional context in the conversation if needed.

Handling "Other" and edge cases

Most multiple-choice fields should include an "Other" or "Not sure" option to avoid forcing users into incorrect categories.

When to include "Other":

• Dropdown or radio with finite, specific options (departments, products, etc.)
• Users might not see their situation represented

When NOT to include "Other":

• Priority levels (every level should be clear enough that users can pick one)
• Yes/No questions (no middle ground needed)

What to do with "Other" responses:

• Review them periodically
• If you see patterns, add new options to cover common "Other" cases
• If "Other" is rarely used, your options are well-designed

Testing your custom fields

A/B testing (manual)

1. Baseline: Note your current submission rate over 1 week
2. Add field: Introduce 1 custom field
3. Measure: Check if submissions dropped significantly (>10%)
4. Decide: Keep the field only if the data value outweighs the conversion cost

User feedback

Ask a colleague or friend (not on your team) to fill out your form:

• Did any field confuse them?
• Did they hesitate on any field?
• Did the form feel too long?
• Would they abandon if they were in a hurry?

Analytics to track

While SupportRetriever doesn't provide field-level analytics (yet), you can:

• Monitor overall submission rate before/after adding fields
• Check how often custom fields are left blank (indicates low value or confusion)
• Review "Other" option usage to spot missing options

Evolving your fields over time

When to add a field

• You're manually asking the same question in 30%+ of conversations
• A field would eliminate a full round-trip (e.g., order number for order issues)
• You're routing inquiries manually and a field would automate it

When to remove a field

• Less than 50% of users fill it out (low perceived value)
• The data isn't being used to improve support quality
• Submission rate dropped noticeably after adding it

When to edit a field

• Users frequently pick "Other" (add more options or make labels clearer)
• Responses are inconsistent (switch from text to dropdown for standardization)
• You notice patterns in how users interpret ambiguous labels

Advanced: Conditional logic (future)

SupportRetriever doesn't currently support conditional fields (showing fields based on previous answers), but you can simulate this with multiple forms:

Example:
Instead of one form with conditional "Order number" field:

1. Create two forms: "Order Issue" and "General Inquiry"
2. Add "Order number" field only to the "Order Issue" form
3. Link users to the appropriate form based on their need

Summary checklist

Before publishing custom fields:

• Each field serves a clear, measurable purpose
• Total fields ≤ 3 (ideally 1-2)
• All custom fields are optional
• Labels are customer-facing and specific
• Options are concise, non-overlapping, and ordered logically
• Tested on mobile (actual device, not just desktop browser resize)
• Form completes in under 30 seconds
• No internal jargon or abbreviations
• "Other" option included where appropriate

Related articles

• Adding custom fields to forms
• Custom field types reference
• Configuring form fields