The platform where ticket brokers
run their entire operation
POSNext is a cloud-based inventory and order management platform used by professional ticket brokers to manage inventory, pricing, fulfillment, marketplace distribution, and the day-to-day operations of running a business in the secondary ticketing industry. Brokers and their operations teams live inside it for most of the working day: listing tickets, pricing them against fast-moving marketplaces, and fulfilling orders across multiple sales channels.
The project was a ground-up rethink of a legacy platform that had become a bottleneck for the exact users it was built for. As the lead Product Designer, I drove the initiative end to end: framing the core problem with Product, pressure-testing what was buildable with Engineering, and owning the decisions about what the interface should surface, what it should quiet down, and where every action should live. Because inventory and pricing decisions map straight to revenue, the goal was never just a cleaner screen. It was a platform that helped brokers make faster, more confident calls at scale.
A volume problem on the surface,
a decision problem underneath
A typical broker manages thousands of inventory records across dozens of events, venues, and marketplaces. The hardest part of the job is not entering data, it is deciding what to act on next: which listings are mispriced, which are at risk, which are quietly leaving money on the table. On the legacy platform, that decision was slow because the signal a broker needed was buried under the very data they were there to manage.
Every pricing decision moves revenue, so even small usability wins compounded across thousands of records a day. Speed here was not a nice-to-have. It was money.
Priorities were buried
Inventory needing attention looked identical to everything else. Identifying what to act on first meant scanning hundreds of rows rather than being shown.
Pricing opportunities hidden
There was no clear way to read pricing competitiveness or inventory health, so revenue opportunities were easy to miss in the density.
Datasets that fought the user
Navigating thousands of records across events, venues, and marketplaces was slow, and frequently used actions interrupted the flow rather than supporting it.
No view of the business
Without an at-a-glance performance picture, teams leaned on manual reporting just to understand where things stood before any real work began.
I mapped a broker's entire day,
end to end
Before proposing a single screen, I audited the legacy platform the way a broker actually uses it: opening cold, hunting for priorities, and reconstructing the state of the business by hand. Here is what that audit surfaced, and the brief it produced.
What I needed to understand first
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 reconstructed by hand the priorities the system already had the data to show them. That framing, storing versus surfacing, became the thesis for the entire redesign.
Three power users, each asking the interface for something different
These are power users who live inside the platform for most of a shift, which made efficiency and speed the metrics that mattered most. Each role leans on the same screens for different reasons, so any decision about defaults or density had to hold up for all three at once.
Ticket brokers
Need to quickly evaluate inventory performance and make confident pricing decisions at scale.
Inventory managers
Monitor listings across events and marketplaces while keeping inventory levels accurate.
Operations teams
Require visibility into account activity, performance metrics, and system notifications.
From problems to constraints to a brief
Before touching a single screen, I translated each finding into a job the interface had to do, then framed the constraints we were designing inside. Technically, the redesign had to sit on the existing data model and ship in phases rather than as a single big-bang release. On the business side, it could not disrupt brokers mid-workflow, since any downtime is lost revenue. For users, the bar was high: these are experts who would reject anything that slowed them down. That mapping became the brief, and it gave me the three principles I measured every later decision against.
Three principles to keep
complexity from winning
Every decision got held against the same three principles. When a tradeoff got genuinely thorny, what to show by default, how loud a status should be, where an action ought to live, these were the tiebreakers Product, Engineering, and I used to settle it without relitigating taste every time.
Clarity
Complex inventory data should be easy to understand. If a broker has to interpret the screen, the screen hasn't finished its job.
Efficiency
Power users should accomplish frequent tasks with minimal effort, without their workflow being interrupted.
Scalability
The interface had to hold its nerve as inventory volume climbed, staying perfectly legible at hundreds or thousands of records.
Let the interface do the triage, so the broker can decide
The heart of the redesign was the inventory table, the screen brokers effectively live in. We intentionally prioritized surfacing what is actionable and quieting what is not, so reviewing hundreds of listings feels like scanning a well-organized board instead of decoding a spreadsheet. Every decision below started from a problem, ran into a real constraint, and came down to a tradeoff I made deliberately with Product and Engineering.
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.
Reworking the inventory table
Simplified row hierarchy
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.
Built for visual scanning
Consistent alignment and rhythm let users move down hundreds of rows quickly, spotting outliers by shape rather than by reading every cell.
Clearer pricing indicators
Pricing competitiveness is shown, not implied. A number that used to need interpretation becomes a signal you read in a single glance.
Consistent data presentation
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.
Making pricing health legible at a glance
A central challenge was communicating inventory health and pricing competitiveness through color-coded status. The problem: the status is read thousands of times a day, so it had to register instantly and stay comfortable over a full shift. I explored two systems and let the realities of daily use, not the demo, 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. To balance user needs with business goals, I kept the meaning fully legible and removed the glare, so status supports sustained operational use instead of fighting it.
Then I scaled the pattern
across the platform
Once the core table was solid, I extended the same language outward. Rather than redesign each surface from scratch, I reused the row, alignment, and action patterns across orders, checkout, the dashboard, and filtering, so the product felt like one system instead of a pile of screens.
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.
From the table into a single record
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.
A dashboard to start the day with
Discovery showed teams were exporting data and rebuilding the same reports by hand just to know where things stood. Rather than optimize that export flow, I removed the need for it: a dashboard that hands users a clear read on the business before they touch a single listing. This approach allowed us to replace recurring manual reporting with a live overview that starts the day informed.
Revenue & performance trends
Headline metrics and trend visualizations show how the business is moving without a single export.
Inventory summaries
A roll-up of inventory health turns thousands of records into a picture you can read in seconds.
Operational alerts
Time-sensitive issues are pushed to the surface so they're handled, not discovered later.
Activity monitoring
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.
Filtering & system patterns built to scale
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.
One pattern,
one component library
This was not a visual cleanup. Every pattern I shipped went into a shared component library, so high-stakes moments behave the same way everywhere and each new surface inherits consistent behavior for free.
Modals & messaging for the platform's biggest moments
Bulk actions and errors are exactly where trust is won or lost, especially for power users moving inventory in batches. I built a consistent system of modals so these high-stakes moments behave the same way every time. The clearest example is bulk CSV upload, an edge-case-heavy flow I designed end to end: confirm, process, validate, and resolve. Because a partial import can corrupt live inventory, we intentionally validated every row before anything committed, and designed the error state to tell users exactly which rows to fix rather than failing the whole file silently.
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.
Beyond the redesign
Reusable filtering components
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.
Shared component patterns
A growing library of shared components brought consistency across the application and reduced the cost of designing and shipping new surfaces.
The design system
The work pushed the design system forward, giving the team a more mature foundation for visual and interaction consistency at scale.
A foundation for growth
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.
How I drove it,
end to end
I owned this initiative from problem framing through shipping. Rather than hand off static comps, I framed the problem with Product, prototyped the interactions, and pressure-tested them with Engineering against the real data model, then shipped in phases so brokers were never disrupted mid-workflow.
The sequence mattered as much as the craft. Solving the highest-revenue workflow first gave Product and Engineering a concrete pattern to react to instead of a deck of abstractions, and shipping in phases meant each change could be validated in production before the next one built on it.
With Product
We aligned on which workflow to solve first and what "done" looked like, so scope stayed tied to revenue impact rather than screen count.
With Engineering
I pressure-tested every interaction against the real data model and shipping constraints early, so what I designed was buildable and could roll out safely.
Phased rollout
The core table shipped first and proved the pattern in production. Extending it to other surfaces then became low-risk reuse instead of a rewrite.
A complex operation,
made legible
POSNext turned a notoriously dense inventory experience into a modern, data-driven platform. Because the interface now surfaces what matters, brokers spend far less time reconstructing the state of the business and far more time acting on it. The outcomes below are directional, framed the way the redesign was scoped to move them rather than as headline metrics.
What I'd carry
into every project
Try it: locking a row
is irreversible, by design
The clearest example of a deliberate product decision is also the most interactive. Step through the flow below to feel how the design prevents a costly misclick without slowing brokers down.
Guardrails for an irreversible action
Locking a row commits its quantity and price. Because that action cannot be undone, the design problem was to prevent a costly misclick without slowing down brokers who lock rows all day. Rather than remove the friction entirely or bury the action behind a settings screen, we added a single deliberate confirmation. Working with Engineering, I constrained the quantity field to only the legal combinations, so an invalid lock is impossible before the user ever reaches the confirm step. The tradeoff was one extra click on a frequent action, which we judged worth it against the cost of an accidental commit.
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.