Mid-size live event venues (2,000 to 10,000 capacity) operate at the intersection of hospitality, logistics, and finance, but the tools they rely on were not built for that complexity. A typical venue operations manager juggles event booking software, a separate staffing tool, spreadsheets for financials, email threads for client communication, and a shared calendar that nobody fully trusts. None of these talk to each other.
The result is a daily coordination tax: information that should be automatic has to be manually reconciled. A change to an event date means updating five places. A staffing conflict surfaces the morning of a show. A client asks for a budget summary and the answer lives across three spreadsheets and two inboxes.
Enterprise solutions exist, but they are built for arenas and stadium operators with full IT departments and six-figure implementation budgets. Mid-size venues are left choosing between tools too simple to cover their real complexity, or platforms too expensive and bloated to justify.
"Venue OS is a unified operations dashboard designed for the venue ops manager at a mid-size venue, one interface that connects event scheduling, staff management, financials, and client relationships so that running the building does not require running five apps at once."
Before any wireframe was drawn, the research foundation was built. Two personas, a competitive audit of the four most relevant tools in the category, five pain point clusters, ten How Might We statements, and a Jobs To Be Done framework for both primary users.
EventPro. Modular approach sounds flexible. In practice, each module solves its own problem in isolation. The dashboard tells you what is booked, not what is happening. Best for small hospitality venues. The gap it leaves: reduces data entry without reducing cognitive work.
Artifax. Purpose-built for performing arts and cultural venues. Deep scheduling logic, strong financial integration. The sector-specific assumptions baked into the UX do not map cleanly to a mixed-calendar mid-size amphitheater. Users report feeling like they are using about 25% of it. The gap it leaves: power users get a lot out of it. Everyone else is lost.
Momentus Technologies. The category leader. Comprehensive, enterprise-grade, trusted by 700+ venues. It also assumes enterprise resources: custom pricing, implementation measured in months, and a UI carrying 30 years of feature accumulation. The gap it leaves: the right answer for a stadium, the wrong answer for Amy.
Spreadsheets and Google Calendar. The default non-solution. Frictionless to start, infinitely flexible short-term. Most venues have six of them, maintained by different people, none in sync. The cost is invisible on a balance sheet and visible everywhere else. The gap it leaves: everything. This is the gap Venue OS fills.
Six top-level navigation sections, organized by function rather than role or time. This matches how Amy actually thinks under pressure. Dashboard as home base. Events, Staff, Financials, Clients, and Marketing as the six operational domains. Three user flows documented: daily ops check-in, event creation, and staff scheduling.
Five screens wireframed at 1440px desktop. The lo-fi phase was not about visual exploration. It was about locking structure before any design decisions were made. Component placement, column logic, content hierarchy, and data relationships were all resolved here. Nothing moved to hi-fi until the layout under it was settled.
Visual direction: Confident. Dark, structured, high contrast. Built for the professional who does not have time to figure out their software. The design system was completed before a single hi-fi screen was touched. Color tokens named with VOS prefixes and synced to a library. Eight component types with full variant sets. All auto layout.
The wireframes established structure. The design system established language. But the jump from lo-fi to hi-fi is where the real design thinking happens, and this section is an attempt to document that honestly. Not every decision was planned. Some were made in the seat, in the moment, because something was wrong and needed to be fixed. What follows is a screen-by-screen account of what changed and why.
The lo-fi Dashboard was a flat grid with four KPI tiles, an event list, and a chart. Functionally correct but visually inert. The problem was not layout, it was hierarchy. Everything read at the same weight. In a dashboard that someone opens first thing every morning, the most important information needs to announce itself.
In hi-fi, the KPI tiles got an inner stroke treatment with a subtle inset glow that makes them read as data containers rather than just boxes. The stat values are oversized on purpose. If Amy is standing up walking into the room and glances at her screen, she should be able to read the staffing number from across the desk.
The alerts column was the other big shift. In lo-fi it was a list in the right column. In hi-fi it became a persistent sidebar element with severity-coded left borders. Red, amber, and neutral. The decision to make it a persistent drawer rather than a modal came from thinking about how an ops manager actually uses this: she does not stop and open alerts. She glances at them while doing something else. The drawer needed to be scannable at a glance, not a task that requires attention.
The lo-fi Events screen was a standard calendar grid. The hi-fi version looks similar at first but carries a decision that changed the entire screen: event type color coding. Corporate events are one color. Concerts another. Private receptions another. It was not in the lo-fi. It was not in the original component spec. It was made independently during the hi-fi pass because the calendar was visually illegible without it. When you are managing 15 to 25 events a month across multiple event types, a monochrome calendar tells you nothing. Color gives you the composition of the month at a glance before you read a single word.
The inline legend below the month header was added for the same reason. Not as a design flourish. As a functional requirement that the lo-fi had not accounted for.
The event pill component was built as a separate library component with 4 color variants and a hover state. That work happened during the hi-fi pass, not the design system phase, because the need did not become clear until the calendar was populated with real data.
The lo-fi Staff Schedule established the weekly grid structure and the per-person row layout. What it did not account for was visual differentiation between events. In lo-fi, every shift block is identical: a rectangle with an event name and a time. The grid is legible but it communicates nothing about the nature of the work.
The decision that changed the hi-fi most was conflict detection. The lo-fi phase had identified conflict detection as a core product need but the original assumption was to surface conflicts as alerts. During the hi-fi pass that shifted: conflicts should be visible inline on the schedule at the exact point where they exist, not buried in a notification list. If two staff members are double-booked on the same day, the overlap should be visible in the grid before the manager has to go looking for it.
The event type color coding from Events was applied here too, which was not in the lo-fi. Once the calendar had it, the schedule needed it. Cross-screen consistency is not a style choice. It is a usability requirement, the same color meaning the same thing everywhere in the product.
The summary stats row at the bottom (Total Shifts, Open Shifts, Conflicts) was also added during hi-fi. The lo-fi had no equivalent. It exists because the manager's first question is not "who is assigned where" but "am I covered this week." The stats row answers that before she reads a single name.
Event Detail was the screen with the most layout iteration during hi-fi. The original plan had Staff Assignments in the narrow right column and the timeline in the wide left column. That got reversed. Staff Assignments needed the wide column because the data is wider: names, roles, shift times, confirmation status. The timeline reads vertically at any width.
That column swap was made independently, mid-screen, because the layout felt wrong with the data populated. It is the kind of decision that does not make sense on a lo-fi wireframe but becomes obvious the moment you put real content in.
The budget section at the bottom of the screen went through two passes. The first version was a simple breakdown table. The second added a progress bar against budget with a projected vs. actual split. The progress bar was not in the original spec. It came from thinking about what Amy actually needs to know: not the line items, but whether she is on track. The line items are the answer to a deeper question. The progress bar answers the question she actually asks first.
The Financials screen required the most Figma work of any screen in the project. The 6-month revenue trend chart was built manually with a real data curve: a slow climb from December through March, a dip in April, a recovery in May. That was not arbitrary. It reflects what a live event venue's revenue actually looks like through the winter and into spring event season.
Semantic color was applied rigorously here: revenue positive values in green, losses and overages in red, pending items in amber. This was a global design system decision, but Financials was where it got the most work because financial data is where color semantics matter most. A neutral gray on a number that means "this invoice is 30 days past due" is a UX failure.
The sub-navigation within Financials, Overview and Invoices, uses the same glass tab treatment as the rest of the product. That treatment was established in the design system but its application here was deliberate: Financials is where users spend time, and the tab state needed to feel like a place, not just a label.
Eight screens across six operational domains, plus a notification drawer state. All built on the design system, populated with consistent dummy data for Riverside Amphitheater. Click any screen to expand.
Venue OS was designed desktop-first. That was the right call. The product lives on a venue manager's workstation, and the density of information it needs to display, staffing grids, financial charts, multi-column event tables, collapses poorly on a 390px canvas. The desktop is where the serious work happens.
But venue operations do not stop when the manager leaves her desk. On a busy event day, she is walking the floor between the loading dock, the green room, and the main stage. She is not carrying a laptop. The question the mobile screens were built to answer is not "can we fit this on a phone?" It is "what does she actually need to check when she is in the middle of the building during an active show?"
The answer is narrow: today's event status, current staffing coverage, active alerts. The mobile layout strips out everything that requires context-building, the charts, the full tables, the historical data, and surfaces only the information that requires a decision in the next 60 seconds. It is the same data hierarchy as the Desktop Dashboard, built for a completely different use context.
These screens are also a multiplatform proof-of-concept. SOPO and ScreenPark were both mobile-first consumer products. Venue OS is an enterprise B2B tool. Designing both the desktop system and its mobile companion shows that the approach to responsive design scales across product types and user contexts, not just form factors.
The timeline was deliberate. Research before IA. IA before design system. Design system before hi-fi. Every phase builds on the last. No screen was touched before the foundation under it was solid.
Venue OS is the first case study I built with a deliberate intention to wean myself off reliance on AI tools. At my previous company, AI assistance had become a habit I did not fully recognize until I noticed that re-engaging with Figma on my own felt unfamiliar. ScreenPark was a step toward independence. But it was not until Venue OS that I made the explicit commitment to be back in the design seat and use the creative edge that made me fall in love with this work in the first place.
The result was different. I found myself coming up with ideas in the middle of the night. Working late hours and enjoying it. Making design decisions instinctively that I would previously have asked for help with. Swapping the Staff Assignments card to the wide column on Event Detail because it needed the room. Applying event type color coding to the Staff Schedule unprompted because it was the right call. Choosing the glassy inner stroke treatment on stat cards because it felt like the product deserved something that was mine.
This case study is also a deliberate expansion of range. SOPO was a consumer product in the gaming space. ScreenPark was a consumer product in the entertainment space. Venue OS is neither of those things. It is an enterprise B2B SaaS dashboard for a domain I have never shipped in, designed to show that my design thinking does not stop at the edge of what I have built before. The research process, the IA rigor, the systems thinking, the rationale behind every component, all of it was built to prove one thing: I can design for anyone.
Eight days. One product. Research through hi-fi, documented as if I were handing off to a real development team. That is the standard I am holding myself to now.
