Flowers By Chi

Customers had zero order visibility and staff were drowning in manual data entry. I connected both problems into a single workflow.

I was the sole designer at Flowers By Chi, a local florist running on a custom-built website. I started with customer research, designed a tracking solution that staff rejected, then pivoted to a system that automated the operational bottleneck while giving customers real-time order visibility.

Customers placed an order and heard nothing until flowers showed up, or didn't.

The business was scaling from 80 to 150+ daily orders, but the fulfillment process couldn't keep up. After checkout, the only update customers received was a confirmation email, no estimated delivery time, no status visibility, and no way to check without calling the shop.

During peaks like Valentine's Day and Mother's Day, this compounded. More orders meant more anxious customers calling, which pulled staff away from the fulfillment work that would actually get orders to customers.

Behind the counter, staff were re-typing information that already existed digitally.

For each order, a staff member opened the order details, read the customer's message, recipient name, and address, then manually typed it all onto a physical delivery card. During peak seasons, this became the bottleneck. Staff couldn't move faster without making more mistakes, and they couldn't scale without adding headcount for the same repetitive work.

Customers said they wanted "better communication." The real need was transparency.

I interviewed 6 customers to understand where frustration peaked. Every one asked for the same thing: more communication. But when I looked into what triggered the anxiety, the pattern shifted. They were frustrated because they had no way to check on their order themselves.

This reframed the problem from pushing more communication to providing on-demand visibility.

I designed a tracking interface. Staff immediately told me it would make their jobs harder.

Based on customer research, I designed a timeline showing: Confirmed → Being Prepared → Out for Delivery → Delivered, accessible via a link in the confirmation email.

I brought it to staff expecting validation. Instead I got, "This would make our jobs even harder." The tracking page required someone to manually update each order's status. Staff were already spending hours typing delivery cards. I had designed for the customer and overlooked the people who had to operate the system.

I also explored real-time delivery tracking, but ruled it out for the same reason.

GPS-based live updates like Uber Eats and DoorDash would have required delivery drivers to run a tracking app on every route. But this added friction to a different stakeholder group instead.

The infrastructure cost was also disproportionate for a local florist operating in a limited delivery radius. This established a constraint for the rest of the project to provide visibility without introducing a new operational task for any employee.

Staff interviews revealed that the delivery card bottleneck was the real leverage point.

I went back and interviewed 2 staff members, this time focused entirely on their workflow. The delivery card typing consumed the most time and created the most errors. While every other step was relatively fast, this was where the system broke down.

I connected both problems at the system level.

Rather than treating customer transparency and staff operations as separate problems, I looked for where they could share a single interaction.

The delivery card bottleneck had a structural cause: order data already existed in 1-800-Flowers and Teleflora's fulfillment APIs, but staff had no way to act on it without re-typing it manually.

I wrote a Python script that pulled order details from both APIs and sent a formatted delivery card directly to the printer. The same trigger also made an API call to update the order status, moving it from "Being Prepared" to "Out for Delivery" automatically.

The tracking page gave customers real-time visibility without adding any work for staff.

Every decision on the tracking page relied on customers needing access with zero friction, at the moment they were most anxious.

I chose a confirmation email link over account login because email was already part of the order flow. Requiring an account would have introduced a barrier when a customer was already anxious about their order.

Customer Tracking Page — DesktopFinal

I considered adding an updated photo of the arrangement, but it would have required staff to photograph each order manually, reintroducing friction the automation eliminated. The card message was the highest priority since typos from manual entry were a recurring issue.

I also built a reporting mechanism so customers had a way to resolve issues beyond calling.

During discovery, customers mentioned having no clear path when something went wrong: a late delivery, a wrong address, a damaged arrangement. The only option was calling, which often went to voicemail during busy periods.

I added a reporting flow accessible directly from the tracking page. After delivery, customers could flag issues, leave notes, or confirm everything arrived correctly.

The connected workflow eliminated the bottleneck and gave customers the visibility they'd been calling about.

Staff said the difference was immediate: one click replaced minutes of data entry per order, and the first peak season after launch was the first where they weren't falling behind.

On the customer side, the phone stopped ringing during delivery windows. When customers did reach out, it was through the feedback flow with specific issues rather than general anxiety.

The shop went from struggling at 80 daily orders to handling 150+ without adding staff.

You can't design for the customer in a vacuum.

The first tracking concept was the right solution to the wrong scope. It solved customer anxiety while creating operational overhead. The better outcome came from finding where both problems shared a solution, not from solving them separately.

Surface requests hide root needs.

Every customer asked for more emails. Taking that at face value would have produced a notification system that addressed the symptom. Asking why one more time led to a self-serve tracking page instead that solved the core problem.

What I'd do differently.

I should have mapped all stakeholders before touching Figma. The pivot was the right call, but it cost time that a broader stakeholder map at the start would have saved. In every project since, my first question is: who are all the people this system touches?