Drag-and-drop editor

Researching, designing, and building a proprietary drag-and-drop editor for Braze in-app messages and other future applications.

ROLE
Research and Design

TEAM
PM, EM, 5 Eng, part time shared UXR resource

Introduction

This project was a later large phase of the broader multi-year vision for in-app messages (IAMs). The team spent three years building technical and UX foundations, alongside new features, that culminated in the creation of a drag-and-drop editor.

The editor integrated a third-party tool, with a completely custom implementation. It was designed to be flexible, as it was intended for use across various messaging channels and landing page builders. Due to the technical and UX requirements, the project spanned multiple quarters, including Early Access and GA phases.

Below is an example of the existing classic editor, which only allowed for basic color customizations. Users couldn’t rearrange or add elements, nor could they fully align the design with their brand standards.

Team Goals

This project fit perfectly into the in-app message team goals:

• Vision Statement: For teams to engage with their consumers in a contextual, relevant, and delightful manner.

• Mission Statement: Provide teams with intuitive, powerful tools that enable them to design, compose, and deliver relevant, on-brand messages within their products.

The Problem

Braze customers today have no easy way to build and personalize In-App Messages for their core use cases.

Workarounds often require custom HTML code for content and design customizations. This results in a frustrating editing experience with limitations on how on-brand and sophisticated their messages could be.

Process Overview

This project, from the beginning to GA, spanned multiple quarters due to the significant time spent investigating and integrating a third-party tool. The large engineering level of effort (LOE) provided ample time for PM/Design to iterate and test various prototypes and functioning proof of concepts (POCs).

Target Use Cases

Long-term, non-technical marketers want to create better onboarding experiences for their users without relying on engineering help, including:

• New Feature Announcements

• Promotions

• Recommendations

• Location/Push Primer

• Custom Data Collection/Surveys

These use cases served as our guiding light for what template and editor to build.

MVP Journey

For the first launch of the editor, users needed the ability to:

• Open the editor and input custom content like text and images

• Set message behaviors, such as button actions

• Add and move new blocks and rows

After creating the message, users needed to preview it across phone, tablet, and desktop views as a specific end user, and send a test message to a device.

Additionally, users needed access to the existing classic editor, as it wouldn’t be deprecated anytime soon.

Project Goals

Our goals were to build a new WYSIWYG editor to compose and customize in-app messages, focusing on the following metrics:

• Increase editing CSAT (Customer Satisfaction)

• Increase in-app message adoption rate

• Reduce the total number of HTML IAM campaigns

• Reduce campaign setup time

Vision

To kickstart the project, we outlined a high-level and long-term vision of how a drag-and-drop editor could look in the product. This initial mockup used an existing third-party tool already employed in the email editor. Although we ultimately chose a different tool, this mockup was familiar to the team and met the basic requirements, so it served as a guiding light throughout the design process.

Hack Day

As we were setting the long-term vision for the in-app message editor, company-wide Hack Day took place at Braze. One of the engineers and I decided to see if we could build an editor in a day. Using the design above as a reference, we created a working POC, demonstrating that an editor could be integrated and its HTML could be delivered to end users. We also won an award for our work and wrote a blog post about this Hack Day achievement.

Selecting an Editor

After Hack Day, the team evaluated third-party editors to determine which would be the best fit for integration. The table below provides an overview of the deciding factors. Tool 1 was an editor already used in the email editor, but we ultimately decided to move forward with GrapesJS due to its general flexibility. Hosting GrapesJS ourselves would allow for greater stability and customization. From a design perspective, the opportunities for streamlining UX and aligning with our Beacon Product System were exciting, as we would have full control over the editor and all its components.

Design Iterations

After selecting an editor, we focused on refining the editor structure, basic interactions, and determining which features should be included in the MVP. Below is a collection of design iterations as we progressed through multiple live user testing rounds. The designs started low-fidelity and became increasingly refined as we gained confidence in our solutions.

Round 1: Established the basic editor structure and feature requirements.

Round 2: Validated the contents of the right panel for each block type

Round 3: Explored reskin options for the right panels.

Round 4: Final high-fidelity design, fully integrating the Beacon Product System.

Final Designs

Below is the final prototype used in testing as we entered Early Access (EA). By this point, we were able to test the editor with the live beta implementation, so the prototype does not include the interaction of dragging and dropping rows. Instead, this prototype focuses more on the right styling panels, showcasing the configuration and customization options available for each block.

Early Access → General Availability

The release of the editor went fairly smoothly, with positive reception from customers. For the first set of customers, we conducted live usability testing sessions. These sessions provided validation for our solution, feedback for future iterations, and increased our confidence to release more broadly.

EA Requirements: Users could create and launch a basic modal in-app message using the drag-and-drop editor. This included:

• Setting global message styles like font family and text colors

• Dragging and dropping rows and blocks (image, text, button, spacer)

• Customizing individual rows and blocks (size, color, spacing)

• Previewing on devices and sending test messages

Eligibility to move to GA:

• Essential updates based on EA feedback

• Revamped styling options and fields (right sidebar)

• Basic Template Library with modal and fullscreen message types

• Satisfactory stability and performance

Outcomes

Overall, this project was wildly successful. Both customers and internal team members were very excited about this release. While it may have taken longer than initially expected, this first iteration of the editor was promising and showed the potential left to be explored.

• Customer satisfaction: During each round of usability testing (including the EA release), we measured CSAT, which averaged around a 4/5 at all times.

• Adoption: The editor was quick and easy to use, but not all customers had time to transfer existing messages into the new editor. Adoption would likely happen slowly over time as customers implemented new use cases.

• Reduction of workarounds: Customers agreed that the editor satisfied some of their needs for more flexible templates. However, they still requested additional templates, such as multipage and data collection.

• Setup time: Customers could launch an in-app message in a matter of minutes, whereas before, creating custom HTML often required engineering resources, which could take days or even weeks.

• Competitive positioning: Our MVP positioned Braze ahead of many competitors and well-positioned to surpass others in the coming quarters. As far as we knew, we were the first in our market to integrate this specific editor and create such a custom one. Sales engineers loved demoing the editor to prospects for its ease of use. It marked the start of a new generation of editors at Braze.
  

This was a major milestone that set the stage for future improvements and further development, including:

• Further Refinement of the Right Style Panels: We added more controls and streamlined the UX to ensure a smoother and more intuitive experience for users.

• Addition of New Features: We introduced new block types and enhanced device previews, enabling users to create more sophisticated and responsive messages.

• Integration into Other Channels: The editor has since been successfully integrated into four other channels' composers. This extended the benefits of the drag-and-drop editor across different messaging channels, increasing its utility and adoption.

Reflections

• This was a huge project, the biggest of my career. I’m proud of the work, not just because of the process and quality of the work, but because it represented something much bigger at the company. This was a huge shift in editing experiences at Braze, transitioning to a flexible drag-and-drop editor instead of the previous rigid basic WYSIWYG editor. With the editor now being used in multiple other instances, customers are better satisfied, and internal teams can build better experiences, faster.

• The team worked concurrently, with engineering building the basic integration while we were testing editor layouts. Then, once we had a working POC, we were able to conduct rounds of live usability testing in the Beta product, reducing the need for prototype testing. This also allowed for tight collaboration and quick pivots between design and engineering throughout the project.

• There was a lot of work put into the modal template itself, which isn’t represented here. While we initially focused on the customer experience of creating a message, we always had to consider their end users’ experiences as they interacted with the message. This included accessibility and browser compatibility, as well as fully flexible and responsive designs.

• The editor was fully customizable, so I had to be very deliberate with the work I took on. This project likely could have been shorter, but there were so many unknowns when we started that it was difficult to properly estimate the level of effort. Despite the pressure to get to market, I didn’t want to sacrifice the user’s experience just to get something out the door. I knew that I didn’t want to make major structural updates after release, so I aimed to release a solution that would reduce jarring releases and future frustration in enablement.