Energy request form design

[msthiramoni367]

Best practices for creating Request Forms
Here are some tips for making your request forms both user-friendly and relevant to the process they're part of.

A) When possible, pre-fill fields



If your system already knows anything about the user, don't have them fill it out again. This information might include your name, department, office location, supervisor, and so on. Other "known" information may include "preset expenditure limit" or "assigned resource" (for example, a project request may pre-fill the requester's assigned project manage japan phone number list These kinds of pre-fills can significantly cut form completion time while also improving user experience. Pre-fills also limit the possibility of incorrect data being entered, which can lead to forming processing difficulties later on.

B) As far as possible, avoid free-form fields


Most form users prefer to pick rather than type, which is logical given that it is far faster. However, it is also excellent for reporting. You will be able to aggregate replies without having to manually normalize the data if you use pre-determined values to be picked. For example, if your form asks the user to "Describe the capital acquisition." and allows for a free-form response, you may get responses like:

a) To replace the non-functioning A/C unit

b) Enterprise software for accounting

c) New construction for additional call center capacity

d) We needed a better copier

When the CFO inquires, "So, what kind of expenses are most frequently requested?" You have absolutely no idea. However, if you use a dropdown menu with the following options:

a) Building

b) Computer Equipment

c) Furniture or Fixtures

d) Intangible Assets

e) Land

f) Machinery

g) Office Equipment

h) Software

i) Vehicles

Then, when needed, each of these things might be split down. For example, if users pick "Intangible Assets," you may provide additional options such as "patent, copyright, franchise/license, trademark, or goodwill." You may now run a report that breaks down the data by type and subtype.

C) Include just the fields that are required

Personal detail form

You don't want people to glance at your request form and then hunt for other means to make the request (email, phone call, office "pop-in," etc.). If your form is filled with hundreds of fields, many of which have no obvious use, your users will leave it and, like water, seek the route of least resistance.

Consider this: for each field, you add to a form, you must explain to the user why you require the information. If you come across fields that are more "nice to haves" than "need to haves," consider if you want to keep them. Alternatively, simply ask yourself these questions:

a) Is it likely that the user will have this information to provide?

b) Is it required for a subsequent report?

c) Will action be performed in response to this data point?

These questions will give you an idea of how important it is to include that field in the request.

D) The buddy of the requester is conditional logic



Though a form user may be unaware of it, there may be extra questions concealed from their view that surface only when necessary. A form developer may drastically minimize the size and complexity of their forms by showing and concealing fields. Any questions/fields with "(if applicable)" next to them are good candidates for conditional logic. Based on pre-filled data or past replies, the form should be able to determine if a question is appropriate.

For example, if the form already "knows" that the person filling the "Hardware Request Form" is a Field Sales Representative, it also knows that the "Tablet Selection" portion of the form should be displayed because Field Sales Representatives are the only roles that may request them. Displaying the "Tablet Selection" option to everyone else implies that IT will get tablet request