Xpress Leads

The situation

When I joined CDS, the design practice didn't exist.

They had contract designers cycling through, 80+ products and services spread across multiple apps and websites, and no real process holding any of it together. Everything needed modernization. The plan was already in place to stop patching the old products and replace them with new MUI React versions built from the ground up.

Xpress Leads was one of those replacements. It's CDS's lead retrieval app. Exhibitors at conventions use it to scan attendee badges, capture lead information, and manage and export those leads during and after an event. The existing version was close to the end of its life. Not just outdated from a UX standpoint. The app was buggy, the experience was confusing, and it had fallen far enough behind technically that app stores were going to stop allowing it to be downloaded. At live events, the problems were already showing up in real time.

There was no option to iterate on what existed. We were building a replacement.

My role

I was hired as Design Manager with a mandate to build the practice, not just run it.

The first thing I did was hire. I grew the team from one designer to four over the course of my time at CDS. Each of those hires was deliberate, chosen for fit with the team and the work, and set up to grow from day one with a documented career ladder and clear expectations at each level.

The way I structured the team was as important as who I hired. Rather than assigning designers permanently to a single product, I built a quarterly rotation model. Every quarter, designers moved to a new product. The reasons were practical and compounding:

• Designer growth. Working on the same product indefinitely is a ceiling. Rotating across products kept designers learning and challenged.
• Shared product knowledge. Every designer on the team knew every product. If someone was sick, on leave, or moved on, someone else could step in without a crisis.
• Better design critiques. When a designer brought work to a critique, the people in the room had context. Feedback was sharper because everyone had lived with the products.
• Documentation discipline. If you're handing off your product to another designer in 90 days, you keep your files organized. You write things down. The rotation made diligence structural, not aspirational.

The design challenge

Convention floors are not controlled environments.

Every exhibitor is different. Their comfort with technology varies. Their booth setup varies. What they're trying to capture, and why, varies by company and by event. And the attendees on the other side of the badge scan, their level of interest, their engagement, the pace at which they're moving through the floor, change completely from event to event.

You can't lab-test your way out of that variability. No prototype captures the noise, the time pressure, the divided attention of someone running a booth and trying to scan a lead at the same time. The environment itself is the constraint, and it's one you can't fully account for until the app is in someone's hands at a real event.

That meant the design had to do a few things well:

• Reduce cognitive load at every step.Exhibitors using this app are not sitting quietly at a desk. They're mid-conversation, standing up, glancing at a device between interactions. Every screen had to be immediately readable. Every action had to be obvious.
• Handle interruption gracefully. The app gets set down. The screen locks. The user walks away and comes back. Flows that require continuous attention fail in this environment. We designed for drop-in, drop-out use throughout.
• Surface the right information at the right moment.Before an event, exhibitors need setup. During an event, they need capture speed. After an event, they need to export and act on what they collected. Those are three different jobs, and the app needed to serve all three without asking users to figure out which mode they were in.

Process

Before any design work started, I ran structured stakeholder interviews. I wanted to understand the current experience from the people responsible for it, what was working, what was failing, and what success would look like at each stage of the event lifecycle. Those interviews shaped the requirements that design worked from.

From there, we followed the same documentation-first approach I run on every project. Requirements written before design started. No feature moved forward without clarity on what it was supposed to do and why.

The build was staged. We launched a structured beta program across six real conventions in fall 2024, with an onsite feedback protocol at each event. Onsite managers approached exhibitor booths near the end of each event, collected ratings across five dimensions using the app itself, and followed up directly with exhibitors who opted in. Every bug surfaced got a ticket. Every ticket got fixed before the next event.

What was hard

Shipping to live events.

The stakes at a convention are real in a way that's hard to replicate in testing. An exhibitor scans a lead from someone genuinely interested in their product. If the app fails, crashes, loses the note, exits out of rapid scan mode when the screen locks, that lead is gone. There's no undo. The exhibitor moves on, and so does the attendee.

That's what made the beta program both necessary and uncomfortable. We couldn't fully validate the experience until it was in the field. But being in the field meant real consequences for real users when something went wrong.

What happened

Across six beta events in fall 2024, satisfaction climbed from 43% excellent at the first event to 90% excellent at the last. That's not a single before and after number. It's a trend tied to specific fixes at each step.

The lead list and lead action ratings at the final event hit 92.9% and 92.6% excellent respectively. Those are the two screens exhibitors use most during an event.

What I'd do differently

Get into the live event environment earlier in the process.

We did the right things in discovery. Stakeholder interviews, requirements documentation, structured beta planning. But the convention floor has a texture that's hard to anticipate from a distance. Some of the feedback we got at the first event could have been caught earlier if we'd spent more time observing the old app in use at a real convention before we started designing the replacement.

The environment teaches you things no interview can. I'd build that observation phase in from the start next time.