Other work — Booking.com
Provider portal
The commercial surface for App Store software providers: segment selection, pricing, invoicing, content localised in 45 languages, and analytics.
- Product designer
- Interaction design · Visual design · Experience design · Information architecture · Localisation · Analytics
- Booking.com App Store team, product, engineering and content, with provider-facing account managers.
Impact
- 45languages of listing content, localised in-portal
- 4surfaces unified: commercial, content, billing, integration
- Self-servepricing, segments and webhooks, without an account manager
- Account structure,
- Segment selection,
- Pricing models,
- Localisation (45 languages),
- Analytics,
- Webhooks
A provider's business lived in three places and an email thread
Software providers selling into the Booking.com App Store had no single surface for their business. Commercial setup, listing content and technical configuration lived in different places or in email threads with account managers, so a provider could not see how their listing was performing, what they were charging, which markets they were in, and whether their integration was firing, let alone change any of it themselves.
One surface a provider can run their whole business from
Build one portal where a provider can understand performance, configure the listing, set pricing, manage billing, and integrate — without leaving the surface or asking an account manager.
Structure it around the jobs a provider actually does
I structured the portal around the jobs a provider actually does, then designed each surface so a single person could handle everything from commercial copy to webhook endpoints.
Phase 1 — Information architecture and account structure
Providers needed to move between commercial setup, content, and technical configuration without losing context. A persistent sidebar and tabbed sections replaced scattered tooling, and the dashboard opened on the numbers that matter first: total paying customers, trial customers, cancellations, net revenue, MRR and funnel volume.
Dashboard — the provider's commercial snapshot, from total customers and MRR to funnel volume.
Phase 2 — Commercial configuration
The core commercial decisions were market segments, pricing buckets, and supported property sizes. I designed pricing as an explicit choice between fixed buckets and per-room models with recommended defaults, and segment selection as a country-level list with managed defaults, so a provider always knew what would be applied at checkout and where.
- Pricing models: fixed-price buckets versus per-room pricing, with recommended defaults and inline tax guidance.
- Market-segment selection with country-level defaults and a managed supported-countries path.
- Supported property-size ranges, including the ability to remove a maximum cap when it does not apply.
Pricing — a choice between fixed buckets and per-room models, with recommended defaults and tax guidance.
Phase 3 — Localisation and market reach
Providers sold into 45 languages, so listing content needed a localisation workflow inside the same surface rather than a hand-off. Targeting and translation sat next to each other: pick the markets, then write for them. Two decisions made that workable. Listing artwork had to be text-free, because a screenshot with English chrome baked into the pixels becomes 44 broken listings the moment it ships, and no provider was going to redraw its gallery per locale. And translation ran as a pipeline, not a form: a provider wrote the source locale once, the string set moved into the translation queue, and any locale still awaiting a human pass fell back to the source rather than showing a half-translated page.
- Listing artwork specified text-free, so one gallery serves every locale instead of 45 redraws.
- Source locale written once, then queued for translation, with an explicit fallback while a locale is pending.
- Country-level targeting shown alongside supported property sizes in one view.
Market segments — country-level targeting and property-size ranges in one view.
Phase 4 — Developer tooling
The commercial owner and the technical team share one account, so integration could not be a separate product. I designed a webhooks area where technical teams register, edit and remove endpoints for portal events, invoices, bookings, customers and orders, with a filterable list that stays readable as endpoints accumulate.
Webhooks — event subscription management for providers' technical teams.
Providers run their own commercial presence
- Commercial changes that used to travel through an account manager, pricing, segments, supported property sizes, became same-session edits a provider makes alone.
- A listing reaches 45 language markets from one authored source, without a per-locale artwork or copy hand-off.
- Providers stopped asking how their listing was performing: paying customers, trials, cancellations, net revenue, MRR and trial starts are the first thing the portal shows.
- Integration changes moved off the account-manager queue entirely; technical teams manage their own event subscriptions.
What I'm looking for
Product design, design systems, AI-native product.
- Senior / lead product design, design systems, AI product
- Amsterdam, Netherlands. Available in the EU and remote.
- Open to conversations now