Electronic forms need management just as much as paper forms do. Web forms may be the most common type of electronic form in use today, yet they may also be the most uncontrolled and, arguably, the most poorly designed from a forms management perspective.
What is Forms Management?
Forms Management comprises the development and management processes used to keep forms under control: from the first moment they are considered, through publication, the points at which they are filled in, their eventual life as records, and eventually making them obsolete.
All organizations have a forms management function—even if they don’t realize it. That is because all organizations develop and use forms, and the costs are borne by every department or individual who creates, uses, or extracts data from a form.
What professional forms managers do is to bring all that under control. We make sure we know exactly how much each form costs at all stages of its life, and exactly what forms the organization has published, when, and for what purposes.
Sometimes a department attempts to exclude itself from forms management by redefining what they develop as something other than a form. I often hear something like, “This isn’t a form, it is a web page.” My answer: “No. If it has fields for the capture and/or display of variable data, then it’s a form.” If you are bringing data into an organization using a form, then you need forms management.
You may think, “That’s a lot of work for something as simple as a form.” The answer is, “Yes, but it’s a lot cheaper in the long run than not doing it.”
Looking at Different Types of Online Forms
Very often, a person who says, “I want a web form,” has given little or no thought to the business rules and validations that must back it up, let alone to the route that the form will take through the business once it is completed.
From a forms manager’s point of view, there are various degrees of complexity with an online form:
1. Print-on-Demand (POD)
Essentially, paper forms that are made available electronically. The most familiar technology is Adobe’s PDF. Users print the form for filling in manually. The main user benefit is that the form is available immediately. The main organizational benefit is that the form does not have to be printed, stored, or sent out to the user. There is no obsolescence cost if it gets updated, and only the current version is available to the user. POD forms save organizations a lot of money, but the user still has to print and send in the form. POD forms also have the disadvantage that the organization is likely to receive a lot of handwritten forms, which are harder to process. Despite their problems, POD forms can still be a good solution for getting forms to people who do not have their own computer but can get someone else to print out a form for them to complete later.
2. Fill-and-Print (F/P)
These are an improvement on POD forms. The user fills in the form online, then prints and sends it in. There is usually a tab order, some field restrictions, some masking, and special fields such as checkboxes and simple dropdown selections. These forms provide the same advantages as POD and are easier to fill out, more legible, and contain fewer errors. These forms are often a good solution where the organization requires a real signature, or the user has to attach another document that may not be electronic.
3. Intelligent Electronic Forms (IEF)
These forms have more intelligence, such as calculations, conditional fields, logic choices, logon access, hidden fields, and help messages. They are truly online from the user’s perspective, but data collected is not integrated with enterprise applications. Many ordinary web forms fall into this category by accident: the organization has thought about how to collect the data, but not paid enough attention to what to do with it when it arrives within the organization. IEFs do work well, however, as a further improvement on F/P forms for forms with complex internal routing.
4. Enterprise-Enabled (EE)
These employ email connections, database connections, secure access, intranet/internet access, usage tracking, edition control, ecommerce connections, electronic signatures, and other enterprise features. They can eliminate or reduce paper from the process, improve productivity and customer service, and eliminate or reduce filing.
5. Complete Business Applications (CBA)
A full CBA typically employs multiple forms and sub-forms in an integrated business solution. It may have a mixture of IEF and EE forms pulled together into a system that routes forms from the user to the different parts of the business as needed. CBAs require custom programming to build business rules and logic into the forms set. A CBA has the potential to save costs across a business, eliminating paper and duplicate keystrokes, and making sure that the data gets to the people who need it. The overall complexity of the forms is also reflected in the complexity of the development process for the forms: the tools to create them, the amount of programming required, and most of all, the level of understanding of the business processes required.
Keeping Control
Because forms affect so much of a business, forms managers think a lot about controlling the forms. They don’t want a carefully established business process undermined by an unofficial form that does something different. It could well be that there is a need for a change to the “official” form, but this should be brought to the forms management team and built into the system.
We forms managers have a fear of “bootleg” or “rogue” forms. To be really effective, an organization needs to have a forms management strategy so that all forms used within an organization are regularly reviewed for obsolescence, effectiveness, retention, and compliance with security and privacy policies. Bootleg forms represent risk to the organization in many areas, including compliance, efficiency, and cost.
Any forms management professional can regale you with horror stories of organizations where all the forms are bootlegs. These will be the ones where nobody knows which version of a form to fill in; where different departments have competing forms; or where customers are continually bothered by emails or telephone calls that try to patch up the problems in the data collection process. And often there are hundreds or thousands of them. Forms managers have a rule of thumb: without a forms management strategy, the number of forms in use will be approximately equal to half the number of employees. Think about all the duplication and confusion that can represent!
Are Your Web Forms Under Control?
As a forms manager, I often help organizations create enterprise-wide forms management strategies that include plans for development, deployment, support, software standards, output strategy, and management reporting and cost benefit requirements, including return on investment (ROI).
Here are some of the things that you should look for when creating such a strategy:
Development
What departments and individuals have forms development responsibilities? Can anyone create and publish, or is there an appropriate process in place for creating and revising forms, declaring forms inactive or obsolete, and assigning control numbers? What happens if multiple versions of a form are needed, for instance, for different states within the U.S., or different languages? Who ensures that the various approvals (legal, regulatory, marketing, etc.) are obtained? Do the developers have the appropriate development tools and information technology infrastructure, such as database access, server scripts, networks, and email compatibility?
Deployment
How does the form get published? Technological issues to look for include email support, servers, and forms portals. This is also where you should start investigating the issues of user experience: user interface, submission of forms, and security requirements are all crucial when we start thinking about deployment.
Support
What happens when something goes wrong? Consider issues such as user training, help desk support, instruction manuals, user guides, and designer training.
Software standards and style guides
It’s almost unheard of for an organization to have just one form. So when creating a forms management strategy, look for what the organization is doing to ensure that forms are built using appropriate tools and in appropriate ways. Consistency for users is important, but it doesn’t happen easily and it is particularly hard when the forms are being built using ad-hoc tools that were never designed for that purpose (Word, for example). As a forms manager, I would never recommend using general-purpose office software to design forms. You would not expect your programmers to develop in Microsoft Word; forms designers need the same consideration.
Output strategy
What happens when the users have filled in their forms? In the early days of web forms, we learned very quickly that users must be able to save and print their work or they simply will not use the electronic form. This is particularly true for the public doing business with your organization, but it also applies to employees. We generally think in terms of paper being unnecessary (after all, they are electronic forms), but this issue has stopped more than one electronic forms strategy. Users want what they want!
Management reporting
Make sure the forms management strategy includes all statistics necessary to determine who uses the forms, how often each form is used, how long it takes to develop and maintain, how many user requests for enhancements there are, and anything else that can be easily counted and might have an impact on the overall efficiency of the organization. You cannot manage what you do not measure.
Cost-benefit analysis
This element is crucial to the long-term success of any strategy. For each form, the expected development and maintenance costs should be compared to the expected cost savings, including productivity improvements. You can then calculate ROI, including expected payback period.
Are Your Web Forms Part of an Effective Workflow?
Forms managers look on in disbelief at some of the arguments we see about features of web forms, like the best “required field” indicator or the position of the labels. These details do matter, but not nearly as much as making sure that the form is part of an effective workflow. Making a badly designed printed form an electronic form just means getting bad results quicker.
Understanding your business processes is critical to developing effective forms. Forms must fit the process, not the reverse. We recommend at least an annual review of each business process and the forms that support them. This staff function will generally pay for itself many times over.
Here is one example of the things that we check for when reviewing a business process: signatures. Signatures on electronic forms are still a very thorny area. Here in the USA, the Electronic Signatures in Global and National Commerce Act (2001) made electronically generated signatures “legal,” but there is a big difference between being legal and being accepted as evidence in court. Signatures must meet at least two tests:
- Authenticity: Is the signature the authentic signature of the person it purportedly represents?
- Non-repudiation: Did the person signing intend to enter into the transaction represented?
Also, the document containing the signature must exactly represent the transaction as it occurred.
Many business processes require a signature. You need to consider the requirements for signature capture, both for external forms as signed by the users, and also as the form is dealt with internally. This requirement will vary for each form based on the value of individual transactions and the potential for loss.
Web forms bring a further complication into the matter: the substitution of a username and password combination for the authentic signature. In the U.S., we have not yet seen what the courts make of this new type of authenticity, nor have we seen whether username/password plus a “confirm” button will be regarded as enough for non-repudiation.
Generally, signatures can be more casual for low value transactions or where customer denial of the transaction is not likely. For larger value transactions such as insurance applications, or frequently contested transactions, such as beneficiary changes, the signatures must be more secure and non-repudiation measures are more important. Most worryingly, we see web forms being released constantly in “internet time” without any sort of reference number or release control. How will organizations be able to prove which transaction happened on that exact date?
Organizations often take good care of the form data (whatever is collected by the form) but make little effort to keep control of the form container (the part that collects the data). Form data is generally stored separately from the container. This requires that a specific association be created between the container and the data, so the transaction can be recalled and displayed appropriately. As the container is revised and new additions created and deployed, the data display will change. Accordingly, all editions of a container must be maintained and accessible, with data mapped to the original container. Good forms software provides for this mapping automatically, but many organizations are using “write your own” HTML or other technologies and give no thought at all to how they will control their forms containers.
Paper, Web, and Other Electronic Forms
If all this seems too much to think about, then remember that not all forms need be developed with all requirements intact. Do not over-engineer a form. Include only those features necessary to the workflow and avoid costly, over-technical solutions. Remember, paper is not the enemy. Paper is but another technology available to the professional designer. When electronic solutions become problematic, take the form to paper.
A good example is a form that provides a confidential PIN to a customer. Communicating the PIN electronically can introduce considerable risk, where a self-mailer product can resolve the problem simply and perhaps at a lower cost.
Summary
What may start as a simple requirement—“I need a web form,”—may end up with an enterprise-wide effort to understand, develop, and control the forms.
To create really good forms, you need to think across the enterprise and consult with all major departments to assess fully their requirements, needs, and preferences
