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: 6
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.
Core principles
1. Less is more
Rule: Every additional field reduces conversion. Only add fields that provide clear value.
Before adding a field, ask:
- Can we get this information another way (e.g., from metadata, Shopify integration)?
- Can we ask this later in the conversation instead?
- Will we actually use this data to improve the customer experience?
Example:
- ❌ Bad: Adding "Company size," "Industry," "How did you hear about us?" for a basic support form
- ✓ Good: Adding only "Department" to route inquiries faster
2. Make fields optional by default
Custom fields should enhance data collection, not block submissions. Making fields required increases abandonment, especially on mobile.
Exception: A field can be required if:
- It's absolutely necessary to process the request (e.g., "Order number" for an order issue form)
- You're prepared to lose some submissions because incomplete information would be useless
3. Use clear, customer-facing language
Write labels and options for your customers, not your internal team.
Examples:
- ❌ "Dept routing" → ✓ "What can we help with?"
- ❌ "Sev level" → ✓ "How urgent is this?"
- ❌ "SKU" → ✓ "Product name or order number"
4. Order fields logically
Place fields in a natural flow that mirrors how users think about their inquiry:
- General context (department, topic)
- Specific details (order number, product)
- Priority or preferences (urgency, contact method)
Field type selection best practices
When to use Short Text
- You need specific, brief information (identifiers, names, numbers)
- The answer varies too much for predefined options
- You're asking for something unique to each user (order number, account ID)
Avoid: Using short text when dropdown or radio would provide more consistent data.
When to use Long Text
- Rare. Most multi-line content belongs in the main message field.
- Only use for supplementary information like error logs, steps to reproduce, or lists.
When to use Dropdown
- 6+ mutually exclusive options
- Space is limited (mobile forms especially)
- Options are scannable (departments, products, categories)
Tip: List the most common option first to reduce clicks.
When to use Radio Buttons
- 2-5 mutually exclusive options
- You want all choices visible for easy comparison
- Visual hierarchy matters (Low → Medium → High)
Why visible options matter: Users make better decisions when they can see all choices without clicking.
When to use Checkboxes
- Multiple selections are valid (e.g., "Which features are you interested in?")
- Users might select none, one, or many options
- You're asking "Which of these apply?" rather than "Pick one"
Tip: Limit to 5-6 options to avoid overwhelming the user.
Real-world examples
Example 1: SaaS support form
Goal: Route inquiries efficiently and gather context.
Fields:
- "What can we help with?" (Dropdown)
- Technical Issue, Billing Question, Feature Request, General Inquiry
- "How urgent is this?" (Radio)
- Low, Normal, High
Why it works:
- Only 2 fields; minimal friction
- Department routing is clear and customer-friendly
- Priority helps triage without requiring detailed urgency explanations
Example 2: E-commerce order support
Goal: Reduce back-and-forth by collecting order context upfront.
Fields:
- "Order number" (Short Text, placeholder: "e.g., #12345")
- "What's the issue?" (Radio)
- Damaged item, Wrong item, Delivery delay, Other
Why it works:
- Order number field saves time for both parties
- Issue type options cover 90% of support cases
- Falls back to "Other" for edge cases
Example 3: B2B lead qualification
Goal: Collect enough context to prioritize high-value leads.
Fields:
- "Company name" (Short Text)
- "I'm interested in..." (Checkboxes)
- Product A, Product B, Product C, Consulting Services
Why it works:
- Company name personalizes follow-up
- Multi-select shows breadth of interest
- Still feels lightweight (2 fields, both fast to complete)
Common mistakes to avoid
❌ Mistake 1: Too many fields
Example: 8 custom fields asking for company size, industry, role, budget, timeline, referral source, use case, and team size.
Problem: Form feels like an interrogation. Conversion drops significantly.
Fix: Cut to 2-3 essential fields. Get the rest through conversation or a follow-up email.
❌ Mistake 2: Making optional fields required
Example: Marking "Company name" or "Phone number" as required when email already provides a reply channel.
Problem: Forces users to provide info they may not want to share, causing abandonment.
Fix: Make custom fields optional. Remember: email is always required, so you can always reply.
❌ Mistake 3: Using dropdowns for 2-3 options
Example: "Priority" dropdown with options: Low, High.
Problem: Requires extra click to reveal options. Radio buttons are faster and clearer.
Fix: Use radio buttons for 2-5 options so users see choices immediately.
❌ Mistake 4: Ambiguous labels
Example: "Type" (what type? Issue type? Customer type? Inquiry type?).
Problem: Users pause, confused about what you're asking.
Fix: Be specific: "What type of issue are you experiencing?"
❌ Mistake 5: Internal jargon in options
Example: Dropdown with options: "L1 Support," "L2 Escalation," "Tier 3."
Problem: Customers don't know your internal team structure.
Fix: Use customer-facing terms: "General Support," "Technical Specialist," "Billing."
Testing and iterating
After adding custom fields:
- Test on mobile: Most users submit from mobile devices. Ensure fields are easy to tap and complete.
- Monitor submission rate: Compare submissions before and after adding fields. A significant drop indicates too much friction.
- Review actual responses: Are users providing useful data? Are they confused by any fields?
- Iterate: Remove underused fields. Simplify confusing labels. Adjust options based on actual responses.
Accessibility considerations
- Use clear, descriptive labels (screen readers announce these)
- Avoid placeholder-only fields (placeholders disappear on focus)
- Order options logically so keyboard navigation is intuitive
- Test with keyboard-only navigation (Tab, Arrow keys, Enter)
Performance and technical notes
- Custom fields are optional by design (email is the only required field)
- Field responses are stored as JSON in the database for flexibility
- Past submissions are unaffected when you edit or delete fields
- Custom fields data appears in emails, conversations, and exports
- All field values are sanitized to prevent XSS and HTML injection