πŸŒ™
β˜€οΈ

building a builder

It all boiled down to creating a playful experience that encourages the user to experiment while building their audience.

This article is a complementary piece for the Audiences Case Study. I will focus on creating the Audience Builder and the thoughts behind the decisions made.

Before dwelling on the bits and pieces of the Builder as a product component, let me set the stage by first giving some context of what does Leanplum do, and what is Audiences.

LeanplumΒ is a leading multi-channel customer engagement platform that helps forward-looking brands meet their customers' real-time needs.

AudiencesΒ is the audience management solution in Leanplum that helps marketing teams build, manage, and better understand their diverse Audience and leverage this data in their marketing strategy.

Audience Builder is a query builder where you can select user filters and behaviors and chain them with logic operators to define your Audience. For example, I want to explore users who are from Italy, speak English, and are interested in Soccer.

Now, let's dive in.

Introduction

The Builder was the first product component that we tackled in the Audiences vision. Since an audience is a set of properties and behaviors, every audience will start from the Builder.

When we kicked off and started the product discovery, the functionality was there, yet the usability was far from there. The functionality was impressively flexible, giving our users endless possibilities of what they can build, yet usability pushed the user back from achieving this. We understood that to improve the experience, we need to focus on the following main pillars β€” clarity, flexibility, and forgiveness.

Clartiy β€” I wanna see it in technicolor

When we speak about clarity, we are mainly talking about providing confidence to the user. This confidence is needed in the user journey of building an audience, also for viewing the audience.

In the first place, I want to understand all the properties and behaviors available. Hence, I make sure that I'm leveraging this in my audiences. We followed a megamenu pattern to give an on-a-glance view of all the options available.

Also, we wanted to clarify how the audience is combined with logic operators and made them differentiate at a glance. By scanning the audience, the user can understand which properties are combined with "and/or" operators.

Finally, while building an audience, I want to understand the size of this audience. Here is where the Insights section comes in handy. This is a complementary product component that supports the Builder, where we show the size of that audience and several metrics that would guide the user.

Flexibility β€” I wanna play around

Till now, we achieved clarity and provided the user with the confidence they needed. But how we encourage them to play around with it. How do we make sure that building an audience is a breeze? How can we provide a flow where they can experiment while doing it? We added the following functionalities to ensure precisely this.

Drag and Drop β€” a drag and drop appropriately done is always a fun experience. We wanted to make sure that this would ease changing the property's position and eliminate the need to delete and re-add this property in the desired position.

Merge Sections β€” the ability to merge sections separated by an "and" operator and have the properties combined with an "or" operator.

Split Rule β€” Kinda the opposite of the previous action. The ability to split a property from one section into a new section.

Forgiveness β€” I'm only human

The previous functionalities achieved this playfulness sense to the experience. Yet, on the other hand, it made it more error-prone, which by default will add a mental barrier for the user to leverage and use these functionalities.

Don't get me wrong. We want the user to experiment with the audience's structure and break the structure if needed as part of the experiment.

To provide the user with the courage to play around with an audience and experiment with different structures, we had to makes the actions reversible. By doing this, we will directly remove this mental barrier.

Adding undo, redo, and a reset functionalities to the mix is what we needed to ensure that the user can always reverse an undesirable action.

Summary

Looking in retrospect, all these functionalities mentioned above seem obvious and natural, yet we didn't get it right right away. This is the fruit of endless iterations, feedback loops, and above all, a tight collaboration of a product team (PD,PM,FE,BE,QA) whose main goal was to achieve an excellent user experience.

That said, we are constantly learning and searching for opportunities on how to improve the experience further. There's always a room for improvement.