Simplifying form flows to drive organiser service requests

A two-sided marketplace requires balance

Add to Event is a marketplace that relies on a healthy level of event requests being submitted that are then quoted on by a pool of trusted suppliers. That first area, the submission of event requests via the request forms, is an area that had been neglected for a while. The Conversion Rate (CR) of these forms hadn’t been properly monitored and optimised, and our CRO expert uncovered huge drop-offs at certain steps in the form. This was a potential optimisation gold mine. The main goal of this project was to improve the request forms CR across our diverse range of services. This would lead to an increased number of event requests being submitted, which would encourage suppliers to send more quotes and buy more credits. As the sole product designer at the company, my role was all-encompassing and involved leading all sections of the design process and output.

Initially, this project was a way to discover learnings on our current Drupal request forms. It was a prime testing ground for new components, copy updates, and other ways to solve these CR drop-offs at specific form steps. We had the ability to run A/B tests on these steps, so it was beneficial to gain data on these new implementations so that we could improve our current Drupal request forms, as well as be confident that these same improvements could be easily implemented into the new forms solution.

To begin, we focused on steps in the form that saw the biggest CR drop-offs. We conducted a review of the Drupal forms experience on desktop, tablet, and mobile and annotated assumptions and ideas. Here’s an example of some key points I picked out for the Food Vans select service type step (relating to image above):

1. On desktop, users don’t typically scroll. So these services at the bottom potentially aren’t even being seen.

2. Iconography or smaller images may allow users to interpret a large list of services more quickly than the current large stock images. Some of these stock images are low quality and not representative of the service.

3. How has the order of the Food Vans been determined? It’s clearly not alphabetical. This should be revisited.

4. On mobile, the longer service names become stacked which leads to more vertical height being used. Is there a way we can avoid this?

Scalability and flexibility was a must-have for the next iteration of forms

Developer resource for this project was reduced due to a focus on a larger backend migration project. As a result, it made sense to focus on the request form for a low risk service. In this context a low risk service was a service that typically didn’t see a great deal of request submissions or traffic, and fundamentally wasn’t contributing to our bottom line. We chose the Inflatable Pubs service. The other major benefit of this solution was scalability. This service shares the same flow as 90+ services that we offer (we offer 360 in total!), so we could learn fast and be confident when applying these new form flows to other services.

What we have and what the competition has

I did a competitor analysis on the general user experience of forms, focusing on direct competitors such as Bark and Feast It, as well as looking at indirect competitors in different industries. This was a great learning experience as it highlighted form best practises and inspired me to start thinking about how we could implement similar ideas into our request forms. From the competitor analysis, the following findings resonated the most:

1. Great form experiences use the basic form elements well, but they make their selectable area bigger, or add custom icons to create a delightful experience.

2. Great form experiences are technically well built. Ensuring all validation and errors are contextual and displayed early (instead of when a user submits the form), and pre-focusing fields to fill in quickly.

3. Great form experiences gamify elements to provide encouragement. They only ask for essential information, and may request certain information post-submission in order to reduce the overall number of steps.

Building out the first version of the new forms prototype

I made the decision to jump straight into Figma to start creating concepts for a revitalised request form experience. There was a strong focus on stripping away the cognitive load such as the superfluous copy e.g. 2000+ suppliers ready to quote. This also meant designing a full-screen form experience for desktop, removing the jolty modal experience and allowing the user to concentrate on the questions at hand without distractions. Bringing icons into the experience added more delight and another way for users to identify specific answers. This ideation stage also involved rearranging the flow to ensure that there was a semantic flow to the questions. For example, date, time and location were paired together at the beginning, whereas capturing a users personal data was reserved for the end when the value was provided.

Getting the new flow in front of users

Test participants were tasked with imagining that they were booking a summer party and wanted to hire an Inflatable Pub for the occasion. From the user testing, I gained the following insights:

1. Users appreciated the personal touch of the guide avatar at the start, as it felt more personable and less artificial. However, this avatar didn’t follow the user through the form process, which confused participants.

2. A few participants mentioned that being able to use social sign-in would make it easier for them so that they didn’t have to create a new account/password.

3. Despite offering a simple text input field for the Number of Guests, and providing a stepper increase/decrease module for the Budget per Head, users preferred a visible list to choose from.

Creation of web components and new hand-off process

The next stage involved translating these designs into their subsequent web components. I wanted to make it as easy as possible for the developers to access the Figma designs directly from their work base: JIRA. The figma to JIRA plugin was trialled but this didn’t work for our workflow. The solution involved creating a dedicated ‘web components’ page in Figma. Each frame would contain all the required states and edge cases of a specific component. This was then linked to the specific JIRA ticket so that developers could easily access the correct component and immediately understand the component acceptance criteria. Developers were encouraged to ask questions and pin comments to specific elements of the components. As a result, this new workflow streamlined the hand-off process and enabled closer collaboration between design and development.

A lightweight tech stack to enhance performance

The current forms consisted of launching a normal Drupal-powered modal on top of the site. The approach for the new forms was different, the intention was to launch a Stencil.js application on top of the website for optimum performance and the following benefits:

1. The form is embeddable. Using Stencil.js allows us to place these new forms on any website, including: Drupal (current marketplace and old public-facing site) and Webflow (new public-facing site). Currently, Webflow pages use iframe forms which are typically very slow and are not compatible with A/B test tracking.

2. Form is resumable. If a user goes to a particular step and closes the form, their data is persisted. When opening the form again, they are able to resume where they left off.

3. Improvements to A/B testing capabilities. We can test more complicated flows, such as the addition, removal and re-ordering of steps.

4. We can easily group logical questions together. In these enhanced forms, question steps can be swapped in and out, creating the ultimate flexibility.

Consistency with a solid design system

A separate, smaller design system was created for this project so that I could have complete control over foundational elements, instead of having to update outdated legacy components. It also empowered me to breath new life into the forms user interface, something we hadn’t done for 4+ years. When creating the component designs in Figma, careful consideration was taken to ensure that all elements were built out in a robust and reusable manner. Variants were created with appropriate property values such as viewport, state and other custom functionality. The new forms will scale from where we left off, meaning that the creation of new components would be an effortless process.

Live for 90+ categories (and counting!)

The initial A/B test for the new form on the Inflatable Pubs service was successful, we saw an uptick in the number of event requests submitted by 8.4%. With this promising result, we decided to expand the new form flows to 94 more services at the time of writing. Due to the lightweight development stack, we’re in a good place to be able to gain feedback and solidify existing components. We’re also keeping a close eye on Hotjar sessions to review where drop-offs occur or where users seemingly get stuck. The next stage of the project will involve getting this form flow implemented into a more complex service, like Food Vans. Further iterations include implementing the ability to sign-in using social media, which was a highly requested feature from user testing. The key deliverable of this project has been a scalable technology that will allow us to iteratively improve forms more quickly as a business. With a solid design system in place, coupled with a robust and lightweight Stencil.js technology stack, we’re now in a prime position to seriously optimise how organisers submit service requests.