Inventory visibility, at a glance
Time digging through dense tables
Reliance on manual reporting
0
Core user roles designed for
01 · Overview

Complex inventory shouldn't
require a spreadsheet mindset

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.

02 · Discovery

A volume problem on the surface,
a decision problem underneath

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.

How I approached discovery

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.

4
Research inputs triangulated
3
Power-user roles studied
1
Legacy platform audited end to end
1000s
Inventory records each broker juggles
Discovery approach: Four inputs, triangulated into a brief
Discovery approach: four research inputs synthesized into outputs INPUTS SYNTHESIS OUTPUTS Stakeholder interviews Broker shadowing & interviews Legacy product audit Usage & support signals Affinity mapping Journey & workflow mapping Problem themes User roles Design requirements
Workflow audit: A broker's day, before the redesign
POSNext broker workflow, before the redesign Flow showing where the legacy platform slows a broker down from opening the app through making a pricing decision. Open platform Find priorities Read the data Price & act Log in No at-a-glance view Manual reporting Dense table 1000s of records Pricing call Slow, low confidence Day starts blind Scan fatigue Revenue at stake Brokers spent the day managing data instead of acting on it The signal that should drive a pricing decision was buried in the noise of the inventory itself Friction / effort Revenue-critical moment Broker entry point

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.

Observed pattern: Where a broker's attention went
Where a broker's attention went before the redesign: most on discovery, little on the decision A day spent managing data, not acting on it Finding & reconstructing what to act on Deciding MOST OF THE DAY A SLIVER The signal that should have driven the pricing call was buried in the work of finding it.
🔍 Key insight: the data wasn't missing. It was undifferentiated. The opening was obvious once I saw it: let the interface do the triage, and brokers get to spend their attention on decisions instead of discovery.
🧭

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.

Three kinds of power user, all day, every day

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.

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 a brief

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.

Synthesis: What discovery surfaced → what the design had to do
Each discovery finding mapped to a design requirement WHAT DISCOVERY SURFACED WHAT THE DESIGN HAD TO DO Priorities were buried Pricing health was unreadable Frequent actions broke the flow No at-a-glance view of the business Surface what needs attention Make pricing legible at a glance Keep actions inside the workflow Replace reporting with a live overview
03 · Process

Three principles to keep
complexity from winning

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.

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.

1
Step 01
Understand the high-volume workflow
I went straight for the most important and most painful workflow first: reviewing and pricing inventory at scale. Then I rebuilt the information architecture around the decisions brokers actually make, not around the way records happened to be stored.
UX strategy Information architecture User flows
2
Step 02
Restructure the inventory table
I rebuilt the core table to put actionable information front and center and take the mental load out of reviewing hundreds of listings. That meant simplifying the row, sharpening the pricing indicators, and turning the dataset into something you scan, not something you decode.
Interaction design Data presentation
3
Step 03
Explore how status should look
Pricing health needed to be legible instantly without becoming exhausting. I prototyped competing status systems and weighed immediate recognition against the reality of all-day use before committing to a direction.
Data visualization Iteration
4
Step 04
Extend patterns across the platform
With the core workflow solid, I pushed the same language and components outward to the dashboard, filtering, navigation, and notifications. The design system grew right alongside, so consistency scaled with the product instead of fighting it.
Design systems Shared components Prototyping
04 · Solution

Let the interface do the triage,
so the broker can decide

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.

Final design Inventory & pricing workspace
Redesigned POSNext inventory workspace: an event list on the left, a pricing-enabled inventory table in the center with MSRP, price, and suggested-price columns, and a contextual panel on the right with a seat map and net-income chart

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.

Final design Orders & data tables
Redesigned POSNext orders table showing hundreds of rows with consistent columns, inline actions, and clear alignment

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.

POSNext single order detail view with order details, customer info, a pricing breakdown ending in payout, and an activity log
Final design Checkout
Redesigned POSNext checkout screen with a two-step purchase form and a live order summary

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.

Guardrails for an irreversible action

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.

Interactive prototype Locking a row: set a legal quantity, then commit it
app.posnext.io / Mercury Checkout · Purchase
Mercury Checkout purchase table — each row's quantity constrained to the legal combinations in the Allowed column, with active Lock buttons Lock Tickets confirmation modal warning that quantity and sale price cannot be modified once locked Mercury Checkout with a row locked, the order total now calculated, and Confirm Purchase enabled
1 Set quantity
2 Confirm
3 Locked

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.

Making pricing health legible at a glance

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.

Explored · Traffic-light model

Bold red / amber / green status

Instant recognition with bold, attention-grabbing signals. Perfect for urgent, time-sensitive inventory review when every second counts.

At full saturation, hours of continuous use became visually fatiguing.
Adopted · Refined status model

Softer, calibrated palette

Same signal hierarchy, dialed down for the long haul. All the meaning, none of the glare, for sustained operational use.

Reads instantly and stays comfortable across a full shift.

A dashboard to start the day with

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.

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.

Final design Reporting dashboard
POSNext reporting dashboard with date and attribute filters across the top and headline inventory metrics and aggregate totals below

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.

Modals & messaging for the platform's biggest moments

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.

Interactive prototype CSV upload: a guided, multi-state flow
app.posnext.io / CSV Upload
CSV upload preview: ticket groups and events plus a preview table of rows to be imported CSV upload — uploading in progress CSV upload — validation in progress CSV upload — validation failed, listing specific row-level problems CSV upload — upload successful, with counts and a link to the new inventory
1 Preview
2 Uploading
3 Validating
4 Result
Simulate result:

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.

Built from shared components
Reusable card component showing job and broker details with a confirm action
Card. One container for jobs, confirmations, and summaries.
Primary button component
Button. A single primary action style, used everywhere.
Standard modal footer with cancel and primary action buttons
Footer. A standard action bar puts cancel and the primary action in the same spot in every dialog.

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.

05 · Results

A complex operation,
made legible

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.

Sharper inventory visibility. What needs attention is shown, not hunted for.
Triage moved from the user to the interface
Faster pricing evaluation, with competitiveness readable at a glance.
Less reliance on manual reporting, thanks to at-a-glance operational visibility.
The day starts informed
📊 This one really drove it home for me: thoughtful UX and information design can untangle genuinely complex business operations while directly powering revenue-critical decisions. Clarity isn't just an aesthetic. It's an operational advantage.

Beyond the redesign

Built

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.

Established

Shared component patterns

A growing library of shared components brought consistency across the application and reduced the cost of designing and shipping new surfaces.

Evolved

The design system

The work pushed the design system forward, giving the team a more mature foundation for visual and interaction consistency at scale.

Enabled

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.

06 · Takeaways

What I'd carry
into every project

Surfacing beats storing
The legacy platform had all the right data. It just never differentiated any of it. The biggest wins didn't come from new information at all. They came from letting the interface decide what deserved the user's attention first.
Match the signal to the duration of use
The traffic-light model aced every quick test and then lost the only one that counted: an eight-hour shift. Lesson learned. Designing for how long people actually stare at a thing matters every bit as much as designing for what they see.
Solve the workflow, then systematize it
Nailing the core inventory workflow first gave me patterns worth reusing. Extending those into shared components and filtering meant the whole platform got more consistent as a byproduct of solving one screen well.