How to Make Better Request Forms

Earlier we posted twelve tips for more usable Web forms. Today we’re looking specifically at request forms and request form templates. Request forms are usually the first step in any process whether it’s a project request, a finance request, an HR request, or any of the thousands of possible business process forms people use every day. In most business processes, someone is either requesting or reporting something to start a workflow. Because of this, getting a request form right is critical to the proper functioning of a process.

Here are some ways you can ensure your request forms are both user-friendly and meet the needs of the process they’re part of.

Include only the fields you actually need

You don’t want users to take one look at your request form and immediately look for another way of making the request (email, phone call, office “pop-in,” etc.). If your form is littered with dozens of fields, of which many serve no immediately identifiable utility, your users will abandon your forms and, like water, seek the path of least resistance.

Imagine if, for every field you add to a form, you are required to explain to the user exactly why you need the information. If you find fields that are more “nice to haves” than “need to haves,” decide whether you really want to leave them in. Or just ask yourself these questions:

• Will action be taken on this data point?

• Does a downstream report require it?

• Is the user likely to have this information to provide?

These questions will give you a sense of how critical it is to have that field as part of the request.

Pre-fill fields whenever possible

If your system already knows information about the user, don’t make them manually fill it in. This information might include, name, department, office location, supervisor, etc. Other “known” details could include things like “preset spending limit” or “assigned resource” (for instance a project request could pre-fill the requester’s assigned project manager if known). These kinds of pre-fills can greatly reduce form completion time and provide a much better user experience. Pre-fills also reduce the risk of bad data being entered, which can lead to form processing issues downstream. 

Conditional logic is a requester’s friend

Though a form user may never realize it, there could be additional questions hidden from their view that only appear if needed. By showing and hiding fields, a form developer can greatly reduce the size and complexity of their forms. Good candidates for conditional logic are any questions/fields that have “(if applicable)” next to them. The form should know if a question is applicable based either on pre-filled data or previous answers. 

For instance, if the form already “knows” the person completing the “Hardware Request Form” is a Field Sales Representative then it also knows to show the “Tablet Selection” section of the form since Field Sales Representatives are the only roles that are allowed to request them. Showing the “Tablet Selection” section to everyone else means IT will get requests for tablets from people who shouldn’t have one.

The same goes for spending limits. If you don’t want someone to make a purchase request beyond their limit, make the field conditional based on their known limit. The limit might be based on their level, department or a specific number kept in a database table for all employees.

Avoid free-form fields as much as possible

Most form users would rather select than type, which is understandable since it’s a lot quicker. But it’s also better for reporting. By using pre-determined values to be selected you’ll be able to aggregate answers without having to manually normalize the data. For instance, if your form asks the user to “Describe the capital purchase.” and provides a free-form answer, you might get answers like:

• “To replace the non-functioning A/C unit.”

• “We needed a better copier.”

• “New construction for additional call center capacity.”

• “Enterprise software for accounting.”

When the CFO asks “So what kind of expenditures are being requested most often?” you really have no idea. However, if you use a dropdown with options:

• Building

• Computer Equipment

• Office Equipment

• Furniture or Fixtures

• Intangible Assets

• Land

• Machinery

• Software

• Vehicles

And then each one of these items could be broken down as needed. For instance, if they select “Intangible Assets” you might expose another selection that includes “patent, copyright, franchise/license, trademark, or goodwill.”

Now you can run a report with a breakdown by type and subtype.

Always think mobile

When we redesigned our form designer, one of the main focuses was on making our forms work well on mobile screens by default. That was based on feedback from our customers who were finding that no matter what kind of request form they were building, their users wanted the option of using their phones or tablets. The same is likely true in your organization. Great mobile forms aren’t just for field service workers; they’re for the head of HR approving a new hire from the airport or a manager sitting on the couch after hours requesting time off. Much has been written on the topic of designing for mobile so we’ll just point you to one of the best ones: “Best Practices For Mobile Form Design” by Nick Babich.