Booking Office
Booking Office
On-site ticket-selling system designed for fast-paced venue operations, live ticket management, and simplified sales workflows.
On-site ticket-selling system designed for fast-paced venue operations, live ticket management, and simplified sales workflows.
Context & Problem
The Booking Office project was designed as an on-site ticket selling system for event promoters and venue staff. The goal was to allow tickets to be sold and printed directly at venues while keeping the ticket contingent synchronized with the online platform to prevent overselling.
The system needed to support fast-paced real-world environments such as crowded venues, noisy ticket counters, low-light situations, and standing queues. Users often needed to quickly switch between different events while handling multiple customers under pressure. At the same time, the interface had to remain simple enough to be understood with minimal training.
Before this project, no such internal solution existed within the company. Promoters often sold tickets manually or purchased tickets on behalf of customers through the normal online flow, leading to fragmented sales tracking and inconsistent ticket management.
The Booking Office project was designed as an on-site ticket selling system for event promoters and venue staff. The goal was to allow tickets to be sold and printed directly at venues while keeping the ticket contingent synchronized with the online platform to prevent overselling.
The system needed to support fast-paced real-world environments such as crowded venues, noisy ticket counters, low-light situations, and standing queues. Users often needed to quickly switch between different events while handling multiple customers under pressure. At the same time, the interface had to remain simple enough to be understood with minimal training.
Before this project, no such internal solution existed within the company. Promoters often sold tickets manually or purchased tickets on behalf of customers through the normal online flow, leading to fragmented sales tracking and inconsistent ticket management.
The challenge was not only to create a ticket-selling interface, but to design an operational system that balanced:
speed and validation,
simplicity and scalability,
business constraints and user needs,
while keeping development effort realistic for a growing startup environment.
The challenge was not only to create a ticket-selling interface, but to design an operational system that balanced:
speed and validation,
simplicity and scalability,
business constraints and user needs,
while keeping development effort realistic for a growing startup environment.
Research, Process & Exploration
The project started with competitive analysis and research into existing ticket-selling systems, including online research and in-person observation of cashier and self-checkout workflows to better understand real operational behaviors and friction points.
A large part of the process focused on contextual awareness:
how users behave under queue pressure,
how mistakes happen in crowded environments,
and which interactions create unnecessary cognitive load.
Key operational risks included:
overselling tickets,
selecting the wrong event,
payment and cash mismatches,
printing mistakes,
and slowing down queues through unnecessary validation steps.
The project started with competitive analysis and research into existing ticket-selling systems, including online research and in-person observation of cashier and self-checkout workflows to better understand real operational behaviors and friction points.
A large part of the process focused on contextual awareness:
how users behave under queue pressure,
how mistakes happen in crowded environments,
and which interactions create unnecessary cognitive load.
Key operational risks included:
overselling tickets,
selecting the wrong event,
payment and cash mismatches,
printing mistakes,
and slowing down queues through unnecessary validation steps.
Stakeholder discussions with product and business teams also explored future scalability scenarios. Although the company was still small, the system architecture needed to consider future possibilities such as:
multiple promoters using the same venue,
simultaneous nearby events,
and expansion toward self-checkout workflows in the future.
To explore the complexity, user flows were created for multiple operational scenarios, validation patterns, seating-plan interactions, event switching, and payment flows. Many iterations and UI drafts were explored to identify hidden edge cases and reduce unnecessary complexity.
The process continuously balanced:
usability,
implementation effort,
operational speed,
and long-term scalability.
Stakeholder discussions with product and business teams also explored future scalability scenarios. Although the company was still small, the system architecture needed to consider future possibilities such as:
multiple promoters using the same venue,
simultaneous nearby events,
and expansion toward self-checkout workflows in the future.
To explore the complexity, user flows were created for multiple operational scenarios, validation patterns, seating-plan interactions, event switching, and payment flows. Many iterations and UI drafts were explored to identify hidden edge cases and reduce unnecessary complexity.
The process continuously balanced:
usability,
implementation effort,
operational speed,
and long-term scalability.
Final Solution
The final solution introduced a simplified on-site ticket-selling system closely aligned with the company’s existing checkout structure and component system.
The system supported:
live ticket contingent synchronization with the online platform,
event switching with minimal friction,
seating-plan based ticket selection,
cash and payment handling,
and fast ticket printing workflows.
A major design decision was to keep users within a single interface during the selling process to reduce confusion and learning effort. Only the most relevant event and ticket information was displayed to avoid cognitive overload in high-pressure situations.
Several seemingly useful features were intentionally excluded after evaluating their operational impact:
sending tickets via email,
assigning tickets to user accounts,
ticket personalization,
and built-in calculator functionality.
The final solution introduced a simplified on-site ticket-selling system closely aligned with the company’s existing checkout structure and component system.
The system supported:
live ticket contingent synchronization with the online platform,
event switching with minimal friction,
seating-plan based ticket selection,
cash and payment handling,
and fast ticket printing workflows.
A major design decision was to keep users within a single interface during the selling process to reduce confusion and learning effort. Only the most relevant event and ticket information was displayed to avoid cognitive overload in high-pressure situations.
Several seemingly useful features were intentionally excluded after evaluating their operational impact:
sending tickets via email,
assigning tickets to user accounts,
ticket personalization,
and built-in calculator functionality.
These features were removed because they increased queue time, introduced additional error possibilities, or required unnecessary development effort compared to their practical value in crowded live-event environments.
The solution prioritized:
operational clarity,
fast learnability,
low training effort,
reduced friction,
and realistic implementation scope.
At the same time, the structural thinking behind the system allowed future expansion without requiring a completely new product architecture.
These features were removed because they increased queue time, introduced additional error possibilities, or required unnecessary development effort compared to their practical value in crowded live-event environments.
The solution prioritized:
operational clarity,
fast learnability,
low training effort,
reduced friction,
and realistic implementation scope.
At the same time, the structural thinking behind the system allowed future expansion without requiring a completely new product architecture.
My Role & Learning
My Role
Prepared initial requirements through discussions with cross-functional teams
Conducted functional analysis and workflow exploration
Created multiple UI concepts and iterative solution directions
Designed flows for operational scenarios, validation handling, and event switching
Helped balance user needs, technical feasibility, business priorities, and implementation scope
Transferred the final concepts into the company’s existing design structure and component system
A large part of my contribution involved simplifying the product strategically rather than continuously adding features. Many ideas initially sounded valuable, but deeper operational analysis revealed that they would create more friction, cognitive load, or implementation complexity than actual value for users.
My Role
Prepared initial requirements through discussions with cross-functional teams
Conducted functional analysis and workflow exploration
Created multiple UI concepts and iterative solution directions
Designed flows for operational scenarios, validation handling, and event switching
Helped balance user needs, technical feasibility, business priorities, and implementation scope
Transferred the final concepts into the company’s existing design structure and component system
A large part of my contribution involved simplifying the product strategically rather than continuously adding features. Many ideas initially sounded valuable, but deeper operational analysis revealed that they would create more friction, cognitive load, or implementation complexity than actual value for users.
Learnings
This project reinforced that designing internal operational tools requires a different mindset than designing purely consumer-facing products.
Strong UX decisions are not always about creating the most feature-rich or visually advanced solution, but about:
understanding operational environments,
reducing friction under pressure,
minimizing user errors,
and building systems that solve problems effectively within real business, technical, and time constraints.
The project also strengthened my understanding of system architecture thinking — designing solutions not only for current requirements, but in a way that allows future scalability and extension without rebuilding the product from scratch.
Learnings
This project reinforced that designing internal operational tools requires a different mindset than designing purely consumer-facing products.
Strong UX decisions are not always about creating the most feature-rich or visually advanced solution, but about:
understanding operational environments,
reducing friction under pressure,
minimizing user errors,
and building systems that solve problems effectively within real business, technical, and time constraints.
The project also strengthened my understanding of system architecture thinking — designing solutions not only for current requirements, but in a way that allows future scalability and extension without rebuilding the product from scratch.