Whether on paper or online, the unconstrained text box is the most common type of form input that you’ll find in the wild. Here are a few examples of unconstrained text boxes I just copied from a quick search, one each from paper, hybrid and digital forms:

In the humble opinion of the author, this should be the form designer’s last resort. This week we’re going to look at the use of text boxes as form fields, and why a little bit of thought and effort up front can greatly improve the quality of your collected data.

There are many choices you can make when designing a form - there are common form field designs and techniques that are purpose-built for the different types of data that you collect. Your choice could make the form easier or quicker to fill out properly, guide the types of data allowed, and ultimately improve the quality of the data collected.

Conversely if you use only one kind of input for every piece of information your form is collecting: a blank, unconstrained text box with a title; you have given up the most direct place that you as the form designer can control the quality of the data. This means that you will rely more on training users, manual reviews of filled forms, cleaning data sets, or issuing deviations and CAPAs to try to 'fix' data quality issues.

It's much better to collect good data quickly in the first place!

An unconstrained text box is an input area where the user can fill in just about

. On a paper form, it’s a plain box with some kind of title. On a digital form, it’s the default text input field provided by whatever framework is being used to build the form.

In either case there’s no local guide or control as to data format or content - it’s up to the filler to figure out what goes into that box based on the title, box size and any context or instruction that comes with the form.

Although I call them ‘unconstrained’, it's worth noting that there are still some constraints to these text boxes. For example, on a paper form, you are practically limited to the size of the space given for that field (i.e. the size of the box and any space around it for marginalia). Depending on the size of the person’s handwriting this may or may not be enough for the information being asked for.

On a digital form there are limits to how much you can enter too (i.e. number of characters it will allow), however it rarely has anything to do with what’s visible nor what’s reasonable for the question being asked. Instead, it’ll be set to whatever default limit is given by the form building software. Other default limitations on a digital input text box might include whether multiple lines are allowed and how many, whether and what you can cut and paste, whether the input may be formatted, if language settings can be changed and whether right-to-left input is allowed.

In general these constraints are not controlling the input in ways that are intentional to the purpose of the form - they’re either implicit to the physical design of the form (how much space there is on a piece of paper?), or due to the limitations or default states of the underlying form technology (what are the defaults? what options do you have for constraining input?).

All these constraints, yet nothing to guide what you actually want from the data!

Why is this a problem in a production facility or laboratory? If I give you a form with an "Age" box on it, shouldn’t it be obvious to the operator which age goes in there? After all, if they’re competent and trained, we shouldn’t have to hold their hand through every form filling, right?

Let’s take a look at all the things that the operator needs to keep in their heads to fill in that Age box.

So three operators may fill it out in different ways (say, 20.25 years, 243 months and "twenty") and still be

, however the data would be less usable without some manual intervention to put it into a consistent format.

You could get around this by training and instruction. However this is a lot of

for the operator to keep in mind while filling out the form, multiplied by all the fields and all the forms that they may be required to interact with.

When you constrain an input to be exactly what is expected, you are front-loading a small amount of cognitive load, taking it off of the operator’s plate.

, these little efficiencies will add up.

On the other end, the more guarantees you can make on the consistency of a dataset, the easier it is to automate parts of the pipeline. As any data analyst or statistician can tell you, there’s often a large amount of data QC and cleanup that’s necessary from a manual data set before it can be properly analysed.

As I mentioned, you have a whole toolbox of ways that you can constrain input on forms, including:

In general you can and should use a combination of these strategies, but prefer a tighter feedback loop as long as it doesn't get in the way of quick data input. Let them know the format

the user inputs data, highlight problems

they input the data, and finally if at all possible don't allow incorrect input to be submitted.

We'll cover all of these aspects in more detail in future posts.

Of course there are times when what you actually want is a bunch of free-form text. For example a description field or commentary to add detail to a process.

Often these are fields that aren't going to be aggregated and processed in an automated fashion. If they are, then you're probably missing an opportunity to constrain the data - and as we've discussed in previous posts constrained data is much more amenable to automation!

Finally, test your forms out with the people who will be using them. Is the form easy to use? Can they think of grey areas or a corner case where the correct answer might not be on the form? If so, maybe you're asking the wrong

in the first place.

There's much more we can write about good form design, testing and maybe even a case for validating forms. I'll cover these and more future posts.

Until then, thanks for reading!

– Brendan