I just finished up an intake questionnaire for my freelance paralegal site. The questionnaire is part of an information collection system that I am building. As I was completing the questionnaire I remembered the important role that well designed/engineered questionnaires play in an elawyering application.
The Approach
In my view there are two basic types of elawyering questionnaires that may be implemented. The first is one that will be used as a tool to collect information for manual back-end use. For example, the intake questionnaire that I developed will be used as a tool for manual document preparation. The second type of elawyering questionnaire is used as a tool for automated document generation. At this point, the ultimate goal of the questionnaire is not as important as the functionality and the usability of the form.
The Data Requirements
One of the first things that I do before I begin developing an elawyering questionnaire is to look at the data requirements. These requirements will vary depending on the ultimate goal of the questionnaire. I'll focus on the first type of questionnaire for now, that is the questionnaire whose collected data will be used for semi-manual document preparation.
One of the easiest ways to evaluate data requirements is to look at the forms that you'll be using the data for. For example, Washington State has a Confidential Information Form that is required for every case. This form collects basic personal information such as name, address, d.o.b, employment information, etc. The information for the petitioner/plaintiff and the respondent/defendant is required (if known).
Database/Table Design
The data requirements for these types of questionnaires can throw off a purist style of database design. The problem is that each database table will store various types of information which may or may not be logically related. I tend to create a separate database table for each major form. This way, the contents of the table describe the subject of the table (the form).
User Interface
The usability of the questionnaire is crucial. Legal documents require a lot of information, most of which is complex and tedious. My goal is to make the process of supplying this information as painless as possible. Of course, the more usable the questionnaire, the more work involved in the engineering and design. Here are a few user interface guidelines that I use for all of my elawyering questionnaires:
- Don't stuff everything on one page -- Because of the length and complexity of elawyering questionnaires, it is best to break the process down over a series of steps.
- Do secure the form -- This is a no-brainer. All elawyering questionnaires should be secured with 128/256 bit ssl encryption
- Do use in-context help and guidance -- For more complex questionnaires, it is best to implement a help system within the questionnaire
- Do provide progress indicators -- People like to know how far they've gone and how much they have left. It is best to implement a graphical progress indicator of some type.
- Do allow saving -- The questionnaire should have an easy save mechanism. Furthermore, the user must be able to start again from their last saved point
- Do store responses in a database -- The information collected from the user should be stored in a database for later use in the actual documents
Functionality
I could go on forever about the various ways to add functionality to your elawyering questionnaires. The bulk of the decisions and preferences regarding functionality will be technical decisions made by the engineer. Of course, elawyering questionnaires are unique insofar as they require extensive practical knowledge pertinent to the target area of law. This knowledge should be translated into a highly efficient and intelligently engineered product.