VISUAL · Hero
Animated result card: the price flips from “CA$555” to “CA$555 or 55,500 pts”, then to the discounted “CA$430 · Save $125 with 12,500 pts”. 4–6 s loop.
Keep · Fintech · Web 0→1 · 2025
Turning business card points into flights
Timeline
3 weeks to dev handoff
Launched Sep 2025
Iterated through 2026
Team
1 designer (me)
1 PM
3 engineers
Role
Sole product designer,
end to end
Platform
Web
(desktop + mobile web)
Problem
Keep’s best customers carried a second card, usually Amex, and saved those points for flights. On Keep, points could only become cashback.
What I did
I studied how the best travel sites and the PM’s working prototype handled every step, designed the booking flow end to end in 3 weeks, and kept improving it after launch with an A/B test.
~$1M
CAD booked in the first year
2 → 122
bookings per month, Sep 2025 → Aug 2026
35%
of businesses that booked came back to book again
~75%
of booking value paid with points
Final designs
VISUAL · Final designs carousel
6 desktop screens, auto-advancing, one-word captions: Travel home → Search → Results → Fare options → Checkout → Confirmation. Optional: one 15–20 s recording of the full flow.
Context
Keep was the second card. Amex won on flights.
Founder interviews in early 2025 showed our best customers carried another business card, usually Amex, and saved those points for flights. On Keep, points could only become cashback.
VISUAL · Before
Redeem modal: points could only become cashback or a statement credit.
VISUAL · After
Redeem modal: “Book travel (NEW)” next to cashback.
“Travel is the highest perceived-value redemption… especially compared to cashback or statement credits.”
Keep Travel strategy review, Apr 2025
Hypothesis
If business owners can turn Keep points into flights, a reward they value more than cashback, they’ll put more of their spend on Keep to earn those points.
Approach
Booking is a solved pattern, so I studied it before I drew
Flight booking is one of the most established patterns on the web, and the PM had already built a working prototype.
Instead of polishing it, I reviewed it the same way I reviewed Amex Travel, Google Flights, Expedia, TravelPerk and Ramp: step by step, noting what worked and what didn’t. By the time I opened Figma, the first wireframe had already formed.
VISUAL · Approach collage
Competitor screens with green / yellow sticky notes → the PM’s prototype with my audit notes → the lo-fi flow. Slow pan or scroll-linked.
✅ Adopted
Indented multi-airport cities · child ages · per-person, round-trip price · separate Details and Select · breadcrumb back · two-column checkout
⛔ Blocked by the API
Picking a fare right after each leg · a grid view comparing cabins side by side
💡 Liked, not built
Public search without logging in · defaulting “From” to your location
Design
Key design decisions
Search is intent, so booking goes full screen
Travel has its own place in Keep’s navigation, separate from Rewards, so it’s easy to find and can grow beyond points. The moment you start a search, booking takes over the full screen, with a clear way back to Keep.
VISUAL · Nav → full-screen search (loop, 6–8 s)
Keep sidebar → Travel → Travel home inside Keep → Search → the sidebar slides away and results open full screen with “← Back to Travel”. Optional inset: indented airports (New York → JFK / LGA / EWR) and the child-age picker.
Results built for scanning and choosing
Three details make a long list of flights easy to scan and safe to act on.
Fare selection
Both legs on one page. Fares for each leg sit together, with plain ✓ / ✕ / $ labels for bags, changes and refunds.
A grid view I couldn’t ship. I wanted a grid that compares cabins and fares side by side, but our travel API (Duffel) didn’t support it.
VISUAL · Fare options (static)
Both legs with Ultrabasic / Economy / Econoflex cards. Optional: a small thumbnail of the grid-view exploration tagged “Not supported by the API”.
Checkout borrows from e-commerce
Checkout works like a good online store. Inspired by Square’s checkout, you fill in traveller and payment details on the left, while a trip summary stays on the right as a reference. Three short steps (Passengers → Extras → Payment) keep each screen focused.
VISUAL · Two-column checkout
White form on the left, grey trip summary on the right. Optional loop: stepping Passengers → Extras → Payment while the summary stays fixed and the total updates.
No trip management yet, but you can still see your trip
Managing trips (changes, cancellations) was out of scope for the first release. I still added a simple list of upcoming trips with the confirmation number, so people know their booking went through.
VISUAL · Upcoming trips list (static)
The Travel page cropped to the Upcoming trips list (dates, route, travellers, confirmation #) and the support card.
Details
The moments in between are where trust is won
Booking a flight means waiting on an airline and trusting what you see. These small states make that wait feel calm and honest.
VISUAL · Loop
Loading modal with a Lottie animation while the airline confirms.
“Hang tight. We’re locking in your trip!”
A calm wait while the airline confirms the order, instead of a bare spinner.
VISUAL · Loop
Upcoming trip showing “Pending”, then confirmed.
Pending trip
The trip shows up right away, and is honest that it’s still processing.
VISUAL · Loop
Mixed-cabin flag opening the cabin-by-leg modal.
Mixed cabin ⚠
Added after a customer searched for premium and got an economy leg.
After launch
Card-first payment, then an A/B test that found the leak
Release 2: card first, on purpose
The next release let people pay with their Keep card, or split points and card. I explored three options and chose card first: the card is the default, and points are one toggle away. It supports Keep’s goal of more card spend without making points harder to use.
VISUAL · Option 1
Payment step: three equal choices (card, points, points + card).
Option 1 · Three equal choices
Clear, but nothing steers people toward the card.
VISUAL · Option 2
Payment step: points applied first, card for the rest.
Option 2 · Points first
What many people expect, but it works against card spend.
VISUAL · Option 3 ✅
Payment step: default card + “Redeem Keep points” toggle + breakdown.
Option 3 · Card first ✅
The card is the default; points are one toggle away.
Then data showed where people were dropping off
VISUAL · Funnel chart
Control group funnel: search → choose fare is the biggest drop (−60%).
1 · Insight
6 in 10 businesses that searched never picked a fare. Customers asked: “Can I see how many points I need?”
VISUAL · A/B result card
Price card leading with the points discount; control vs. test.
2 · Test
I designed prices that lead with the points discount. In an A/B test, fare selection rose from 40% to 52%, but bookings stayed flat.
VISUAL · Payment before → after
Before: points toggle off, full price. After: points on by default, “You saved $X”.
3 · Fix
The discount disappeared at payment. So I turned points on by default and kept “You saved $X” visible to the end.
A small, directional test (Mar–Apr 2026).
Impact · Sep 2025 – Aug 2026
A year in: ~$1M booked, mostly with points, and 1 in 3 businesses came back
Monthly bookings grew from 2 in the first month to 122 in August 2026, with about three quarters of the value paid in points: the redemption customers told us they wanted.
336
businesses booked a flight
665
bookings in the first year
17.9M
points redeemed in Aug 2026 alone
VISUAL · Monthly bookings chart
Sep 2025 → Aug 2026 (2 → 122), redrawn in the site’s style, last bar in brand green. Don’t paste the Metabase screenshot.
“I’m going to move all my employees onto Keep, so I earn more points for travel.”
Keep customer, Feb 2026 (paraphrased)
Reflection
What I’d do differently
Carry the anchor price through to payment, from day one
The A/B test found the leak after launch: the discount disappeared at payment. I could have designed for it before.
Ship a new visual style with a rollout plan
Travel was where I first tried tonal layers: white surfaces on a tinted background. It’s still the only part of Keep that looks this way. On Keep Mobile, I went flat instead.
This is the short version.
I’m happy to walk through the full case study: how I reviewed the PM’s prototype, the card-first debate with engineering, and what the A/B test taught us.