HoneyBook's first native floor planning tool, built for its highest-value vertical.

Overview

Venues are one of HoneyBook's highest-revenue verticals. They're also the customers most likely to need a floor plan for every event.

Without a native tool, venue teams were piecing the workflow together across Canva, Prismm, and AllSeated. HoneyBook already had the booking data, client portal, and relationship. It was missing the tool.

My role
I led design from early discovery through launch, partnering closely with Product, Engineering, and Research.

The problem

Floor planning was a completely separate job.

Build a plan in another tool, export it, email it, get feedback, update it, and send it again. Different people ended up working from different versions. None of them were connected to the contract, guest count, or client portal.

The opportunity: bring floor planning into the project itself, creating one shared source of truth.

Early research changed how we thought about this problem. Rather than building another drawing tool, I pushed us to focus on the workflow around floor plans, particularly version control, reuse, and sharing. That insight helped shape the MVP and gave the team a clearer framework for what we should build first.

Research

Version control was the real problem, not drawing.

We studied 13 tools, mapped the venue workflow end-to-end, and spoke with early users.

Our initial assumption was that venues needed a better way to create floor plans. Research showed us something different.

Most teams already had ways to draw a room. The real friction came after that. Files were duplicated, renamed, shared across tools, and modified for individual events. Teams struggled to know which version was current and often rebuilt work they had already done.

The opportunity was not to build a better drawing tool. It was to create a better system around the floor plan.

HoneyBook also had something competitors didn't. The context around the plan already lived in the product: guest counts, contracts, clients, and relationships.

Workspace

Before designing the builder, I designed where it would live.

Floor Plans became a dedicated tab inside every HoneyBook project.

I defined three statuses to separate preparation from sharing, distinct experiences for venues and clients, and a creation flow built to accommodate templates once they were ready.

V1

We deliberately started small.

Research also showed that venues rarely start from scratch. They typically set up a space once, then adapt it for different bookings. A wedding, corporate dinner, and cocktail reception might all use the same room, but each requires a different arrangement.

We knew reusable templates and blueprint upload would better support this workflow, but neither could make the first release. Rather than expanding the scope, I advocated for launching V1 to a smaller group of customers so we could validate the core experience while being transparent about its limitations.

V1 launched to 30% of venue members with the core builder:

1 · Element panel
Furniture, shapes, rooms, and text. Organized by category. Drag or click to place.

2 · Status bar
The plan's name, its project, and its current publish status, at a glance.

3 · Canvas
An infinite grid with a 1×1 ft scale indicator. Build freely, set the scale once.

Feedback

We shipped to 30%. Then we listened.

The first release validated the core idea, but it also exposed where the experience broke down in real workflows.

Rather than treating launch as the finish line, I worked with Product and Engineering to understand where users were getting stuck and which problems were worth solving next.

11 venue members responded. The signal was clear.

Direction

The feedback gave us a clear path forward.

I helped align Product, Engineering, and the venue team around what to ship first and what would make the product genuinely competitive.

Set the V2 priorities
What we learned from the release reinforced the direction. Templates and blueprint upload became must-haves, giving venues a consistent starting point while still letting each event evolve independently.

Protect the product vision
Partner through build and QA to keep Floor Plans native to the HoneyBook project, not a standalone tool.

V2 · Templates

Build once. Reuse everywhere.

Venues set up the same spaces again and again.

Templates let them save a room once and reuse it across bookings without starting from scratch every time.

V2 · Scale

Floor plans needed to work in the real world.

7 of 11 members said scale was the biggest reason they couldn't switch to HoneyBook.

V2 · Precision

More control. Less guessing.

We redesigned the wall interaction and added tools for measuring and locking elements in place.

The builder could now behave more like something venues could actually use to plan a physical space, not just draw one.

Result

One place for every plan.

Floor Plans now lives inside the HoneyBook project alongside the booking, client, and event context it belongs to.

No exports. No second tool. One source of truth.

Impact

Members found it without being asked.

Floor Plans launched June 10 with no marketing push and opened to 100% of venue members on July 5.

By day 27:

1,019

Floor plans created

746

Unique creators

1.37

Average plans per user

41

Shares per day

The early adoption validated more than the feature itself. It reinforced the decision to focus on the workflow around floor plans rather than simply giving venues another tool for drawing them.

What started as a request for a floor plan builder became a new way for venues to create, reuse, manage, and share one of the most important artifacts in their workflow.