Senior Product Designer
Product strategy, UX, Interaction design, A/B test design, Mobile design
Bridebook was launching wedding websites: one place for couples to share their story, schedule, venue, travel and gift list with guests. Couples wanted a site that felt like their wedding, not a template. I ran user research to understand what they wanted, then designed a tokenised theme system so every style came from the same components, with type, colour and accents swapped through tokens.
I was the product designer on the theme system, from user research through to the final token set and developer handover. [Add the team you worked with, e.g. PM, engineers, other designers]
I owned:
User research into what couples wanted from their wedding website
The theme token structure: type sets, colourways and accents
Font pairings and colourways for each theme family
The wedding website template on desktop and mobile
Handover of the token set to engineering
Why the product needed a system
Every wedding has its own look, and couples expect their website to match their invitations and colour palette. But designing each theme as a one off page would have been slow to build, hard to maintain and impossible to scale as the feature grew. We needed variety for couples and consistency for engineering.
Who the system serves, and what it had to do
Let couples personalise their site without needing design skills
Ship many themes from one template and one set of components
Make adding a new theme cheap: a configuration, not a build
Keep key information readable in every theme
Couples
A site that matches the style of their wedding and feels personal to them.
Guests
Dates, venue, travel and gift details they can find quickly, mostly on mobile.
Engineering
Themes delivered as data, so new styles don’t mean new code.
Structure stays, style changes. Layout and content are shared across every theme. Only tokens change.
Readable first. Date, venue and key details stay clear in every theme.
Accents add personality, not noise. Decoration sits on its own layer, away from the content.
How might we give every couple a wedding website that feels like theirs, without designing and building a new site for every style?
What the audit uncovered
What couples told us
Before designing a single theme, I ran user research to understand what couples wanted their wedding website to do, and what it should say about them. [Add the method, e.g. interviews or a survey, and how many couples took part]
[Finding 1]
[Finding 2]
[Finding 3]
Mapping the styles
I gathered inspiration from wedding stationery and existing website builders, then grouped it into style families: minimalist and timeless, floral and blossom, botanical and green foliage, modern and playful, and destination. Each family became a starting point for a theme.
Tokens, type, colour and spacing
Every theme is built from the same small set of tokens, grouped so they can be mixed and matched.
Type sets
Heading, body and CTA styles, each with a font, size and weight. I tested pairings including Baskerville with Josefin Sans, Dancing Script with Raleway, Playwrite with Montserrat, Della Respira with Lora, Aboreto with Figtree, Figtree with Poppins, and Oswald with Roboto.
Colourways
Background, surface, font colour, CTA colour and accent colour.
Accents
Decorative illustrations such as florals, foliage and bows, sitting on their own layer above the layout.
The components teams build with
One page template, with every section built once on desktop and mobile, then themed through tokens:
Header with the couple’s names, date and venue
Our story
Schedule of events
Venue, with a map
Hotels and travel
Gift list
Photos
FAQs
Because the structure never changes, guests always find information in the same place, whichever theme a couple chooses.
The calls that shaped the system
1. Tokens over templates. Rather than designing each theme as its own page, I designed one template and moved every visual choice into tokens. That turned a new theme into a configuration.
2. Type sets and colourways as separate groups. Splitting typography from colour meant themes could share pairings and palettes, so we could create more variety from fewer decisions.
3. Accents on their own layer. Florals, foliage and bows sit above the layout, so a theme’s personality can change without touching the content or breaking the structure.
4. Lock the structure. Every theme keeps the same section order, so guests never have to relearn the page.
5. Design with realistic content. I used a full sample wedding, with real length copy and photography, to test every theme against the content couples would actually add.
How teams adopted it, and kept it healthy
[How the theme system was handed over to engineering, how many themes launched, and how new themes get added]
[Any results, e.g. wedding websites created, the most popular themes, or feedback from couples]
Looking back
What worked
Separating type, colour and accents made it quick to explore new themes
Designing with realistic content showed which themes held up and which didn’t
[Add a learning from the research or launch]
What I’d do differently
[Add what you would change next time]
Wedding websites needed to feel personal for every couple without becoming a new build every time. A tokenised theme system gave couples real choice and gave engineering one template to maintain.
The lesson I took from it: personalisation scales when you design the system, not the screens.
