POSNext was a from-the-ground-up rethink of a legacy inventory management platform that ticket brokers and operations teams (including the folks at TicketNetwork) lived in all day. The brief was deceptively simple: make managing ticket inventory, watching performance, and pricing at scale feel fast and obvious instead of fiddly and slow.
As Lead Product Designer, I got to define the interface system that pulled it off. We took screens that looked like spreadsheets having a bad day and turned them into a calm, confident, data-driven platform that was actually built to grow.
Ticket brokers wrangle thousands of inventory records across a pile of events, venues, and marketplaces. Here's the kicker: the hardest part of their job, actually deciding what to act on, was slower than it had any right to be. The signal they needed was buried under the very data they were supposed to manage.
Inventory decisions hit revenue directly, so even tiny usability wins added up fast. Speed here wasn't a nice-to-have. It was money.
To get my head around a workflow this dense, I refused to trust any single source and triangulated four. I sat shoulder-to-shoulder with the brokers and ops teams who live in the tool, interviewed the stakeholders who owned the business goals, audited the legacy product screen by painful screen, and dug into the usage and support signals that showed where people actually got stuck. Then I affinity-mapped it all and traced a broker's day from login to pricing call. A messy pile of complaints turned into a tidy set of structural problems.
Mapping the day end to end, the pattern was consistent: the platform was excellent at storing inventory and poor at surfacing what mattered. Brokers opened to no clear picture of performance, then waded through dense tables to reconstruct, by hand, the priorities the system already knew.
Inventory needing attention looked identical to everything else. Identifying what to act on first meant scanning hundreds of rows rather than being shown.
There was no clear way to read pricing competitiveness or inventory health, so revenue opportunities were easy to miss in the density.
Navigating thousands of records across events, venues, and marketplaces was slow, and frequently used actions interrupted the flow rather than supporting it.
Without an at-a-glance performance picture, teams leaned on manual reporting just to understand where things stood before any real work began.
These users live inside the platform for most of their shift, which made efficiency and speed the success metrics that mattered. Each role asks the interface for something slightly different.
Need to quickly evaluate inventory performance and make confident pricing decisions at scale.
Monitor listings across events and marketplaces while keeping inventory levels accurate.
Require visibility into account activity, performance metrics, and system notifications.
Before I touched a single screen, I turned each finding into a job the interface had to do. That mapping became the brief for the redesign, and it gave me the three principles I'd measure every later decision against.
Every decision got held up against the same three principles. When a tradeoff got genuinely thorny (what to show by default, how loud a status should shout, where an action ought to live), these were the tiebreakers that settled it.
Complex inventory data should be easy to understand. If a broker has to interpret the screen, the screen hasn't finished its job.
Power users should accomplish frequent tasks with minimal effort, without their workflow being interrupted.
The interface had to hold its nerve as inventory volume climbed, staying perfectly legible at hundreds or thousands of records.
The beating heart of the redesign was the inventory table, the screen brokers basically live in. I rebuilt it to surface what's actionable and hush what isn't, so reviewing hundreds of listings feels like scanning a well-organized board instead of squinting at a spreadsheet.
The whole workspace in one glance: events on the left, the inventory table dead center, a contextual panel on the right. Flip Pricing Mode on and MSRP, current price, and a suggested price line up side by side. Directional indicators call out where a listing sits above or below the recommendation, so a broker can nudge one row or push every price to suggested in a single click.
Each row leads with what matters and de-emphasizes the rest, so the eye lands on the listing, its status, and its price without competing for attention.
Consistent alignment and rhythm let users move down hundreds of rows quickly, spotting outliers by shape rather than by reading every cell.
Pricing competitiveness is shown, not implied. A number that used to need interpretation becomes a signal you read in a single glance.
The same data reads the same way everywhere, so brokers build one mental model of the table and trust it across every event and marketplace.
The same table language carries across the product. On dense lists like orders, a steady column rhythm, consistent alignment, and inline actions on every row let users move through hundreds of records and spot outliers by shape rather than by reading each cell.
Click a row and the full order opens up in the exact same visual language as the table it came from. Order details, customer info, and the ticket group sit up top, and a clean pricing breakdown runs straight through to the payout, so the number that matters gets read, not recalculated. A running activity log keeps the order's whole history in one place.
Completing a sale follows the same logic: a guided two-step form on the left, with a live order summary that keeps quantities, pricing, fees, and the running total visible as the broker works.
The purchase flow has one job above all else: keep brokers from making costly, unrecoverable mistakes. Each row's quantity is locked to the legal combinations a ticket group actually allows, and locking a row freezes its quantity and price so the order can be committed safely. Since locking can't be undone, it sits behind a deliberate confirmation rather than a twitchy single click.
Step through it: set a quantity within the allowed combinations, hit Lock, and the confirmation makes the consequence explicit before you proceed. Once locked, the row's quantity and price freeze, the order total resolves from “TBD,” and Confirm Purchase becomes available.
A central challenge was communicating inventory health and pricing competitiveness through color-coded status. I explored two systems and let the realities of daily use decide between them.
Bold red / amber / green status
Instant recognition with bold, attention-grabbing signals. Perfect for urgent, time-sensitive inventory review when every second counts.
Softer, calibrated palette
Same signal hierarchy, dialed down for the long haul. All the meaning, none of the glare, for sustained operational use.
To kill off manual reporting for good, I designed a dashboard that hands users a clear read on the business before they so much as touch a listing. It surfaces the trends and insights up front, instead of making people stitch them together themselves.
Headline metrics and trend visualizations show how the business is moving without a single export.
A roll-up of inventory health turns thousands of records into a picture you can read in seconds.
Time-sensitive issues are pushed to the surface so they're handled, not discovered later.
Account activity stays visible, giving operations teams the situational awareness their role depends on.
Reporting reframed as a starting point: a row of date and attribute filters sits above headline metrics and aggregate totals, so teams read the state of the business at a glance instead of assembling it by hand.
Big datasets demand powerful, predictable tools, full stop. So I built reusable filtering components that let users carve down huge inventories in seconds and behave identically everywhere they show up. That speeds discovery, slashes search time, and keeps every table experience scalable. The same systems thinking spilled into the supporting interface too: a cleaner account menu that keeps frequent actions within easy reach, clearer notifications for system and operational updates, and a set of shared components that locked in consistency across the whole application.
Bulk actions and errors are exactly where trust gets won or lost. So I built a consistent system of modals that makes these moments behave the same way every single time. Users always know what's happening and what to do next. The clearest example is bulk CSV upload, where I designed the full flow end to end: confirm, process, validate, and resolve.
Click through the real flow: confirm the import, watch it upload and validate, then resolve the outcome. Flip Simulate result to follow either path. The error path serves up specific, row-level problems that tell the user exactly what to fix, and the success path drops them straight into freshly created inventory.
Every modal and message above is assembled from this little kit of shared components. The payoff: a brand-new dialog inherits consistent behavior and styling for free, instead of getting designed from scratch every time.
POSNext took a notoriously dense inventory experience and turned it into a modern, data-driven platform with a pulse. Because the interface finally surfaces what matters, brokers spend way less time reconstructing the state of the business and a whole lot more time acting on it.
Filtering turned into a consistent, documented pattern any large table in the product could pick up. Data discovery got faster everywhere, not just on one lucky screen.
A growing library of shared components brought consistency across the application and reduced the cost of designing and shipping new surfaces.
The work pushed the design system forward, giving the team a more mature foundation for visual and interaction consistency at scale.
The redesign left behind a scalable base the product can keep building on, ready for more inventory, more workflows, and more users without starting over.