Desgining a pop-up form creation module

Key information

Company - Freshworks
Product - Freshmarketer
Time - 3 months
Team - 1 Product Designer, 1 Product Manager, 5 developers, 1 QA
My Role - I worked on this project end-to-end. I worked on competitive research, lo-fi wireframes, hi-fi designs, Visual QA and post-hand-off support to developers.
Platform - Desktop
Status - Under development

What is a pop-up form?

A pop-up form is a type of form that "pops up" on the screen when triggered by a specific action, such as clicking a button or scrolling to a certain point on a webpage. These forms are commonly used by businesses to collect user information, such as email addresses for newsletters, feedback, or registrations.

Some common use cases -

1. Lead generation

   

   
   

2. Announcements

   

   
   

3. Email subscriptions

   

   
   

4. Promotions

   

Business and user needs

This project had been on the roadmap for a long time but was not pursued because it required a lot of engineering bandwidth. It had now been prioritized due to important business needs.

1. This was a feature request from a high-value customer in a key geographic area for our strategic expansion.

2. We decided to prioritise it within this quarter to be on par with other competitors in this location.

User needs

1. Freshmarkter has features that enable businesses to engage with their customers across multiple platforms such as email, WhatsApp, SMS, and social media. These platforms allow businesses to interact with and nurture existing contacts in the CRM. However, forms help businesses in their top-of-funnel strategy to acquire new customers within Freshmarketer.

   

2. Freshmarketer already had a Forms module that enabled integrating and syncing existing forms with CRM. Upon integration, when a new visitor fills out a form, their contact information is added to the CRM. However, it could not create and customize forms within Freshmarketer. Users could not set conditions such as when to display the form and whom to target.

   

Making sense of the problem statement

Initially, when I had a little context of pop-up forms and all it entails, the problem statement for me at a high level was quite simple but ambiguous. Since we knew clearly that we needed to enable our customers to create pop-up forms, we skipped the Discovery phase of user research and directly dived into the competitor's study to understand the nitty-gritty.

I created a detailed user flow based on my understanding of the vision from the product requirement and the competitive research. Below is the screenshot of the user flow and the questions I had.

Understanding user

Goals and metrics

We at Freshmarketer are working towards increasing the features' adoption. Therefore, one of the most important success metrics for this feature is the percentage of accounts with live forms.

At this point, my understanding of the problem statement had become slightly nuanced compared to when I started.

Figuring out the solution

With improved clarity in the user flow (though not final yet), I began working on the wireframes to align the engineering and product teams on the approach.

After discussions with the product and engineering teams, we identified a few key points early on:

1. The wireframes were initially designed assuming we would create our own editor. However, we decided to use third-party editor tools, which completely changed our approach.

2. We used our existing modules as guidelines to maintain consistent behaviour, leading to the steps outlined above. However, further discussions revealed that the review step was unnecessary. To maintain consistency, we added an extra step that users didn't need to complete.

Constraints

1. Using a 3rd party editor

   Although major competitors like Klaviyo, Omnisend, and HubSpot created their form editors from scratch, we were limited by time and decided to use a third-party tool called Bee Editor.

   
   

   

   
   Bee Editor is also used in our Email Campaigns module, so the engineering team was already familiar with it. However, the design team tried to push back on this decision because the UI looked dated and Bee Editor provided limited customization options.

   

   
   

   Using the Bee Editor tool as it was had a few limitations:

   1. It didn't provide the ability to map form fields to CRM contact fields

      

      
      

   2. It didn't allow end users to create their fields if they didn't want to use the predefined options.

      

      
      

   3. It lacked certain field types, such as data privacy and consent text, and didn't offer the ability to customize form actions based on button selections in different scenarios.

      

   How did we solve this?
   Initially, we pushed the developers to consider other third-party tools. They conducted a proof of concept (POC) with several third-party and open-source tools, but due to security issues, we ultimately decided to stick with Bee Editor. We chose to use Bee Editor as the base editor while building our form configuration, which would appear in an iframe on top of the editor.

   

   
   

2. Existing forms module

   We already had a forms module with a different purpose than the one we were building. Our question was how to provide this new experience to our existing customers. The existing list page had different columns than what we needed.

   After discussing with internal stakeholders, including developers, product managers, and fellow designers, we agreed on a new list page. We removed redundant columns, such as URL, Manual/Automatic form type, and toggle, to keep it streamlined. In their place, we added new columns like 'Add Contacts to Marketing List' and 'Submission Rate'.

   

Final designs

Freshmarketer maintains a Design Library, utilized for creating most visual design components. Some unique components were developed specifically to meet the requirements of this particular project. Below are the two key screens from the entire project:

1. Edit form

   

   
   

2. Configure form

   

   
   
   

Check out the video below to see the entire flow.

Way ahead

The case study might end here but we have a lot of work left to do :)

1. Visual QA

2. Ship phase 1 to the users

3. Track data and gather feedback

4. On to the next phase with incremental improvements