Case study · 2021 – 2026
Redesigning a SaaS platform for photo booth operators — web and mobile
Company
Photobooth Supply Co.
Role
Product Designer · Photobooth Supply Co.
Scope
Web & Mobile · Design Systems · User Research
Timeline
2021 – 2026
Overview
The company
Building software for the photo booth industry
Photobooth Supply Co. makes hardware and software for photo booth operators — people who run photo booths at weddings, corporate events, and parties. The software is a SaaS platform that lets operators manage their events, configure their booths, control what guests see and print, and handle their galleries.
The platform exists as both a web app (where operators do most of their setup and management) and a mobile iOS app (used on event days). I joined as the product designer responsible for both.
SaaS
Web
iOS
Design systems
User research
IA
The users
A wide range of users — not just one type of operator
The people using Fiesta are photo booth operators, but that's where the similarity ends. Some are highly technical — they want granular control, custom configurations, and they'll read documentation. Others are not tech-savvy at all and need the software to be self-explanatory. The age range runs from early twenties to people who've retired from another career and bought a photo booth as a new venture.
Some users run their booth as a weekend side hustle alongside a full-time office job. Others have it as their sole source of income — a full-time business with multiple booths and staff. They come from very different backgrounds: photographers, wedding and event planners, DJs, hospitality workers, and people with no event industry background at all who simply decided to start a business.
Designing for this range, same product, same screens, meant the interface had to work for the expert who wants speed and power, and the first-timer who needs clarity and confidence on event day when things go wrong.
My role
Product designer across web and mobile
I've been a product designer at PBSCO for 5 years, working as part of a two-person design team. My work spanned the full product — from the operator-facing admin platform to the guest experience. I worked closely with engineering, product managers and stakeholders on everything from new feature design to information architecture to the design systems that keep both platforms consistent.
The work covers the full design process: research and discovery, informational architechture and flows, component design, prototyping, handoff, and ongoing iteration after launch.
9 min
Average time to create a new event
— supported by a built-in resource library of templates, overlays, photo strip designs, and an operator academy
2 systems
Admin and Guest design systems
— two separate systems built for operator-facing and guest-facing experiences
Web + iOS
Consistent across platforms
— same patterns, terminology, and IA on both web and mobile
The problem
Starting point
One product, an enormous range of people using it
The core challenge wasn't a broken product, it was a product that had grown organically to serve an extremely wide range of operators with fundamentally different mental models, technical comfort levels, and workflows. Someone who runs photo booths full-time and has used the software for years approaches it completely differently from someone who bought a booth as a weekend side business and opens the app once a month.
“ I have support articles printed out to help me set up an event.”
The platform had to work for both. There was no separate lite mode or power user tier, everyone used the same screens, the same settings, the same navigation. Making that feel clear and manageable for a first-timer without slowing down an expert was the design problem that ran through everything.
Research
Talking to operators and listening to the people who talk to them every day
We did all of it — user interviews, support ticket analysis, usability sessions, heuristic audits. The customer support team was a particularly valuable source: they were in direct contact with operators daily and had a clear picture of where people got stuck and what kept coming back as a problem.
The most important thing we learned was the depth of the user range. It wasn't just 'some operators are more technical than others', the gap was enormous. The same feature that felt completely intuitive to a photographer with years of experience was confusing for someone who had just bought their first booth. That finding became the lens through which every subsequent design decision got evaluated.
Conducted user interviews and synthesised in Dovetail
Information architecture
Structuring the product
Organising a feature-dense platform around what operators actually do
Fiesta covers a broad range of operator needs: configuring the camera, setting up capture modes and effects, managing branding and overlays, controlling the gallery, sharing and printing. The IA challenge was organising all of that in a way that felt obvious regardless of technical background.
Before the redesign, a lot of settings and actions were scattered across the product without a clear logic. The bigger problem was repetition: operators had to redo the same setup steps every time they created an event, even for things that didn't change event to event. The goal was to remove that friction, help operators set things up once, in a way that carried over, rather than starting from scratch each time.
The platform is now structured around 8 distinct sections, Interface, Camera, Modes, Effects, Branding, Live Gallery, Sharing, and Printing, each mapped to a clear job-to-be-done, and arranged so that operators move through them in the natural order of setting up a booth.
Mapped out the app's architecture and brainstormed ways to enhance it
Navigation redesign
Settings arranged as a wizard — left to right, in the order operators actually use them
The navigation in the redesigned platform follows the natural order of booth setup. Operators move left to right through the 8 sections, starting with Interface and Camera, through Modes, Effects, and Branding, and finishing with Live Gallery, Sharing, and Printing. It mirrors how they'd actually work through setting up an event, which means the structure teaches itself.
The same 8-section model runs across both the web dashboard and the iOS app, so operators who learn the structure on web don't have to relearn it on mobile on event day, when there's no time or patience for confusion.
Before
After
Feature design process
How we work
From top-down priorities to ideas from everywhere
In the early years, most feature direction came from leadership, the priorities were set from above and the design work followed. Over time that changed. As the team grew more confident in the product and the user base, ideas began coming from everywhere: operators surfacing needs directly, support flagging recurring friction, and the design and product team identifying gaps through their own product thinking.
Design gets involved early, before there's anything visual to do. Understanding whether a problem is worth solving, for whom, and under what constraints is part of the work, not a prerequisite to it.
01 · Discovery
Understand the signal
Ideas come from multiple directions: operator requests, recurring support themes, gaps spotted during product reviews. Before any design work starts, the signal gets pressure-tested: is this one operator's edge case, or something broader? That distinction shapes everything.
02 · Definition
Scope and align
Once a problem is worth solving, the team aligns on scope, constraints, and what 'done' looks like before design begins. This step keeps exploration focused, it's easier to generate good ideas when the edges are clear.
03 · Design
Explore and refine
Multiple directions get explored before committing to one. Concepts are tested against the operator range — does this work for the technical power user and the first-timer? Feedback from the team and sometimes from operators shapes the refinement until there's a clear recommendation.
04 · Ship
Hand off and learn
Handoff to engineering is detailed: annotated specs, edge case documentation, and staying available through build. After launch, the work isn't done: support data, operator feedback, and usage patterns tell you whether it landed the way you intended.
Design Studio
Building a design tool for non-designers
Design Studio gives admins a library of pre-designed templates: strips, overlays, frames, and a built-in editor to customise them for any event. No design skills needed.
From the idea to MVP to future releases FigJam file
References for the new Design Studio library
Design systems
Two systems, two contexts
Admin system and Guest system, built separately for different audiences
The product has two distinct user groups with very different needs: operators (who set up and manage everything through the admin interface) and guests (who interact with the booth and gallery experience). One monolithic system wouldn't work for both, the visual language, tone, and interaction patterns are fundamentally different.
The Fiesta Admin design system covers everything operators touch: event management, hardware configuration, settings, analytics, and galleries. The Guest design system covers the in-booth and guest-facing gallery experience. Each has its own component library, token set, and documentation.
Fiesta Admin system
For operators managing their business
Covers the web dashboard and iOS app that operators use day-to-day. 8 main sections: Interface, Camera, Modes, Effects, Branding, Live Gallery, Sharing, and Printing, each with their own set of components and settings patterns. Built to be functional, clear, and fast to use under event-day pressure.
Guest design system
For guests interacting with the booth
Covers what guests see and interact with at the event. The core is the in-booth interaction — selecting a capture mode, choosing filters, backgrounds, and overlays before taking their photo. Different visual language from the Admin system: more expressive, brand-flexible, and designed to feel like part of the event itself.
Building the system
Starting from visual identity and building outward
The Fiesta Admin system is anchored in a strong visual identity that stays consistent across all sections of the platform. That visual foundation came first; the component library and token system were built on top of it, section by section, as the product grew.
The Guest system required a fundamentally different approach. Where Admin is built for efficiency and control, the Guest UI is built for the momen, expressive enough to feel like part of the event, flexible enough to accommodate the branding operators apply on top. The two systems share no components directly, but maintain a relationship through shared principles around spacing, feedback, and interaction behaviour.
Over 5 years, both systems grew alongside the product. New sections, new components, new patterns, the system had to absorb all of that without losing coherence. That meant periodic audits to catch drift, conversations with engineering when implementation diverged from design intent, and ongoing decisions about what to standardise and what to leave flexible. A design system on a live product is never finished; it's maintained.
Admin UI Kit in Figma
Admin Design System in Notion
Selected screens
Web App
Complexity of the admin role
Admins don't just run events, they configure them. The web app is where everything gets set up before the booth goes live: capture modes, templates, camera behaviour, gallery sharing. Designing for this meant balancing depth of control with a setup flow that works for non-technical users under time pressure.
Event dashboard
Preview personalisation
Camera settings on web app
Guest Experience
(iOS)
Designed for everyone at the party
A photo booth is used by guests of all ages, from kids to grandparents, often in a loud, busy environment, and sometimes by people who don't speak English. The iOS app needed to feel instantly familiar, not require reading.
I drew on interaction patterns people already know from Instagram, TikTok, and Snapchat: swipeable mode selection, large tap targets, and icon-led controls that communicate through shape rather than text. The result is a flow most guests can navigate without instruction.
Tap to Start
Taking a capture
Tip to make a selection
Key challenges
Challenge 01
Designing for an extreme range of technical confidence
The same interface had to serve a retired photographer who's been using the software for years and someone who bought their first booth last month. There was no tiered product, just one platform. Every labelling decision, every settings hierarchy, every error state had to work for both ends of that spectrum simultaneously.
Challenge 02
Keeping web and iOS in sync across a growing feature set
As new features shipped on web, they eventually needed to exist on iOS too, but the two platforms have different form factors, interaction patterns, and contexts of use. Operators use the web dashboard to set things up; they use iOS on event day, under pressure. Maintaining a shared mental model across both without forcing the same UI onto different contexts was an ongoing design challenge.
Challenge 03
Two design systems that can't drift too far apart
The Admin and Guest systems are intentionally different, but they can't become entirely separate languages over time. As both systems evolved across 5 years, maintaining a coherent relationship between them, shared principles, consistent terminology, compatible interaction patterns, required constant attention alongside the feature work happening in parallel.
Challenge 04
Settings at the event level that probably belong at the account level
One thing I'd revisit is where certain settings live. Some configuration that we placed at the event level, where operators set it up per event,would have been better handled at the account level, set once and inherited. Operators ended up repeating work they shouldn't have had to repeat. It's a structural decision that's hard to undo once it's embedded in the product.
Reflection
What I learned
Research is still necessary, even when the company already knows its users
PBSCO had a lot of internal knowledge about operators, there are photo booth owners on the team, and the support department talks to users every day. I went in thinking that gave us a head start on understanding the user. It does, but it's not the same thing as research. Support views operators through the lens of problems to resolve. That's valuable, but it's a different angle than understanding how operators think, what they're optimising for, and how they actually experience the product.
If I were starting over, I'd push harder for dedicated research time upfront, even with all that existing knowledge in the room. The other thing I'd change is how I worked with engineering during build. I'd push for more visibility into what was being built as it was being built, more check-ins, more shared context, so that what shipped was closer to what was designed, and surprises on both sides were fewer.
baida.masha@gmail.com