When designing digital processes, you will often have to interact with, or perhaps design, webforms, otherwise called questionnaires or interviews. By ‘webforms’, I mean interfaces where a user answers a series of questions which are then used to drive another process – such as generating a document or managing a transaction. You can use webforms to collect any kind of information in a legal setting – from timesheets and personal information to live project data.
At echo.legal, we have been designing webforms to be used for document automation for years and understand that there is a direct correlation between the design, or thinking, that has gone into creating the webform, and the quality of answers that users enter into it. This is because a good webform should anticipate the kind of information that will be entered in it and make the process as easy as possible for the user. This is what drives many of the efficiencies in using it in the first place!
This is also where some projects stumble: the first impulse is often to make a webform as open as possible, where users can enter any kind of answer, to ensure that edge cases are caught. This often manifests as ‘plain text’ fields – questions where the user is presented with a blank field where they can enter any value.
While it may seem practical, over-using plain text fields can lead to some problems down the line, for you; the creator of the webform, for the users, and for your clients. In fact, most systems allow for a wide variety of field types: for example, see column Types for HighQ or data types in DocAssemble (an open-source document automation system).
Here are some reasons why you should avoid using plain text fields and consider whether other field types may be more appropriate: to avoid mistakes, allow more opportunities for processing, and improve reporting.
Avoiding mistakes
It is worth considering whether the answers to a specific question are required to be in a specific format, either by the nature of the data collected, or because of the nature of the project. For example, if you are collecting phone numbers, they would usually take a specific format – i.e., a country code followed by a series of numbers.
Where the kind of data input is fixed or should follow a pattern, consider providing guidance with an example of what the format would be. Also, check if it is possible to enforce the formatting; for example, some webform software allow you to enter regular expressions or similar ‘masking’ methods which are used to compare the answer with a predefined pattern and alert the user if the pattern does not match.
This could be driven even further by predefining a list of options using a ‘choice’ field. For example, when you need the user to specify a monetary amount, and you expect the form to receive multiple currencies, it may make more sense to provide the user with a predefined list of available currencies and ask for the amount in a separate question. This avoids common mistyping errors, like someone typing ‘GP’ instead of ‘GBP’. This will also benefit you down the line when it comes to processing and reporting on the answers received.
Processing
The answer input by the user is likely to be only the first step in a calculation. For example, you might want to execute a currency conversion calculation depending on currency amounts collected, set up reminders for a certain deadline, or send out alerts if an entity is based in a certain jurisdiction.
While this is possible to do with plain text fields, it makes processing a lot harder as you would need to make sure that the answers all follow the exact same format. Instead, for the examples above, using a combination of a choice field and a text field (for currencies), date fields (for deadlines), and a choice field (for jurisdictions) allows for straightforward processing, which can in turn drive more useful ‘process’ automation.
This is where you start moving beyond ‘point’ solutions, where you are filling out this webform to get a document, to more integrated solutions where, by filling in a webform, you generate a document and alert relevant individuals that the document has been created and set up reminders and execute calculations from the information entered.
Finally, using appropriate field types for the task at hand can also massively help with formatting. Your organisation or jurisdiction may mandate that, for example, dates are formatted in a specific way. Webforms which collect date data (rather than plain text) can automatically format the output to correspond to that style – resulting in consistent outputs and less need to check for routine errors.
Reporting
A key benefit of using webforms, aside from the immediate output (be that a document, an email, the creation of a reminder etc) and resulting processing options, is that all the answers are aggregated, allowing analysis of answers provided across multiple uses of the form.
This is where using plain text fields could hinder your results. For example, imagine a currency question without any kind of data validation or pre-defined options. Here are some ‘valid’ answers, all describing the same amount:
£ 1,000.00
£1000
GBP 1000
1000 GBP
one thousand pounds
£1K
Imagine then having to plot these answers in a chart. Even assuming all the amounts are in the same currency, you would need to spend time making these results consistent before you could compare or summarise them meaningfully. On the other hand, enforcing consistency in answers through your question set up you could even produce real-time reporting, where data is aggregated automatically and shown to management or client users, through a dashboard.
Conclusion
If you are designing webforms, it is vital to keep in mind the additional value that can be unlocked by taking the time to investigate all the options that the system you are using allows. It can benefit your users in terms of a smoother experience, you as developer in terms of collating and processing answers, your management in terms of being able to generate better reports, and the business as a whole by being able to flag overdue items or alert risk teams of edge case transactions automatically.
Although it can be tempting to leave webforms as open as possible from a speed of development and flexibility perspective, as with so much of this type of work, a balance needs to be struck between flexibility, usability, and business requirements to ensure i) the best experience for users while achieving ii) a high RoI and iii) a quality end-product.
Well thought out validation can take your data to the next level - have a go at implementing some of these tips in your next webform!