Passport Unlimited

Passport Unlimited is an established savings and discount program connecting members with participating vendors. By the time this project started, the desktop experience had already been modernized. The mobile app was a different story. It was dated and barely used.

That mattered more than it sounds. Mobile was the primary touchpoint for a member out in the world, standing on a street with two hours free and no idea that the restaurant across from them honored their card. The company had the bones of a valuable product. The app just wasn't reflecting that.

The core promise, finding a nearby vendor offer, wasn't being delivered in a way that felt useful or current. Fixing that meant rebuilding the discovery model.

I wasn't hired to design this app. I was Passport's in-house graphic designer, and my job was marketing 800+ merchant accounts to our members.

The mobile and web work went to an outside consulting firm. Their rate was high enough that it shaped the roadmap: development happened in quarterly bursts, sized to whatever budget was left. Product decisions were being made on a billing cycle rather than on what users needed.

I was already doing the visual design. I was confident I could carry the UI and UX as well, and that the same budget could buy considerably more than it was buying. So I made the case to the CTO: let me design it, and let me find a developer at a rate that matches how this company actually operates.

He gave me the shot. I sourced several options and found a solo developer with a track record for efficiency who came in well under what the firms had quoted, enough that development stopped being rationed by quarter.

That's the part of this project I'd point at first, because changing how the work got funded is what made the redesign possible.

Three personas carried the work, and I made them deliberately different.

Thomas is 55, IT support in Kirkland, married, no kids, dines out two to four times a week. Emily is 33, an HR director in Seattle with two young children, telecommuting most days. James is 29, an entrepreneur in Bellevue who is rarely home and travels within the states most weeks and abroad once or twice a month.

None of them is a deal hunter. All three were handed a benefit by an employer and mostly forget they have it. What separates them is when and where they need it to surface: Thomas near home on a weeknight, Emily somewhere that will tolerate a six year old, James in a city he landed in that morning.

The frustrations were the part I kept going back to, because several of them turned up in more than one card. Navigation hidden enough that the app goes unopened. Filters that disappear once applied, so nobody can tell what they have narrowed to. Content that has nothing to do with where you actually are.

And in two of the three, the same sentence: having been turned away at a business that had quietly left the program. That one isn't a layout problem, and it stayed with me, because no interface saves a member who is embarrassed at a till.

Someone hunting a discount will go looking for it. Someone who has forgotten they have a benefit needs the benefit to find them, and that is a different product.

I started by auditing comparable savings and loyalty apps to understand the current bar and where Passport could differentiate. From there I moved to wireframes, focused on proximity-based offer discovery, because that was the app's core value and the thing it was failing to deliver.

The information architecture stayed deliberately flat. Home, all offers, the three verticals, map view, search, change location. Every one of those paths lands on the same vendor detail page, and every vendor detail page carries a route out to the vendor: their website, their social, a phone number. The app's job ends at handing the member off to the business, so every screen was checked against whether it moved somebody toward that.

Location is the one piece of state that runs through all of it. It sits in the header, it is editable from anywhere, and it persists. A member who searches Las Vegas before a trip and lands back in Seattle a week later should not have to think about which city the app believes it is in.

I built prototypes and ran user testing sessions. One piece of feedback surprised me.

I'd designed a central action button into the bottom navigation, a shortcut that opened a radial menu and threw you straight into All Offers, Dine, Shop or Travel. It solves a real problem on paper. The three verticals are the spine of the business, they were buried a level down, and this put them one thumb-reach from anywhere in the app.

I thought it was a smart shortcut. Users disagreed. Most preferred to simply browse naturally, and a few actively disliked the button.

I removed it and let browsing do the work. The clip is the version that did not ship.

Looking back, I had solved an org chart problem instead of a member problem. The three verticals matter enormously inside the company and barely at all to somebody deciding where to eat.

Ownership of the product was split three ways, with no single authority over the roadmap. In practice any design decision could be reopened by anyone, at any point, on any grounds.

Having argued my way into the work, I couldn't afford for calls to come down to whichever preference carried the room that day. So I stopped bringing options and started bringing evidence: what users actually did in testing, what a direction would cost, what it would take to maintain. That gave the group something external to agree or disagree with, which turned out to be the fastest path to a decision.

It's the habit I've kept longest from that job.

The three verticals needed to be legible at a glance, in a list, on a map pin, and on a card in somebody's wallet. So they got colour before they got anything else. Dine red, shop orange, travel blue, each one built on the same circular mark and the same construction grid, so a pin on a map and an icon in a filter row are recognisably the same object at very different sizes.

Everything else is Lato and a five step grey ramp, and that's the entire system. It was meant to be modest. A member is looking at a photograph of food, a distance and an offer, and the interface's job is to stay out of their way.

The redesigned app launched and adoption was meaningfully stronger than the old version.

Home opens on what's near you: quick access to saved, new and hot offers, then featured placements, then the newest dining, shopping and travel offers as you scroll. Search carries recent searches and recent locations, so the two things a returning member most often repeats are both one tap away. Results run as a list or a map from the same filter set, and the filters stay visible as breadcrumbs so nobody loses track of what they've narrowed to. The vendor page leads with the space itself, then the offer, then the ways to act on it.

But the launch also surfaced something design alone couldn't fix: the quality of the offers the sales team was acquiring was a friction point for members.

So I designed a feedback loop into the app, a lightweight way for members to tell the company what they thought of an offer. For the first time the team had quantitative data on member satisfaction they could act on, instead of assumptions.

Developer sourcing saved the company thousands in development fees. After launch I kept iterating the UI on direct member feedback.

The app was one door into the program. The other was the corporate member portal, the web experience a company's employees landed on after HR enrolled them. It had to do the same job as the app on a desktop, for a member who might only visit once a quarter to see what was near the office.

The portal reuses the mobile system rather than restating it. The three category marks and their colours carry over unchanged, the location and filter row does the same work as the app's live filters, and the featured collections down the right are the same paid placements that fund the program.

The emails were the part nobody had designed. Welcome, assign your gifts, and the survey sent when a company let its membership lapse. Each one is a single column with one action, because they were read on a phone in an inbox full of other things.

Split ownership with no single roadmap authority meant every direction could be reopened, and the project absorbed a lot of avoidable back-and-forth as a result.

If I ran this again I'd spend the first week establishing who decides (a single product voice, or failing that a written alignment process) before any design work started. I treated that as someone else's problem to solve. It was mine, and the time lost to it was the biggest drag on the project.

Ratings are from when I left the company in 2020. The app has changed since and no longer reflects my work.