Tapbook — AI Booking Platform

Problem

Tapbook bet that booking over SMS and voice could beat the form-heavy status quo. The rushed, outsourced build fell short, and adoption stalled. Working directly with the founder, I rebuilt the product end to end over four months. Every change in the final designs traces back to something we watched a user do.

Tapbook web dashboard led by an Ask Tapbook prompt, with featured providers, upcoming appointments, and spending — The rebuilt product: web dashboard and mobile app, one system across both surfaces.

Process

We ran four rounds of moderated usability testing, two with clients and two with providers, and iterated between every round. The biggest shifts:

Client home. Search moved from the centre of the screen to the top, and we added a "Near Me" option after travellers in new cities surfaced the need mid-test. Category images became icons, and "Popular" became a personalized "Favourites" list with one-tap removal.

Client home after testing: search relocated for discoverability, and a "Near Me" option born from observed traveller behavior

Provider home. We swapped a mid-page calendar for a task manager after watching providers hunt for the day's appointments. In every session, task-first beat calendar-first. Cards surface upcoming and completed counts so providers can read their day at a glance.

Provider home after testing: task-first, not calendar-first

Search results. A dedicated back button replaced reliance on the home icon, a calendar icon absorbed the "when/where" fields, and filters became pills so they read as tappable.

Search results after testing: direct return path, compact date entry, filter pills

Design

Client home led by an Ask Tapbook prompt, with search, favourites, and the next appointment — The client experience: home with personalized favourites, search results rebuilt from testing, and one-screen booking.

Provider dashboard with daily schedule and task counts — The provider experience, the other half of the marketplace: a task-first dashboard, earnings without guesswork, and client chat.

Outcome

The rebuild shipped as an interactive prototype with full handoff documentation: twelve final screens across client and provider, each shaped by the four testing rounds.

Appendix

To avoid designing from my own assumptions about booking, I ran two tracks in parallel: interviews with five users spanning service providers and clients, and a competitive analysis of Acuity, Booksy, Calendly, and Setmore. Four needs kept coming up: quick to learn, fewer steps per booking, one complete solution instead of several partial ones, and something that holds up on weak infrastructure.

"…most people in 62% of counties in the US did not have government minimum download speeds for broadband internet." — Setmore Whitepaper

Interview sessions and affinity mapping across five participants

Feature matrix: Acuity, Booksy, Calendly, Setmore across twelve capabilities

The research condensed into two personas: a client who wants booking simple enough for her parents, and a provider drowning in manual scheduling. Their flows carry both through onboarding and booking, where the AI prompt sits alongside manual search instead of replacing it.

User flows for onboarding and booking, with decision points

I built the brand alongside the product, because Tapbook needed an identity as approachable as the booking it promised:

Primary

#FFFFFF

Secondary

#242F5A

Accent 1

#C7D8FF

Accent 2

#34C759

Neutral 1

#F1F1F1

Neutral 2

#D3D3D3

Neutral 3

#858585

Inter

Regular · Medium · SemiBold · Bold

Body & UI

Poppins

Medium · SemiBold

Headings

The full story

Every artifact, decision, and iteration lives in the deck.

The deck is available on request. The password is included in my job applications, or you can request it via the contact form.

Using AI to rescue a booking product users had abandoned

Problem

Process

Design

Outcome

Appendix

Money Movement — Payments Vision