Add form creation and management capability to stay competitive, reduce support costs and increase revenue.

Problem

While the product allowed clients to collect form responses, the forms themselves were hand-coded by tech support. This required significant time and personnel cost. Clients found it frustrating not to be able to create or edit forms themselves and felt stymied by the longer ticket response times. Additionally, some competitors provided form building tools putting us at a competitive disadvantage.

Project goals

Give people the ability to create and manage their own forms within the product:

• Easy to use form builder interface
• Ability to collect and see responses
• Provide advanced options commonly expressed in support tickets
• Allow clients with old forms to continue to access those

Process

Discovery & research

Based on interviews with clients and stakeholders as well as analysis of support tickets, the VP of Product created the project roadmap.

From there, I researched direct competitors and popular form builders with an eye toward ease of use, standard elements, error handling, response collection and advanced settings. 

Define the MVP and information architecture

Due to the complexity of the project and only two developers working on it, we had to determine the minimum functionality required to release the project and what we could add later.

People creating forms needed at a minimum: a place to build a form, a place to see all their forms and a way to access the responses to each form. Client interviews had revealed a strong desire for the ability to schedule or turn on and off each form, a notification method to find out when new submissions occurred and some way to easily share the form with potential respondents. As these later items were ideal but not strictly necessary we placed them in at the top of the queue for after the MVP release.

While the list of respondent needs was shorter, they were still high priority due to their necessity: a place to fill out the form and an immediate verification of successful response submission. 

All the while, we also had to keep in mind that form creators and form respondents might be using any device to complete their tasks.

Design iterations and user testing

During our initial interviews with clients we discovered which form building tools people used currently and why, as well as what they found easy or hard to do with those tools. That gave us a rough idea for our form building interface which we took to our developers. While our front-end developer and software engineer got the basic functionality working, I continued design iterations and user tests to finalize the UI. 

I also itemized all the possible form field types we might want to provide based on competitor research and client prioritizes. Each field type needed a UI appropriate to its data type while remaining consistent with the other field types and our design standards. Additionally, we wanted to match or surpass the ease of use of the best form builders currently available to our clients. As we finalized the design for each field type I added it to Confluence, including how it looked initially and how it looked after the client had entered the question information.

Since there were so many pieces to this feature, we mostly worked on one at a time: the developers working on one piece while I worked on the next piece, working circularly to refine each piece a little more until all pieces worked together to provide the functionality needed for the MVP.

Onboarding

Constraint

With limited development team resources available we had to minimize the time required by them to implement and maintain onboarding.

Ideally I wanted to guide someone through form creation interactively inside the feature itself. However, that would require development time to create and update. Instead we opted to, first, use best practices such as helpful blank states, smart defaults and inline help. And, second, to create a tour in InVision.

The tour provided an introduction to basic functionality and a simple link in the feature took people to the tour. In this way we were able to minimize the dev time needed to only the time needed to add the link itself. The creation of the tour and updates to it could all be done by the product team.

As it turns out, moving the tour to InVision had a beneficial side effect: the sales and marketing teams were able to quickly show off the ease of use and functionality of the new forms feature.

Results

Clients and internal teams embraced the new tool. Clients appreciated the ability to create and manage their own forms without technical support. Technical support shifted their focus and time to other issues. The sales team presented forms as a well-constructed sellable product add-on.

Six months after release 211 sites had added the new forms feature. Previous to this, clients had been completely unable to create their own forms.

Lessons

When you start a project it can seem smaller or larger than it really is. Breaking the project into parts is the key to making all the pieces visible and do-able.

Internal resources who are touchpoints with customers, such as technical support and project managers, have very valuable information about user needs.

Build all the forms you want, but if you can’t see the responses it’s a fruitless endeavor.