Group Pass Management
Designing for confidence when group owners are responsible for their members
Group Pass Management is the flow group owners use at RainFocus to manage passes for a small, high-touch group. Think a team of ten heading to a conference together, with one or two people on the hook for getting everyone registered, booked, and ready.
It's the project I'm proudest of from my time there, and it launched before I left. Before I get into it, I want to share how I work. It explains almost every decision in this case study.
Start below the waterline
Screens are what people see. They're the tip of the iceberg. What actually shapes them sits underneath. The problem we're really solving, the people we're solving it for and with, and the principles we hold when tradeoffs show up.
Product is a team sport. My best work has come from getting product, engineering, and the people closest to customers aligned on what's under the surface before anyone opens Figma.
Clear thinking is what creates beautiful product experiences.
The risk that's always been there
Keeping with the nautical theme, the biggest risk for any product team is drift. Building something nobody uses. It rarely happens all at once. You set out for what customers need, you end up a few degrees off, and by the time it ships you've built something else.
That isn't new. But it's more tempting than it has ever been. A team can now go from idea to a polished, working product in days. That speed is a gift. It also means you can drift faster, and the result looks so finished that nobody stops to ask if it was the right thing to build.
Polish used to be a sign that someone had done the thinking. It isn't anymore.
What keeps us on course
I use three questions to keep teams pointed at the right thing. I call them the 3 C's, and I write about them in my newsletter, Philosophy & Design.
Clarity asks what the real problem is. Character asks how it should feel, and what wins when two good things conflict. Craft is finding the pattern that solves the root problem, making it beautiful, and getting it in front of real people early and often.
That all sounds nice in theory. Here's what it looked like on a real project.
The case study
Group Pass Management launched at RainFocus before I left. To show the thinking without any client data, I rebuilt the group-owner flow as an iOS prototype, set at Lumen Summit, a fictional tech conference.
The screens below come from that prototype. I'll walk through it the same way we worked. Clarity, then Character, then Craft.
Clarity
On the surface, the request we kept hearing was "make co-registration easier to use." And every client had a version of it. A sales-incentive trip needed a rep to manage her own registration and her guest's from one portal. A family-friendly event needed parents to manage schedules for kids with no inbox of their own. A professional association wanted to bulk import members without anyone filling out forms. Several others wanted a wallet of passes bought centrally, then assigned out.
Built one at a time, those become bespoke flows that don't share a model. So we sat with group owners in interviews and watched them work. The problem underneath was different from the request. They weren't just filling out forms for other people. They were accountable stewards, on the hook for whether everyone in their group was registered, booked, and ready. Easier wasn't really the goal. Confidence was.
Once we saw owners that way, three things followed. Action is delegated. Owners act on behalf of their members, and doing that well means the member is never in the dark about what was done for them.
Stewardship is shared. A group can have several owners who share responsibility, whether they attend or not. And every member is different. Some people should get an invite and register themselves. Others, like minors or dependents without an inbox they check, need an owner to register them. The design had to support both.
Character
Our team had one tenet we came back to over and over. Confidence over speed. They aren't opposites. But when they conflict, confidence wins.
Underneath it, we named the specific tradeoffs ahead of time. Each one names the good thing we were willing to give up.
Visibility over simplicity meant giving up a calm, minimal dashboard. Owner control over automation meant giving up smart defaults that assign passes and book rooms on their own.
Accuracy over encouragement meant giving up upbeat progress framing that keeps owners motivated. And we held one hard constraint. No completion state can hide an incomplete obligation, even when hiding it would simplify the interface.
This is the part I don't think AI can do for you. A model can generate ten dashboards in an afternoon. It can't decide which good thing your team is willing to give up.
Craft
Not everything landed the first time. Our first version was a table of passes. The problem was that everyone read each row as a person, so unassigned rows looked broken. And someone holding more than one pass had to be assigned over and over. Marcus, three separate times.
So we split it. Passes on top, read as inventory. People below, read as people, with each person's passes in one place. That's the structure on the home screen of the prototype, and it landed with the team and with customers.
The tenets show up all over the product. Every pass is accounted for, open items included. On a member's screen, the owner sees what's done, who did it, and when. In the prototype, Priya registered Elena and booked her hotel, but nobody has picked her sessions yet. So that shows up as an open item instead of hiding behind a checkmark.
That's the hard constraint at work. A banner also makes it clear you're acting on Elena's behalf and that she'll be notified.
Stewardship is shared, so a group can have several owners, attending or not. Chris handles billing and isn't going, and every change shows who made it. And when you add someone, you choose. Send an invite so they register themselves, or register them yourself. The sheet tells you exactly what happens next.
Demo
Did it feel the way we intended?
We designed for confidence, so sentiment is how I measure it. Did it make people feel the way we intended?
"Our clients are going to love this." Customer Success Manager
The clearest early signal came from inside the company. Customer Success heard this problem from clients all the time, and they recognized it as solved. Then product marketing demoed it at the internal launch on my behalf. People don't evangelize what they aren't confident in.
If I were still there, I'd keep watching client sentiment, support tickets about group changes, and how often owners needed help from Customer Success to manage their group.
What's worth building
That's the question I want to keep working on. If it's one you're asking too, I'd love to talk.
Comments