Recommendations and strategies for building an exemplary appointment request webform

I have spent my two previous blog posts exploring how requesting an appointment online begins a patient's digital journey and how top US hospitals approach online appointment request forms. Now, I would like to make some recommendations and strategies for building an exemplary appointment request form and follow it with an explanation on to how these recommendations are being applied to the Webform module's "Request a Medical Appointment" form template.

Creating an exemplary appointment request form is an iterative process that requires experimentation and testing with analytics to determine which solutions work and which ones don't.

There are many different levels of statistics that can be captured from a form.

Completion
The most immediately available statistic is the form's completion rate, which indicates how many people successfully filled out and submitted the form. Subtracting the completing rate from how many users visit the form provides a general sense of the form drop-off rate. What is missing from these statistics is more nuanced information about the form's drop-off rate that can give a better understanding of the form's user experience.

Events

Tracking a form's events shows which inputs were filled in and in what sequence they were entered. This detailed information helps to determine how a user is interacting with a form. Furthermore, knowing where users drop off from completing a form can help indicate which questions may need to be removed or reworked.

Analytics provides the digital team with insights that lead to experimentation and testing.

A good iterative process should always including testing, which makes sure that changes and improvements are successful.

A/B

Forms built using an iterative process typically have some current version of the form where inputs or labeling could be improved. The best way to confirm that an improvement or experiment is successful is to perform an A/B test where the original and improved variant is randomly presented to end-users, and each variant's success rate is tracked and then compared.

User

At some point, the best way to get direct and helpful feedback about an appointment request form is to ask users their opinion. User testing an appointment request form is tricky because you risk inconveniencing potential patients. Large healthcare institutions should consider doing professional usability testing with real patients who volunteer and are compensated for their participation. Seeing and hearing a user's frustrations with an appointment request results in inspiring a digital team to care more about the patient's experience.

Personally, my experience watching user testing made me realize that the most important thing that needs to happen on an appointment request form is that a patient is able to book an appointment, even if it requires them to make a phone call. Always include a phone number on an appointment request form.

On a related note, witnessing and understanding how users with disabilities navigate a website, inspires everyone to care about accessibility.

There are a lot of resources about form design and usability that provide general form recommendations. The goal here is to highlight common suggestions and recommendations explicitly applicable to appointment request forms.

Easy

Make it easy for users to find the appointment request form. Appointment request forms should be accessible within three clicks from a hospital's homepage.
 

Directions

Create landing pages that route users to the correct appointment request form. Landing pages can route domestic and international patients to the proper form and direct referring physicians to doctor portals.

Expectations

Set expectations by indicating how long and what type of response is expected. For example, will patients receive a confirmation email with a callback within 24 hours?

Grouping

Group related inputs by type of information. Common groupings for appointment request forms include contact, patient, diagnosis, and insurance information.

Explanations

Explain why specific healthcare information is needed. Tell users why providing insurance, referring physicians, and diagnoses will help when booking an appointment.

Relevance

Only collect the relevant information required to complete the immediate task of booking an appointment. Scrutinize each input and question and ask is this information needed.

Layout
Make sure the layout inputs are easy to understand and complete. Top aligned labels are the recommended approach for mobile and desktop forms.

Conditionals

Use conditional logic to ask simple yes/no questions which then ask for more specific answers. For example, asking who is filling out the form should be one of the first questions on all appointment request forms.

Indicator

Clearly indicate what inputs are required or optional. If most of a form's inputs are needed, it may be more appropriate to note which inputs are optional.

Ordering
Required elements should come before optional elements. Placing the required inputs first makes it easier for patients to skip optional inputs.

Accessibility
Make sure users with disabilities can complete the form. Forms should fully accessible to screen readers and keyboard navigation.

The Webform module's templates are intended to provide a starting point. Site builders and architects can customize the suggested elements and information for their specific business requirements.

Please note: The new 'Request a Medical Appointment' template is only available to new installations of the Webform module using the latest release of Webform 8.x-5.4+. Otherwise, you can manually install the webform.webform.template_medical_appointment.yml via Drupal's Configuration Management UI (/admin/config/development/configuration/single/import) or API.

Accessibility should not be an after-thought. Appointment requests need to be easy to understand and complete for all users.

JavaScript

For mission-critical forms, it is best to avoid any unnecessary JavaScript enhancements or behaviors that can cause accessibility issues. This is why the appointment request template avoids using Select2 to enhance select menus. There is a fascinating related discussion happening on Drupal.org about improving the usability and accessibility of long select lists. Ben Mullins (bnjmnm) is doing a fantastic accessibility audit of several of the available select menu enhancement libraries.

Indicators

Forms should show an explanation of required (*) fields, so I decided to display the 'Indicates required field" message at the top of the form.

Browser

The appointment request form is configured to display a native browser warning message when a user navigates away from a form with unsaved changes. Because the warning is generated from the web browser and not custom JavaScript, screen readers and other devices for people with disabilities should adequately handle this behavior. For example, Gmail also uses this functionality when a user is about to lose unsaved changes.

The goal of the appointment request is to collect patient and caregiver information. Therefore, it is key to ask for this information directly and make it clear what information is required to complete the form.

For example, the caregiver and patient contact information inputs ask for the same type of information. This makes it easy for an end-user reviewing the form to know that they need the caregiver's or patient's first name, last name, phone, and email.

Labels

This appointment request form tries to keep the labeling as simple as possible. Because the form targets patients and caregivers, it is challenging to create generic labeling that addresses both audiences. In the past, I have written custom JavaScript, which conditionally changes form element labels and descriptions based on the audience. For example, a caregiver would see 'Patient First Name' and a patient would see 'Your First Name.' This approach becomes unmanageable. There are no form builders on the market that support conditional form element labels and description. Conditional form element labels and descriptions would be a tremendous and challenging feature for the Webform module to explore.

Required

Required elements always come first. Besides indicating which elements are required, all the medical information is denoted as (optional) because a care specialist can also collect this information during the appointment scheduling phone calls.

Phone

For phone numbers, I nudge the user to enter the phone number using the standard US format (XXX) XXX-XXXX. Still, we don't need to require users to enter this format. Once again, I avoid using a JavaScript enhancement, like a phone number input mask. Input masks create an accessibility issue for screen readers because the (__)-___-____ is read aloud as "opening parenthesis, underscore, underscore, underscore, closing parenthesis, dash, etc."

Confirmation

The appointment request template displays a straightforward confirmation page and deliberately does not send a confirmation email to the end-user. Sending insecure emails to a patient can be considered a Health Insurance Portability and Accountability Act (HIPAA) violation. Generally, it is recommended to use secure messaging communicate with the patient or caregiver.

Buttons

Drupal and the Webform modules provide a responsive user experience out-of-box. Radios can be challenging to use on a small screen, so I decided to enhance the radios so that they would visual appear and behave like buttons.

In the Webform module, there is a dedicated buttons element that uses jQuery UI Buttons. I opted to use a recent enhancement to radios which makes it possible to style radios as buttons without using jQuery UI.

Layout

Even though single-column forms are more comfortable to complete, allowing some elements to be laid out in two columns makes it possible for someone to see the entire form and, in turn, realize that is is very easy to fill out.

Theming

Drupal's Bartik theme provides a good starting point for a form's visual design. I do find the default table element, used for the phone preferences, to be a little bit visually heavy. Phone preferences are optional and therefore should not be the most visually appealing element on the page. BTW, another reason I chose buttons for the first question, 'Who are you?", was to further draw a user's eye to this question, which is inside a container with a light gray background.

Results

The saving of results is disabled to prevent protected healthcare information (PHI) from being stored in Drupal. The appointment request template sends a confirmation and notification email. In a production environment submissions should be remotely posted to CRM or database.

Widgets

The simpler a form is to fill out, the more likely end-users will complete it. At the same time, it is important to capture the most accurate information. Since an appointment request form results in a phone call back, it is beneficial to know the best time to call a prospective patient or caregiver. I decided to experiment with adding a custom composite element allowing users to enter the best days and times to receive a callback. This widget adds complexity to the form, which is why it is optional. To further reduce this widget's complexity, I removed the adding, removing, and sorting of the days and times.

Honestly, we don't know if the enhancement is useful. If we track all the requests, we can look at how many people provide this information and how many days/times they are providing. A more direct approach is to perform usability testing that would allow us to watch end-users fill-out and submit the form.

There is always room for improvement. I hope my suggestions and tips inspired you to take a second look at your existing webforms and think differently when building new webforms. Building webforms is an iterative process and we should always welcome feedback.

I welcome any feedback to help me improve the webform's 'Request a Medical Appointment' template. Thanks for taking the time with me to research, review, and explore building an exemplary appointment request form.