Office Tool
Office Tool
Internal event-management platform with role-based access control for safer and scalable operational workflows
Internal event-management platform with role-based access control for safer and scalable operational workflows
Context & Problem
The Office Tool was designed as an internal operational platform for stagedates employees to access and manage event-related information with role-based permissions.
Before this project, employees relied on a shared promoter admin account to access platform data. While this allowed fast access to information, it also created major operational and security risks. Employees could potentially access or accidentally modify sensitive live-event data unrelated to their responsibilities, and even small mistakes could directly impact customers, promoters, ticket sales, refunds, and business trust.
The platform managed highly interconnected live-event systems where actions in one area could create cascading effects across other parts of the platform. For example:
deleting a ticket with existing sales could automatically trigger customer refunds,
changing ticket or event visibility could unintentionally stop online ticket sales,
and accidental modifications could negatively affect promoter revenue and trust in the platform.
The Office Tool was designed as an internal operational platform for stagedates employees to access and manage event-related information with role-based permissions.
Before this project, employees relied on a shared promoter admin account to access platform data. While this allowed fast access to information, it also created major operational and security risks. Employees could potentially access or accidentally modify sensitive live-event data unrelated to their responsibilities, and even small mistakes could directly impact customers, promoters, ticket sales, refunds, and business trust.
The platform managed highly interconnected live-event systems where actions in one area could create cascading effects across other parts of the platform. For example:
deleting a ticket with existing sales could automatically trigger customer refunds,
changing ticket or event visibility could unintentionally stop online ticket sales,
and accidental modifications could negatively affect promoter revenue and trust in the platform.
The challenge was not only to create role-based access control, but to design safe operational workflows that balanced:
security,
usability,
scalability,
and implementation complexity.
Different departments required different visibility and action permissions (view, edit, delete), while the system itself needed to remain practical enough for everyday operational use.
The challenge was not only to create role-based access control, but to design safe operational workflows that balanced:
security,
usability,
scalability,
and implementation complexity.
Different departments required different visibility and action permissions (view, edit, delete), while the system itself needed to remain practical enough for everyday operational use.
Process & Exploration
The project started with discussions with the Product Owner and UX team to define the scope and understand the complexity of permission management within a live operational system.
A major part of the process involved evaluating how much flexibility was realistically necessary compared to the implementation effort and operational value it would create. Early discussions explored questions such as:
should every employee have individually configurable permissions,
can users belong to multiple roles,
how should role overrides work,
and how should the system communicate actions that affect other interconnected entities?
These discussions quickly revealed how rapidly complexity could scale inside a permission-based architecture.
Because event, ticket, sales, order, and promoter data were deeply interconnected, much of the work focused on dependency mapping and validation logic. Actions such as editing or deleting information could indirectly affect departments that might not even have direct access to the modified section. This led to extensive exploration around:
validation flows,
warnings,
visibility of system-impacting actions,
and safe operational UX patterns.
The project started with discussions with the Product Owner and UX team to define the scope and understand the complexity of permission management within a live operational system.
A major part of the process involved evaluating how much flexibility was realistically necessary compared to the implementation effort and operational value it would create. Early discussions explored questions such as:
should every employee have individually configurable permissions,
can users belong to multiple roles,
how should role overrides work,
and how should the system communicate actions that affect other interconnected entities?
These discussions quickly revealed how rapidly complexity could scale inside a permission-based architecture.
Because event, ticket, sales, order, and promoter data were deeply interconnected, much of the work focused on dependency mapping and validation logic. Actions such as editing or deleting information could indirectly affect departments that might not even have direct access to the modified section. This led to extensive exploration around:
validation flows,
warnings,
visibility of system-impacting actions,
and safe operational UX patterns.
The process included:
brainstorming sessions,
workflow mapping,
low-fidelity sketches,
competitor and tool analysis,
and iterative UI explorations to uncover hidden edge cases and operational risks.
Although most internal users had moderate to high technical literacy, reducing workflow complexity remained important because operational mistakes in live-event environments could have significant financial and trust-related consequences.
Instead of focusing purely on interface design, much of the work focused on:
defining scalable system logic,
simplifying operational workflows,
reducing unnecessary complexity,
and balancing ideal UX solutions with realistic development constraints.
The process included:
brainstorming sessions,
workflow mapping,
low-fidelity sketches,
competitor and tool analysis,
and iterative UI explorations to uncover hidden edge cases and operational risks.
Although most internal users had moderate to high technical literacy, reducing workflow complexity remained important because operational mistakes in live-event environments could have significant financial and trust-related consequences.
Instead of focusing purely on interface design, much of the work focused on:
defining scalable system logic,
simplifying operational workflows,
reducing unnecessary complexity,
and balancing ideal UX solutions with realistic development constraints.
Final Solution
The final concept introduced a structured internal management tool with modular role-based access control and scalable system architecture.
The initial release focused on:
event management,
employee access control,
and department-based visibility permissions.
Employees could only access the sections and actions relevant to their responsibilities, while admins retained centralized permission management.
The system architecture was intentionally designed to support future scalability, including:
expandable role hierarchies,
granular permissions,
and future multi-role support,
even though the first release intentionally simplified many of these capabilities to reduce implementation complexity and improve ROI.
A major design decision was prioritizing the 95% of operational use cases instead of over-engineering edge cases too early. More flexible but technically heavy solutions — such as fully customizable role structures and extensive permission overrides — were explored but intentionally simplified for the initial release.
The final concept introduced a structured internal management tool with modular role-based access control and scalable system architecture.
The initial release focused on:
event management,
employee access control,
and department-based visibility permissions.
Employees could only access the sections and actions relevant to their responsibilities, while admins retained centralized permission management.
The system architecture was intentionally designed to support future scalability, including:
expandable role hierarchies,
granular permissions,
and future multi-role support,
even though the first release intentionally simplified many of these capabilities to reduce implementation complexity and improve ROI.
A major design decision was prioritizing the 95% of operational use cases instead of over-engineering edge cases too early. More flexible but technically heavy solutions — such as fully customizable role structures and extensive permission overrides — were explored but intentionally simplified for the initial release.
To support faster implementation and reduce development overhead:
the UI reused the existing design system and components,
complex edge-case scenarios were intentionally limited,
and the first release scope was reduced to the most business-critical workflows.
This approach allowed the company to:
create a safer operational environment,
reduce risk around live-event management,
support future scalability,
and release a practical internal tool without investing heavily into unnecessary early complexity.
To support faster implementation and reduce development overhead:
the UI reused the existing design system and components,
complex edge-case scenarios were intentionally limited,
and the first release scope was reduced to the most business-critical workflows.
This approach allowed the company to:
create a safer operational environment,
reduce risk around live-event management,
support future scalability,
and release a practical internal tool without investing heavily into unnecessary early complexity.
My Role & Learning
My Role
Collaborated closely with the Product Owner, CPO, and technical stakeholders to refine product scope and workflow structures
Conducted brainstorming sessions and system-flow exploration
Designed user flows, permission structures, validation logic, and UI concepts
Explored hidden operational risks and interconnected system dependencies
Presented concepts and iterative progress to cross-functional teams
Contributed to discussions around scalability, simplification, and implementation feasibility
A large part of my contribution involved balancing:
operational safety,
usability,
technical feasibility,
business priorities,
and long-term scalability.
The project required strong systems thinking to identify where flexibility created value and where simplification created better operational and implementation outcomes.
My Role
Collaborated closely with the Product Owner, CPO, and technical stakeholders to refine product scope and workflow structures
Conducted brainstorming sessions and system-flow exploration
Designed user flows, permission structures, validation logic, and UI concepts
Explored hidden operational risks and interconnected system dependencies
Presented concepts and iterative progress to cross-functional teams
Contributed to discussions around scalability, simplification, and implementation feasibility
A large part of my contribution involved balancing:
operational safety,
usability,
technical feasibility,
business priorities,
and long-term scalability.
The project required strong systems thinking to identify where flexibility created value and where simplification created better operational and implementation outcomes.
Learnings
This project reinforced that strong UX in operational systems is not only about creating the most feature-rich or ideal solution, but about designing workflows that safely and effectively solve problems within realistic business, technical, and time constraints.
Key learnings included:
complex internal systems can quickly become over-engineered if edge cases are prioritized too early,
scalable architecture does not always require immediate full implementation,
and simplifying workflows can often improve both usability and implementation ROI.
The project also strengthened my understanding of designing safe operational UX for interconnected business systems, where even small interface decisions can have significant financial, operational, and trust-related consequences.
Learnings
This project reinforced that strong UX in operational systems is not only about creating the most feature-rich or ideal solution, but about designing workflows that safely and effectively solve problems within realistic business, technical, and time constraints.
Key learnings included:
complex internal systems can quickly become over-engineered if edge cases are prioritized too early,
scalable architecture does not always require immediate full implementation,
and simplifying workflows can often improve both usability and implementation ROI.
The project also strengthened my understanding of designing safe operational UX for interconnected business systems, where even small interface decisions can have significant financial, operational, and trust-related consequences.