So, you want to create your first interactive legal application (sometimes also called guided interview or wizard). Congratulations!
Whether your app is the next TurboTax for drafting wills or an access to justice app for pro se debtors, it helps to understand the components of your app. That’s true whether it’s something you’re building yourself or outsourcing. This will be the first in a small series of blogs about getting started in interactive legal app building. I’ll focus on step-by-step apps that walk a user through a legal process and deliver advice, an intake, or a completed form at the end. Part 2 is now up: Should you build a legal app?.
For the most part, these concepts are the same whether you are using Docassemble, HotDocs, A2J Author, Contract Express, or any of a number of different platforms. Of course, they also hold true for platforms built on Docassemble, such as Documate and Community.Lawyer.
Most interactive legal application projects involve these basic components:
- Host website/splash page
- Interview
- Template
- Cover page
- Logic
- External data, which includes
- API integrations
- Interaction via text/email
- External databases, spreadsheets, and the like
- Visual design, including CSS and interactivity created using JavaScript
The Big Picture
Every legal app development platform uses the same high-level components: the Interview and the Template (or other output). Most also offer two other possible components: code, and external data.
The template often starts out as a legal form in the real world, while the interview plays the role of an advocate assisting a client. While the interview usually requires a dedicated server, a client discovers or accesses the interview from an existing host website.
The Host Website
Most people choose to host their interview in a parent website and to launch it from a splash page. The host website has more room for explanatory text, matches your organization’s branding, and is more discoverable through search. It has a web address that is easier to advertise, too.
The project owner will usually be responsible for either adding a new page to an existing website on their own, or working with a web developer to develop this splash page.
The Interview
The interview is the interactive part of the legal app. You can think of it as a flowchart brought to life. It contains questions, help text, and logic to show the questions in the proper order.
A developer often builds at least a working prototype of the interview before integrating it with a template. A prototype will let you test your assumptions, refine any ideas about ease of use, and work out a structure for the code that will be maintainable. Internal elements like variables and data structures will be in flux at this point. This will also let you validate the legal logic with subject matter experts before the developer gets too far.
Separate from the splash page on your existing website, most interviews start with a brief orientation screen and end with instructions for next steps. In the middle lives all of the implicit knowledge that an expert lawyer uses to help a client fill out your form. The goal of the interview is to break the form down into easy to understand factual questions. This is the meat of the collaboration between the subject matter expert and the developer: translating law into step-by-step instructions.
The project’s client, project manager or owner will often come to a developer with a basic outline of the interview. This can be a diagram, a step-by-step document with text for each screen and a description of which option will lead to which follow-up, or just rough notes. This outline is always a starting point and will go through revisions throughout the project, so if it’s incomplete, it’s usually not a reason to delay a project. The best approach is to have a rough outline and to have a subject matter expert who can both walk the developer through the form and be available for follow-up questions.
If there is no interview outline, and there is no subject matter expert on the project owner side, the project will have wasted time on blind alleys and delays while waiting to ask clarifying questions.
It’s best to include an expert on the project owner’s side, ideally someone who has worked with clients to fill out the form. Hiring a developer with experience as a lawyer or paralegal is also helpful, even if it’s in an unrelated field.
The Template
The template is the the final output of your application. Most often, your app’s output will be a PDF, Microsoft Office document, SMS or Email. These all contain formatted text that will be delivered to a human to read.
Usually, your template should include a page of customized final instructions for the user to review once they have printed their document, like the one below. This page should reinforce a message given throughout the interview, and especially on the download screen.
The subject matter expert will usually provide a template with any word-smithing and design done in advance. This does not need to be a final draft. Changes can be made as needed. Templates contain some logic too: logic can be used to display a list of items in a table or bullets, change gendered words to match pronouns, and to show and hide text based on conditions.
Typically, PDFs are the most difficult types of templates to work with. This is both because text needs to fit in the box that the original form designer provided, and because PDFs usually can’t have any logic inside the template. Instead, the logic has to be done in the interview. Lists of items in particular are harder to work with in this format.
The project owners should understand what kind of output is required and provide clean original copies of the form, preferably in Microsoft Word format. Sometimes Microsoft Word versions of PDF forms can be obtained by contacting the court’s forms committee.
Sometimes, there is no template. Instead, your app may use an API to deliver information directly to a database or other endpoint, such as a Case Management System (CMS) or Electronic Case Filing system (ECF). In these cases, the project owner should make sure that they have access to any public APIs that are part of the CMS or ECF.
Code / Logic
Code is a helper to make an interview more easy to maintain and to save the user effort. Sometimes code relies on externally maintained data sources. For example, matching an address to a court can save your user a lot of time and reduce errors. Most larger interviews will benefit from custom code that makes it easier for the programmer to work with and make changes to the interview as the design is iterated.
The project owner should think through any special calculations that the form will need, but this section is otherwise mainly the responsibility of the developer.
External Data
Many projects benefit from connecting to external data. In my past projects, this has included using Google Maps to auto-complete an address, pulling office locations from the Social Security Administration, and data sources such as CSV/Excel, Google Sheets, and Airtable. Think in advance about where information your app could use lives as well as information you may want to put in a database to make it easier to maintain.
In some platforms, including Docassemble, your app can talk to your users when they are finished using your website. You can send SMS and Email messages to your users, or even have an interactive interview that’s run over SMS or Email.
Access to external data is limited in the platforms mentioned, excluding Docassemble.
Project owners should think broadly about the process that’s in place now, and consider if integrating external data can save the user time, improve accuracy, reduce burden on the organization, or improve the user’s success. One time consuming step in one-on-one consultations is the follow-up call. Can sending automated information help reduce those calls or improve the client’s success? The developer will help the project owner understand if an integration is possible and can be done inside the project’s budget.
Visual Design
Visual design is an important component of any project. You may have branding requirements, such as corporate colors. You might want to make an app that looks friendly and approachable, or formal and official. Choices of fonts, color, and the placement of optional visual elements such as images and videos can reinforce your app’s fit with your audience. Many platforms can customize these elements with “stylesheets” or CSS. Hints of interactivity, such as auto-formatting numbers, can also be an important part of the design. These will typically be achieved with JavaScript.
Design should be directed at both your desired audience and the final usability of your product. “Flash” for the sake of flash rarely improves usability, but that doesn’t diminish the importance of design.
Design options might be limited on some platforms. Docassemble, Documate, and Community.Lawyer offer very flexible design options, as do custom built apps. A2J Author may allow customizations when self-hosted, but not on the LawHelpInteractive platform.
Your developer’s design experience is enough for most projects, but sometimes it makes sense to bring in an outside designer, or to work with your organization’s existing brand or design consultant. Project owners should be ready with any design requirements that may come from your organization’s branding guidelines.
Conclusion
Knowing the basics of interactive legal applications can help you plan your project. Hopefully you’ll also better understand any quote that you receive from a vendor.
If you would need support with your custom legal app project, I’d be happy to help you at Lemma Legal Consulting.
Next up in this series: should you build a custom app? I’ll also cover branding, UPL, and gathering feedback from users and stakeholders in coming weeks.
0 Comments