Product Design · UX Strategy · SaaS Dashboard
StudioFlow
A booking-to-delivery management tool for boutique photography studios — one owner-first view that replaces WhatsApp threads, a stale Excel sheet, and phone calls with a single source of truth for every client contract.
01 — Brief & context
One pipeline, three disconnected tools
Every studio contract moves through the same lifecycle: a client inquires, the studio confirms a booking, the shoot happens, the work gets edited, it's delivered, and payment is settled. Right now that entire chain lives across WhatsApp threads, Excel rows, and phone calls that no one else can see. The problem isn't that the studio lacks tools — it's that no single person, not even the owner, has one reliable view of where every client currently stands. Excel goes stale the moment it's not updated live, WhatsApp threads get buried under the next inquiry, and phone calls leave no record at all. Day-to-day decisions — who's shooting Saturday, who still owes a balance payment, whose album is running late — end up relying on memory and manual cross-checking between three places that don't talk to each other.
I designed against one specific studio type rather than "studios" in the abstract: a boutique wedding & event photography/videography studio running a mixed slate of shoot categories — wedding, pre-wedding, maternity, newborn, birthday, corporate, and event coverage. One location, one owner, a small team of 3–6 photographers/videographers/ editors, and roughly 15–40 live client contracts running at any given time. Anchoring to a real, specific business kept scope decisions grounded instead of theoretical.
02 — Who I designed for
Owner-first, not owner-only
I designed primarily for the owner, because they're the one point that touches every stage of the pipeline — inquiry, scheduling, payment, delivery — and the one absorbing the cost of today's chaos. What the team and the client see follows from what the owner needs them to see, not the other way around.
Primary
The Studio Owner
Runs the business day to day, makes the final call on bookings, payments, and team assignment, and is personally accountable to every client. Today, the owner is the only person holding the complete picture together — in their head, across three disconnected tools.
Secondary
The Team
Photographers, videographers, editors, and sometimes a coordinator, who execute the shoot and the edit. They need to know what's booked, when, and what a client was promised — without calling the owner to find out.
Tertiary
The Client
Wants reassurance that their event is on track and clarity on when they'll receive their deliverables, without repeatedly messaging the studio to ask.
03 — Scope
Four problems, in priority order
Ranked by how much day-to-day chaos each one currently causes:
-
1
One place to capture and track every client and booking — replacing the Excel sheet as the studio's single source of truth for who's booked, for what event, and when.
-
2
A visible stage-by-stage status per booking — Inquiry → Booked → Shoot Scheduled → Shot → Editing → Delivered. The biggest time-loss isn't getting a client, it's losing track of where an already-confirmed job stands once there are 15+ running in parallel.
-
3
Payment tracking per booking — advance received, balance due, due dates. Money is the second most common reason for WhatsApp and phone chasing, and today it lives only in memory or a stray Excel column.
-
4
A simple, read-only status view the studio can share with the client — cuts down the "where is my album / video" follow-ups, which make up the bulk of inbound client-initiated contact after a shoot is done.
I deliberately stopped at four problems rather than five, and six screens rather than more, given the compressed timeline. A smaller, well-reasoned system felt truer to the brief than a shallow pass at everything a studio could theoretically need.
04 — What I deliberately left out
Six things I didn't build, and why
-
×
Two-way in-app chat/messaging — WhatsApp already works for real-time conversation. Rebuilding it inside the product adds cost without solving the actual gap, which is status visibility, not communication.
-
×
Payment gateway integration — logging payment status is the v1 priority; collecting money online is a separate, larger problem worth tackling once manual tracking proves useful.
-
×
Lead generation / marketing tools — the brief starts from "client inquires," so lead capture happens outside the product, with booking creation as the product's entry point.
-
×
Contract e-signing and formal invoicing/GST — real needs, but not what's causing the day-to-day chaos described in the brief. Adding them now would dilute a focused v1.
-
×
Multi-branch / franchise management — I scoped to a single location to keep v1 buildable; coordination pain is sharper within one team than across branches.
-
×
Granular team permissions — v1 assumes a small, trusted team where the owner grants broad visibility by default. A full roles/permissions system is premature before there's evidence of who actually needs restricted access.
05 — The system
Six screens, one flow
An inquiry — still happening outside the product, over call or WhatsApp — becomes a New Booking. It lands on the Bookings list and Dashboard. The owner assigns a team member and moves it through stages on Booking detail as the shoot happens. Payments are logged as they come in on Payments. Once delivered, the booking is marked complete. Throughout, the client checks the shared status view instead of messaging in.
Dashboard — the owner's morning glance
Four stat cards — today's shoots, pending deliveries, overdue amount, active bookings — answer "what's urgent" before the owner reads a single row. Today's Schedule and Upcoming Deliveries below turn that summary into the actual next actions, so the first five seconds of the day don't require opening Excel or scrolling WhatsApp.
Bookings list — one list, not one spreadsheet
Every booking, one row each — client, event type, date, stage, and payment status — searchable and filterable by stage or shoot type. This is the direct replacement for the Excel sheet: the same information, but live, shared, and never out of date the moment someone else updates a booking.
New booking — the moment an inquiry becomes a job
A single-page form — client details, event type, package, date, and advance — so a confirmed inquiry becomes a tracked booking in one step, on the spot, instead of waiting for someone to remember to add a row to a spreadsheet later.
Booking detail — the screen everyone returns to
Stage tracker, payment, and notes on one screen
Inquiry → Booked → Shoot Scheduled → Shot → Editing → Delivered is rendered as a single horizontal tracker so the owner can see exactly how far a job has moved without reading a status label. The payment breakdown sits beside it rather than on a separate tab, since balance-due is usually the second question the owner is answering in the same glance. Once there are 15–40 bookings running in parallel, this is the screen the owner opens most.
Payments — a studio-wide answer to "who owes what"
Booking detail answers "where does one payment stand"; this screen answers it at the studio level — total revenue, payments due, and overdue outstanding up top, then a per-client installment table with Due Soon / Overdue / Paid filters. The Overdue Alerts panel turns "I should chase Sneha about her balance" into a one-click Remind Client action.
Client status view — a status view with nothing internal in it
Same stage tracker, stripped down
The client-facing view reuses the same six-stage progress language as the booking detail screen, so the studio never has to explain two different systems. It shows only what a client needs — current stage, delivery ETA, and their package — with every internal note, payment figure, and team assignment left out. That's the whole point: reassurance without exposure.
06 — At a glance
All six, side by side
The complete system spans dashboard, booking list, intake, stage tracking, payments, and the client-facing status view — one consistent visual language throughout.
Dashboard
Bookings list
New booking
Booking detail
Payments
Client status view
07 — Assumptions
What v1 takes for granted
- –
Single studio location for v1, not a multi-branch operation.
- –
Client access is a lightweight shared link (or OTP-based view), not a full account system with login/signup.
- –
The team is small and trusted enough that broad visibility by default is acceptable for v1.
- –
Payment tracking is manual entry against advance/balance, not connected to a live payment gateway.
- –
WhatsApp remains the channel for actual back-and-forth conversation; the product isn't trying to replace it, only to hold the status that conversation currently has to carry.
08 — Result
Scope
6
Screens designed
4
Core problems solved
3
User tiers designed for
A smaller, well-reasoned system, sized to a compressed timeline and a real studio's actual pain points, rather than a shallow pass at everything a studio could theoretically need.