Do: Keep your forms small and simple (don’t build long forms)
It’s easy to get carried away and try to build really elaborate, all-inclusive forms.
One word about that: don’t
Just don’t do it. Don’t build long forms.
Why not?
The longer the form, the more time your field staff will spend filling it out. That means less time available for them to do their field work. If this statement doesn’t resonate with you, then you need to get out of your well-lit, climate-controlled, comfortable office and out in the field with them to actually experience what their usual day is like. Hint: they are busy as shit, dealing with weather issues, equipment issues. and almost always some unforeseen events. The last thing they want to do is spend a bunch of time squinting at a phone with the sun baking them to a crisp, tapping and pecking at the device to fill out things. Point is, the longer the form, the less likely your field staff will actually use it. So keep it as basic and as short as practical.
An example of a well-intentioned, but too long of a form is a Phase I Environmental Site Assessment (ESA) Site Visit form. To properly fill one of those things out on an iPhone, or even an iPad, you have to scroll A LOT! Tons of information to fill out, lots of tables, fill-in text and paragraph fields, checkboxes, etc. Filling out one of those forms while on site can be distracting. It’s better to just jot down notes as needed, record audio notes, take lots of pictures, and then fill out that form when you are back at the office. Or consolidate that site visit form to just the bare bones basics. As basic as possible. If you don’t, your user adoption rate for that form will be dismal. I think this is why dedicated Phase I ESA Site Visit software hasn’t taken off. It’s onerous to fill out in the field because it’s just too time-consuming.
Do: Pre-populate as much of a form as possible
Why? For the same aforementioned reasons: that your field staff is really busy trying to do their field job while often battling weather and equipment issues. If a form is pre-filled, inteliigently, then your field staff doesn’t have to worry about that field. That’s one less data point they need to worry about.
Most software tools allow you to pre-populate fields when the form first loads. For example, fields like:
- Date and time
- The user filling out the form
- Calculated fields
- Default values in text fields
And with XForms, you can design a form with a table grid that can be pre-populated with values in any of the cells. Here’s an animated gif illustrating a typical pre-loaded table. In the example below, the Status column is a listbox, and it has been pre-populated with the value “N/A” in it. When a user loads this form, he/she can tap on a row and change the N/A value to a different value. This saves a field tech gobs of time by not having to tap on each row for items that are not applicable.
Do: Group similar questions and fields into form sections
Set up your form to be INTUITIVE to the field user. That is, group things logically. Don’t scatter similar things around from one area to another. Keep them close together.
An example of this is illustrated above in the animated gif. Notice that this form has clear sections. Tap on a section header to expand it and you will see fields specific to that section name.
Do: Be consistent across all your form templates
Consistency across forms will lead to a shorter learning curve for your field staff using those forms. A good practice is to place your basic form fields at the very top of the form template. Things like date, time, user, client, and project. And to then create a section toward the bottom of the form template to place a general field notes section, a photo capture field, and a signature block.
After you have established a norm, stick with it and follow this pattern for all your form templates. Trust me on this: your field staff will appreciate this.
Do: Use valid value ranges where possible
An example of this is a pH field. We all know that you can’t have a pH less than zero or greater than 14. So you should set the valid values range to 0-14. Then if a user accidentally types 770 (because they forgot to type in the period after the first 7), the system will beep at them and the field user can correct the value.
Do: Use human-readable field IDs
A pet peeve of mine is the use of overly-complicated field_id’s. Reminds me of the insanely complex processes that the US Army Corps of Engineers (USACE) use. They tend to favor process over results for some reason. I know this because my old firm Terraine that I founded ages ago won a few 5-year USACE contracts. But alas, most engineers think this way 🙂
Trust me on this: Don’t use some sort of fancy field_id pattern that only you will understand. Just use field IDs that can be understood by regular Joes. One day you aren’t going to be around (because you quit, got laid off, or died), so keep it simple. Also, these field_id’s are used when extracting data programmatically via API calls out of the software tool, so the more understandable these are, the easier it will be for the programmers that are building integrations. So….just keep these field_id’s simple and short.
Parting thoughts
A big goal of field form software is to use it for downstream benefits. Things like automated PDF generation, analysis of digital data sets that can be sliced and diced to look at trends and patterns, and to systematically improve the efficiency of some of your organization’s workflows by reducing manual processes. But to do that, you have to have decent user adoption by your field teams. And to have adequate user adoption, the forms you push out to those teams need to be simple, understandable, and almost minimalistic from the field user’s perspective. Otherwise, they will see it as yet more work thrown at them.
So…keep your forms simple.
Period.
Want to learn more about XForms?
Click/tap the button below