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:

1. 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.
2. Do secure the form -- This is a no-brainer. All elawyering questionnaires should be secured with 128/256 bit ssl encryption
3. Do use in-context help and guidance -- For more complex questionnaires, it is best to implement a help system within the questionnaire
4. 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.
5. 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
6. 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.

So what are we really talking about when we mention automated document generation in elawyering or virtual law office applications? The answer is not a simple one. Based on the various blog posts that I have read on the subject, and the public information of companies who provide this service, I conclude that it does not have a central definition.

My Take

I admit that I have been less than enthusiastic about the prospects of automated legal document generation in the past. I have worked in a number of positions where I have developed various forms of document automation processes. Unfortunately, all of these processes involved some type of database field merging. Database field merging in its basic state is rigid and unintelligent. Basically you set up a document template, designate existing merge fields (which exist in a database table or view) and initiate the merge process. Using a mail merge based approach to legal document generation almost always involves "cleaning up" or refining the document in some way. To make matters worse, most giant law office database applications have these archaic and  weird predefined merge fields used to extract information from the database. More often than not, i opted to create smaller more efficient databases with user-friendly merge fields.

The Future of Automated Legal Documents

This blog is all about shaping the future of the online delivery of legal services, and document automation is included in that vision. Although I do believe that there are some worthy alternatives to mail merge document generation out there, I have not yet seen any truly robust systems. Of course I don't know how every company's technology works, but I really don't need to.

For instance, Wizilegal is a company that claims to be the most cutting-edge provider of SaaS automated legal document software. They have very little information available pertaining to the inner-workings of the software. I don't even know the output of the generated documents. What I do know is they require the attorney to upload their documents. Next, the software will generate documents? Yes, it is confusing. I guess there is no wonder that their most recent blog post was in September 2009.

The future of automated legal document assembly has about as much to do with traditional mail merge as this blog has to do with typewriter maintenance. :-)

The Role of the .PDF

I really like .pdf documents. However, I think they have been miscategorized in their intended role for automated legal document solutions. A .pdf is great for what it is, a portable document format. Because of its long tenure in the world wide web, it has become the standard for shuffling documents through cyberspace. The King County Superior Court in Seattle now requires attorneys to electronically file documents in .pdf format. I think this is great. The problem is that .pdf files are not particularly suited for pure automated document generation. I'm sure it works for some people, but it is not ideal.

Conclusion

The future of automated legal document generation is all about file format. What type of file format can be best used to completely generate legal documents on the fly? The idea of mail merge definitely has a place in automated legal document generation, but only the idea. The future I envision detaches us from our desktop programs and thrusts us into the cloud where virtually anything is possible. I'm excited about the possibilities!

If you've been following the development of ABIEE™, you know that I am in the client use development phase. Due to intellectual property concerns, I cannot disclose specific information relating to the design of the database. Generally speaking, the database design portion of an elawyering application should be given a tremendous amount of attention. Any elawyering application worth using is heavily databse dependent. The more features in play, the more complex the database will be. For ABIEE™, I am breaking down the database design process into two separate parts. One part is for the client/user portion of the application and one part is for the bankruptcy professional's portion of the application.

Data Integrity

The databse should be designed to ensure optimal data integrity and performance. Elawyering application databases are especially tricky because of the need to integrate document generation and processing requirements into the database.

Utility Database

One more complexity involved in an elawyering application's internal structure as it relates to database design, is the need for a "utility database" section. This is the term I use to refer to attributes that will not necessarily be a part of the central database. Some examples are profile information, account information, some personalization information, etc.

What follows is the client registration use case for the ABIEE™ (Alliance of Bankruptcy Information and Expert Exchange). If you were following the previous related post, you will see that the client registration use case specifically builds upon the global client use case. Before the client can access any major features of the application, he/she must register an account. Although it is possible to allow anonymous browsing and functionality, up front registration makes the most sense.

The Registration Process Overview

Basically, a client will complete a brief and painless registration form. When they click submit, pertinent data will be entered into a database table. Next, the client and the site administrator will receive notification of the event.

Developer's Perspective

The programming portion of the registration use case is fairly straight forward. Once the client enters information on the form and clicks submit, logic will be written to add that information to a database table. Additional code will be written to confirm the registration with the client. Finally, code will be written to notify the site administrator that a new user has in fact registered an account.

Designer's Perspective

The eventual graphic design of this input form will reflect the overall look and feel of the application (the graphic design will come much later in the process). The focus should be on modern design techniques with an emphasis on usability.

Marketing Perspective

At this point, it is important to realize that the client has an open mind and may be interested in additional services/offers. One thing that I will add here is an opportunity to opt-in to marketing  communications such as newsletters and special offers. One more marketing feature that I will add here is an opt-in for a printed information packet of some kind.

Conclusion

Once the client is registered we will have non personally-identifying identity parameters to use for future programming, design, and marketing implementations.

Client_Reg_UseCase.pdf (143.40 kb)