Picklists, Free Text and Everything Between: Designing Fields People Fill In Correctly

How to choose the right field type, build controlled vocabularies people will use, and avoid the 'Other' option that quietly ruins your data.

You ask for a report of requests by department. The tool helpfully groups them: “Finance” (41), “finance” (12), “Fin” (8), “Accounts” (15), “Finance team” (6), and one memorable entry that just says “Dave”. The report is technically correct and practically useless.

Nobody did anything wrong. They were handed a blank box and filled it in their own way. Field design is how you stop that happening.

Every field is a question

It helps to think of each field as a question you’re asking the person filling it in. The field type is the shape of the answer you’ll accept. Choose the shape based on two things: what you’ll do with the answer later, and how much the person needs room to explain.

If you’ll group, filter, count or trigger an automation on the answer, you need consistency. If you’ll only ever read it, you need expressiveness. Most fields fall clearly on one side.

The main field types, in plain English

Field type	Use it when	Example
Single-select picklist	One answer from a known, short list	Priority: Low, Medium, High
Multi-select picklist	Several answers from a known list	Channels used: Email, Phone, Web form
Link to another record	The answer is something you track elsewhere	Client, assigned person, project
Number	You’ll add, average or compare it	Quantity, hours, budget
Date	You’ll sort by it or measure time	Due date, date received
Yes/No checkbox	The answer really is binary	Signed contract received
Short text	A name, code or title that varies	Invoice reference, subject line
Long text	Explanation or context	Description, notes

Two of these get underused. Linked records are the right answer whenever the list of options is really a list of things you track, like clients or people. A picklist of 300 client names is a linked record trying to escape. Numbers stored as text are a classic spreadsheet leftover: “approx 20”, “15-20”, “TBC”. Use a number field and a separate note if people need to qualify it.

Designing a picklist people will use

A picklist (also called a dropdown or controlled vocabulary) is only as good as its options. A few rules keep it useful:

Make options mutually exclusive. If “Urgent” and “High” both exist, people will pick differently for the same situation.
Cover the real cases. Look at what people actually wrote in the old free-text column. If 20% of entries don’t fit any option, your list is wrong, not your users.
Keep it short. Somewhere around seven options, scanning gets slow. If you need more, consider grouping or a linked record.
Order it sensibly. Logical order for scales (Low to High), most common first for categories, alphabetical only when nothing else makes sense.
Write labels a newcomer understands. “Tier 2 escalation” means something to your team today and nothing to the person who joins next year.
Add a short description to each field explaining what it’s for. Most tools show this as help text right next to the field.

Cleaning Your Spreadsheet Data Before Migration: A Practical Guide covers converting old free text into picklist values. This post is about designing the list so you don’t need that cleanup again.

The trouble with “Other”

“Other” looks like a kindness. It’s usually a trap.

Here’s how it goes wrong. Your request form has a “Category” picklist with eight options plus “Other”. People in a hurry pick “Other” because it’s faster than reading eight labels. Within six months, “Other” is the second-biggest category and your report tells you nothing.

That doesn’t mean you should never use it. Use it carefully:

Pair it with a required text field that appears only when “Other” is chosen. Asking people to type one line makes “Other” slightly harder than picking the right option.
Review “Other” monthly. Read the text entries. If the same thing appears five times, it deserves its own option.
Watch the percentage. If “Other” climbs above a small slice of entries (say one in ten), the list needs work.
Leave it out when the list is truly closed. A “Region” field for a company in four regions needs no “Other”.

When free text is the right answer

Not everything should be a dropdown. Over-structuring creates its own mess: people choose the nearest wrong option because the right one doesn’t exist, and your data becomes confidently inaccurate.

Free text is right for descriptions, context, reasons and anything you’ll read rather than count. A support ticket needs a category picklist so you can report on volumes, and a description box so the person handling it understands the problem. Both, not one or the other.

A useful test: if you’d never filter or group by this field, free text is probably fine.

Changing a picklist after launch

Lists evolve. When you rename, merge or retire an option, think about the records that already use it.

Renaming is usually safe in a proper tool, since existing records update with it. Announce it anyway.
Merging two options means updating old records so history stays consistent. Do it in one go, not gradually.
Retiring an option is best done by hiding it from new entries while keeping it on old records. Deleting it can leave those records blank.

Changing a Live System Without Breaking Trust covers how to communicate these changes so nobody is surprised.

Where to start this week

Find your messiest text column. Pick the one you most often wish you could report on and list every distinct value in it.
Draft a picklist from that list. Group similar values, aim for under ten options, and decide whether you genuinely need “Other”.
Check for hidden linked records. Any picklist of people, clients or projects should probably link to those records instead.
Write one line of help text for each field on your most-used form.