Overview
Role
Timeline
The Challenge
At my company, we host a diverse range of events - from large scale international conferences to galas.
Event planning involves many moving parts: session and speaker logistics, AV cues, catering, volunteer coordination, and so on.
The multiple teams, platforms, documents cause friction within and between teams. Eventually human error leaks to the public.
The challenge was to design a tool that simplifies the complexities of event planning and centralizes simplicity, providing all the necessary features for team management while effectively communicating that with the public in a timely manner.
Key Pain Points
Use of multiple planning platforms create redundancy and confusion
Difficult to find (individual or team) responsibilities
Updates to public schedules aren't timely
(ie. incomplete/outdated)
Cross-team collaboration is difficult to maintain across multiple teams and channels
Real-time example of duplicated "Official" event schedules
THE PROCESS
PART 1: RESEARCH
EXPLORING USER NEEDS
Understanding Two Groups of Users
To build an events builder that supports the full lifecycle of event planning, I needed to understand the needs of the two groups.
I first conducted qualitative interviews with event planners, organizers, and project managers to understand their workflows, frustrations, and mental models around building out schedules for the day of.
Then spoke with event attendees to understand how they interpret schedules, what confuses them, and what makes them feel prepared throughout an event.
Overall — Many described using multiple disconnected tools, Google Sheets, WhatsApp, PDFs, email threads. which often led to miscommunication and duplicated effort.
Overall — Friction points around unclear session details, schedule changes, and the lack information for event day.
MARKET RESEARCH
Diverse events of different scales and types, requires customized itineraries that are similar, but can contain different components (ie. filters, locations — depending on the needs of the event).
To understand how event itineraries are currently structured at scale, I analyzed existing tools and patterns by doing an audit of a range of events, varying in scale, audience, and type.
To identify the key features needed to build out a scalable system, I completed a competitor analysis of SXSW, ViiV Healthcare, and RGB Design Thinkers Conference, followed by a feature prioritization matrix.
Key Insights
Filtering is a universal feature, but overuse can be counterproductive
Showcasing sessions & speakers was one of the most fundamental features
Speaker details: connecting social media (helps with: credibility, and opportunities to network)
Bookmarking: beneficial especially for large conference, but can require users to make accounts to personalize/save
Accessibility and mobile optimization seems to be a weakness across many platforms
Overall — There’s a gap between highly functional but visually heavy systems (like SXSW) and smaller scale, limited systems. My goal is to design a scalable itinerary sy stem that allows for both types of systems.
PART 2: DEFINE
I noticed that event planners and organizers wanted to have better ways to organize cross-team workflows so all team members are aware of any updates to the itinerary.
User Personas and User Journey Maps
I created 2 personas, from my user interviews to showcase the two groups I was analyzing.
From my user personas, I developed a set of user scenarios that illustrate the needs, motivations, and pain points.
Organizer Persona
Attendee Persona
The user scenarios helped highlight moments where coordination often breaks down. It also guided critical design decisions around categorization, notification logic, and how information should be structured for two user groups with very different priorities.
How Might We Statements
The following questions were created to help identify the key pain points for each user group.
PART 3:IDEATE
CREATING THE FRAMEWORK
With a clearer understanding of my audience and the key points of friction, I began exploring how the app could function as a system.
I started off by focusing on understanding how to create a scalable system using the same set of atoms -> molecules -> organisms. I needed to understand this to understand what inputs had to be made during the onboarding of creating any sort of itinerary.
Understanding the Input
Storyboarding
Afterwards I set to explore how I could filter and create custom schedules, and started to storyboard how the schedule would look like to attendees.
These early explorations helped me break down the core components of the system: dates, speakers, and different inputs.
I experimented with different ways to visualize filters, and visualize how attendees would be able to navigate on the platform.
Cross-team Syncing
As I mapped user flows and storyboards, it became clear that a single linear itinerary experience would not fully support the needs uncovered in research. This realization led to an important shift in thinking: a multi-mode ecosystem with event planning & publishing an itinerary.
The concept of cross-mode syncing emerged as a way to separate internal planning from public-facing experiences while keeping them connected through a shared system.
So I started to brainstom how to create a relationship between the two different system entities.
Content Governance
Large scale teams would require need the platform to allow for set rules, systems, and workflows to help control how content is created, reviewed and published.
In order to reduce redundant edits and intentional updates, I created access tiers to minimize and prevent accidental updates to the public.
This architecture enforces role-based permissions, separation of concerns, and accountability, while maintaining a single source of truth.
Hierarchal Access
Storyboarding Continued.
Cross Mode Syncing
Throughout this phase, I continuously evaluated how each idea supported the dual-system model, ensuring the platform stayed scalable for organizers while remaining intuitive and streamlined for attendees. This ideation work formed the foundation for a more refined, user-informed design direction.
By combining hierarchical access, cross-mode syncing, and governance workflows, EventFlow supports complex, multi-day events with clarity, flexibility, and reliability.
User Flow
This userflow served as a blueprint for wireframing and prototyping, making the app’s multi-layered system intuitive and scalable.
PART 4: LOW-FIDELITY DESIGN
TESTING THE STRUCTURE
ONBOARDING SCREENS
ONBOARDING
DASHBOARD
Public/Team Toggle : easy switch between the two interfaces
Publish CTA (limited ability based off rights)
Event editing
Date Options
Schedule
Title
Time
Description
Speakers
Options to add more to the schedule
Navigation Bar:
Home and & Custom Editing Design option.
PUBLIC MODE
Overview:
Full view of all upcoming events
Setting/Profile Options
Individual Events:
High level overview of event (Key details from onboarding)
Countdown
Option to enter Team or Public Mode
Ability to add another event to the list
Session Addition
Input in order of importance and requirements (time, name, and description requirements)
Filtering options
location
Filters added from onboarding session
Option to add a profile
TEAM MODE
Usability Tests
To ensure EventFlow would be intuitive and easy to adopt, I conducted low-fidelity usability testing with five participants, all with experience in event planning or team coordination. The goal was to validate that the platform would not introduce a steep learning curve while identifying gaps in functionality and interaction design.
During these sessions, I walked participants through key concepts and workflows, discussed their expectations, and observed how they interpreted the layouts and features.
While the overall concept was well understood, the testing revealed missing micro-interactions, unclear transitions between features, and opportunities to strengthen the system’s usability. These findings helped shift my focus toward refining core workflows and adding essential supporting features.
Key Findings
DASHBOARD
Overall:
Participants understood the dashboard as a high-level overview (underwhelmed).
Key Findings:
Limited ability to sort or filter events.
Option to view past events, especially if the platform is used repeatedly over time.
Insight:
The dashboard needs to better support event lifecycle management, not just active events.
PUBLIC ITINERARY
Overall:
The Public Facing Mode was the most intuitive
Key Findings:
Users clearly grasped the input → output relationship.
How are filters added, edited, and interacted with?
"What happens when you push publish?"
> Absence of a clearly defined final published itinerary view.
Insight:
While the concept was intuitive, users needed stronger confirmation of what the end experience for attendees would look like.
TEAM INTERFACE
Overall:
Team Mode generated the most questions, but also the most interest.
Key Findings:
Clearer interactions for adding, editing, tagging, and assigning team members.
"Are there teams?"
Multiple participants suggested a chat or notification feature to support real-time communication, especially for time-sensitive updates.
Insight:
Team Mode has the highest complexity and therefore requires stronger affordances, clearer hierarchy, and better communication cues to support collaboration.
Overall Takeaways
Stronger bridging features between modes
Clearer final-state views
Supporting micro-interactions that reduce friction and uncertainty
Fine tuning the Systems Architecture
To reduce friction when organizing event-related tasks, I worked closely with an Events Manager to identify the types of tasks typically created during event planning. Together, we defined an initial set of high-level task categories based on real operational workflows.
I then conducted a card-sorting exercise with seven participants to evaluate how effectively different category structures supported task classification. Participants tested sets of 4, 6, and 8 categories, allowing me to assess the tradeoff between simplicity and clarity, as well as the impact on task selection speed and user confidence.
The results showed that six categories consistently led to faster completion times and lower hesitation, striking the best balance between structure and flexibility.
PART 5: VISUAL DESIGN & FINAL SOLUTION
BRINGING THE APP TO LIFE
LOGO
Branding & Visual Identity
I chose the name ‘EventFlow’ to reflect the core goal of the product: creating a uninterrupted flow between planning, coordination, and execution. The goal was the brand to emphasizes clarity and movement. The visual identity is intentionally minimal and flexible, allowing it to scale across different types of events without feeling overly rigid or prescriptive.
The UI tone is designed to feel confident, calm, and operational, prioritizing readability and hierarchy. A combination of light mode and dark mode is used strategically to help distinguish between different contexts of use. Light mode supports public-facing and attendee experiences, while dark mode is used for internal team workflows.
Subtle colour accents and consistent spacing help guide attention, support categorization, and reduce cognitive load, ensuring the interface feels intuitive even when managing complex, multi-layered event information.
EventFlow UI Kit
ONBOARDING
CROSS MODE SYNCING
TEAM MODE : ADDING TASKS
TEAM MODE : ADDING TEAM MEMBERS
PART 6: REFLECTION & NEXT STEPS
Final Usability Test
KEY INSIGHTS
Overall
Participants generally described the experience as simple and approachable; however, as workflows became more complex, areas of friction began to surface. This reinforced the importance of strengthening information hierarchy and clarifying system logic, particularly for power users managing larger events.
Team Page
Users found the interface simple but visually dense, highlighting the need for some kind of breakdown as users find their way to the dashboard or clearer hierarchy as task complexity increases.
Pre-defined task categories helped some users organize quickly, but others hesitated when classifying tasks, revealing a tradeoff between structure and flexibility.
Task Ownership & Visibility
As task lists grow, ownership becomes harder to track. Introducing colour tagging allows teams to maintain an “All Tasks” view while quickly identifying responsibility.
Participants requested a “My Tasks” view to support personal task management within larger team workflows.
Publishing & Feedback
The Publish button caused confusion, as users were unsure when actions were finalized, leading to my decision to remove the manual publishing in favour of auto-save, reducing cognitive load while preserving cross-mode accuracy.
Itinerary Page
The public itinerary was consistently understood with minimal guidance.
Users requested the option to add additional filters to support more complex schedules without sacrificing clarity.
PRIORITY REVISIONS
My primary goal in this project was designing a scalable and intuitive team-facing system, focusing on how tasks, schedules, and content publishing could work seamlessly behind the scenes. The public-facing interface was not fully developed in this phase, but it remains a clear next step.
Moving forward, I would refine the user flow to make interactions more intuitive, expand features for customization and filtering, and improve interactive design elements, including loading times and screen transitions. A key lesson from this project was the importance of balancing structure and flexibility—pre-defined categories help with organization but need thoughtful implementation to accommodate diverse user workflows.
