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!

This is part 2 of series on building the elawyering application ABIEE™. You can find all related entries by selecting "ABIEE" in the category list.

Portion 1: The Software Requirement Specification for client/consumer users of ABIEE™

In entry 1, I roughly outlined most of the features that I envisioned ABIEE™ containing. I also mentioned the size and complexity of the task at hand. Finally, I noted the fact that I would break the development and design process down into manageable chunks. I decided to start the development/design process by outlining the Software Requirement Specifications (SRS) for the client/consumer portion of ABIEE™. You can see a preliminary list of the features for the client in entry 1. The following list is more refined and should be considered the official SRS for the client/consumer portion of ABIEE™. of course this list is also subject to change as the elawyering application development/design process progresses.

Official Software Requirement Specification for the Clients/Consumer Portion of ABIEE™

Pre-Filing Stage

1. Unregistered clients can browse library of resources (RL  SRS Pending)
2. Clients must register and login for additional features
3. Clients can organize case related documents that the BKP will need for document generation (BKP SRS Pending). Case related documents include scanned (.pdf or .xps) versions of documents such as bills, tax returns, etc.
4. clients can view the documents they have uploaded
5. Clients can send documents to BKP when necessary (BKP SRS Pending)
6. Clients can build a personal library of resources and use standard methods to manage their library such as add, delete, and sort (RL SRS Pending)
7. Clients can follow a process checklist which will guide them through the appropriate processes to completion of BK case (intermittently updated as development progresses)
8. Clients can browse information about BKP such as BKP supplied BIO, experience, etc. on public BKP list)(BKP SRS Pending)
9. Clients can inquiry/message BKP they are interested in hiring (BKP SRS Pending)
10. Clients can hire a BKP and complete retainer agreement/service agreement (BKP SRS Pending)
11. Clients can submit payment to BKP (BKP SRS Pending)
12. Clients must submit case review/means test to hired BKP (BKP SRS Pending)
13. Clients can receive case review/means test result from BKP ((BKP SRS Pending)
14. Clients can receive completed document copies from BKP(BKP SRS Pending)
15. Clients can inquiry/message BKP they have hired (BKP SRS Pending)
16. Clients can create reviews for BKPs they have hired (BKP SRS Pending)
17. Clients can complete questionnaires for later use in document generation.

Post-Filing Stage

1. Clients can have case-level calendars updated by BKP (BKP SRS Pending)
2. Clients can receive standard built-in information about upcoming hearings

Note: BKP = Bankruptcy Professional -- RL = Resource Library

I want to briefly discuss an important part of every e-lawyering application, the questionnaire(s). I have seen my fair share of questionnaire implementations. Most have been in various online legal document sites, the bulk of which are uncontested divorce document sites. If you do a search in any major search engine for online divorce, you will see a massive quantity of so-called online divorce sites.

Why the large amount of uncontested divorce sites?

This is a good question with a simple answer. Programming an uncontested divorce questionnaire is very straightforward. First, everything is pretty much static. This means that a paper-based intake questionnaire can easily be transformed into a semi-functional electronic questionnaire. The same was true for the proliferation of bankruptcy document preparation sites a few years back. Most of these sites require an uncontested situation because it keeps things very simple. More importantly, an individual does not need a fundamental and working knowledge of the law to throw up an uncontested divorce site. This is literally a job that can be handed off to any programmer.

The difference between questionnaire-based sites and elawyering apps

The elawyering applications that I envision do rely on questionnaires. However, these questionnaires are far more advanced and intelligent than your run of the mill divorce document site. This is where a true elawyering applications becomes far more useful than a typical do-it-yourself product. The highly intelligent questionnaires that I am referring to are a infused with deep legal knowledge. These questionnaires are a product of advanced programming and design techniques. The questionnaires of the future anticipate the client's issues, inform the client, and are developed to provide a rich client experience.

More than uncontested divorce

The next-generation elawyering questionnaires can serve multiple client personas from one interface. Not only can they do simple things like collect information for an uncontested divorce, they can do things like walk a customer through a complex child support matter.  On the back end, the questionnaire compliments the interaction of the legal professional. In other words, your questionnaire will allow you to gather pertinent information, be notified of any major issues, integrate your marketing strategy, and deliver personal assistance to the client. As you can see, this requires a much more advanced programming model than a simple conversion of paper-based intake questionnaire into electronic form.