So you're going digital, get all your instructions online from the business, maybe even roll out a front door or a CLM. Nice. The form is easy, right? Find all the gotchas in one document. For easier reading, we have also included a downloadable PDF file below.

‍

Online Intake Forms: lessons learned

There comes a time in every legal team’s development when they decide that requests for assistance must be sent via an online system. It’s a natural progression from using an existing document or email template, or it may be a jump from allowing the business to email their favourite lawyer. It could be part of rolling out a contract lifecycle management (CLM) platform or part of a legal front door that covers more than contracts. 
‍

Whatever the background, creating an intake form is not as simple as it may appear.

The joy of forms

Forms are terrific. You can ensure that you get exactly the information you need (they act as a checklist), you can validate answers (helping make sure data is correct), and you can take control, finally, in how you receive instructions.

‍

But there is a problem. 

‍

Not one of your business users wakes up in the morning eager to start filling in forms. You are also forcing the user to think about what they need. This is uncomfortable; the old hand waving was a lot easier. You are making your team’s lives easier, you are making the overall process better, you may even apply for an award (although this is getting stale, even for legal innovation awards), but you will be annoying your internal clients.

‍

Huge effort is required to create a usable form. You should make that effort, but the result can still only be a less annoyed user. You can make it as pain-free as possible, but it will never be a pleasure. And no one will truly understand or appreciate your efforts. Accept that as your destiny.

‍

With these motivating thoughts in mind, how do you create a good intake form?

Designing the form

The questions

You should agonise over your questions:

‍

• Everything you need: the form needs to be complete, in that you should not need to ask any follow-up questions to complete the first stage of the work, at least for the common work-types.

• Minimal number of questions: despite that, you should only ask the questions that are relevant to the work that needs to be done. So you should be using conditional questions - questions that only appear when relevant, depending on answers to previous questions. Avoid unnecessary questions where the answer is already known (e.g., the company number of a group company).

• Short, clear questions: the questions should be as short as possible. Every word you add slows down the user and adds “cognitive burden”. Try not to use more than seven words. Use terminology that the user is familiar with.

• Explanatory notes: add notes only where needed, but again keep them as short as possible. Your goal is to never need to give training. Explain where a user can find information if it is not obvious. 

• Logical ordering: the questions should appear in a logical order. Err on putting the easiest questions at the top.

• General question at the end: you should have an open question at the end to allow the user to provide relevant information that you hadn’t envisaged when you created the form.

• Every question should be mandatory: in order to know that you have all the answers, every question should be made mandatory. The general question at the end should be a mandatory “Is there anything else we should know?” with a yes/no answer that reveals the text box.

The fields

You should agonise over the field types and other form elements that you use:

‍

• Text fields v text boxes: use a text field for a single line of text. Use a text box (text area) if the text is likely to be more than a few words.

• Checkboxes v radio buttons: check boxes are for when you can select more than one option. Radio buttons are for when you can only choose one option. Do not use a single checkbox on its own as you won’t be able to tell if it was overlooked. Do not have a default option on a radio button as you, again, won’t be able to tell if it was overlooked.

• Dropdowns: dropdowns save space but make it harder for the user to see all options. Only use dropdowns if you have more than four options. Multi-select dropdowns are also fiddly to complete, so try to use checkboxes where you can.

• Data validation: use date fields for dates, number fields for numbers etc to help ensure that the data is entered accurately. Where it needs to be entered in a very specific format, use specific rules for data validation.

• Avoid placeholder text: don’t use placeholder text in the form unless it’s the only way to show notes with your software. It tends to confuse users.

• Progress bars: the user should know where they are in the form. If you split the form into multiple pages, include a progress bar.

• Action buttons: action buttons should appear at the bottom of the form. The label on the action button should be meaningful and not “Submit” - what is going to happen for the user when they click it? 

User testing

You have no idea what your users will find confusing. However much time you spend perfecting your form, as soon as it is in the wild you will have stumped users. The only solution is to do extensive user testing, and not just with your lawyers. Get typical users to fill in the form and just watch them (using shared screens if necessary). Watch where they get stuck and ask them to talk through what they are doing as they do it.

‍

You will uncover issue after issue, so assume that you are going to run an iterative process until a new user (so you need multiple test subjects) can fly through it (and see below for ongoing changes).

System requirements

The minimum

Given the points above, you need to be careful that the systems you are considering have all the features you need. This is the first of the major gotchas, because many systems out there are missing some of these:

‍

• Input types: the software must be able to handle the following:

• Text field
• Text box (text area)
• Radio buttons
• Checkboxes
• Dropdowns (both single-select and multiselect if you have long lists)
• Dates
• Numbers (both integers and decimals)
• Attachments (with multiple files)

• Conditional questions: you must be able to turn on/off questions depending on previous answers.

• Mandatory questions: you must be able to require the user to answer each question before submitting. Conditional questions must also be capable of being made mandatory, only when they appear.

• Notes: you need to be able to add explanations.

Other points

There are other features and topics that you should consider:

‍

• What happens next: how is your team going to receive the instructions? How are you going to track its progress? Who is going to do triage (or will you automate with rules)? How will it be allocated? As tempting as it is, sending the form into a black hole is not a long-term viable strategy. 

• How the form looks: forms are bad enough without being ugly too. Is the software beautiful? If not out of the box, how much control do you have over how it looks? This is a double-edged sword, as good design skills are rare and corporate powerpoints attest to how dangerous it is to give users the ability to change look and feel… but are you doomed to a hideous experience?

• Proliferating tickets: even the best forms don’t get answered perfectly every time, so consider how you address the back and forth with your business users including asking for more information. Will this happen within the system? Watch out for multiple instructions if you are asking the user to update data (and does the system even allow for updates?), and consider how you are going to handle the inevitable duplicates. 

• Structured data: you will probably want to analyse the data to see what is happening so consider how easy this is to do in your system and how you can export the data when you have new questions.

• Integration: you will also want the possibility of sending the data to other systems.  Consider how this could be done, but also see below for more on the issues that come with integration.

• Data location and security: Obviously, you will need to consider where the data is processed and stored (for data protection reasons) and, if it is hosted by a third party, whether the system you use has ISO27001 and/or SOC 2 type II certification.

The gotchas

We talked about system features above, but we have seen contracting improvement grind to a halt for other reasons. This is the stuff that your consultants may not warn you about:

Forms are not projects

‍

It is a common misconception that creating an intake form is a project that comes to an end. This is not how the world works. First, however much you test the form, issues will come up. Second, there is always room for improvement. You should be running a continuous improvement process that is always exploring new and better ways for this stage, and all the other stages, in your contracting process. Third, your organisation will change. Often.

‍

You therefore need to consider how you can keep improving the form. If you’ve hired someone to set it up, will they be available to make changes in the future? Have you budgeted for ongoing support? Will you be able to get changes made in days not weeks (or even months, if at all)?

‍

If it’s being done internally, will the person who set it up always be available to make changes? Can someone else help?

Curse, train, or improve?

How do you find opportunities for improvement? This comes down to how you respond to failure. When the form isn’t completed correctly, do you blame the user, fall back on mandatory training courses, or dig deeper into what is going on and figure out how the form can be improved? Points which might trigger your inner detective:

‍

• incomplete answers, including users getting around mandatory fields by inserting spaces,

• incorrect answers or the wrong documents being attached, or

• instructions changing after the lawyer digs in to do the work.

‍

Perhaps also talk to the users who are getting it right? How could it be made even easier for them? Stay curious!

Impact on suppliers

If you have an existing supplier who updates the current form, you may not realise how many tweaks and improvements they are making. If you prevent them from being able to make improvements, you remove their ability to experiment and improve things for you. Consider how changes will be made in the future. How will improvements get raised, how will they get prioritised? How do you encourage everyone to be curious?

‍

Yes, we harbour strong feelings about this point.

Integrating systems

Having clean data nicely passed between systems seems like a terrific goal. But consider this: if two systems have to change when you improve your form, then you have exponential complexity and cost in making changes. You will potentially need two sets of developers to make a change (who have to coordinate). Two sets of stakeholders to give approval (who have to have aligned priorities). Cascading issues from underlying data structures, and so on. Integrated systems (and monolithic systems such as CLM) can stop continuous improvement in its tracks.

‍

Consider how you can minimise the need for tightly-coupled systems. If it’s really just about making sure that a unique identifier is consistently used, consider whether it is such a problem to double-key? The pursuit of perfectly integrated data can come with significant costs. In an age of APIs, there are ways to manage data flows that maintain flexibility and assume that change will be constant, but they need to be designed in from the get go. 

‍

Everything can be improved; try to avoid stasis.