Bridagency

Wedding planning rarely begins with a complete list of suppliers. For Bridagency, we designed and built a planning journey that captures preferences, guest numbers and budget to prepare a relevant selection of services.

Challenge: Turn many individual wedding decisions into an understandable planning journey.
Our contribution: UX research, interaction design, budget logic, and frontend and backend development for the bilingual platform.
Result: A 23-step planner with direct access to individual services and an adjustable budget allocation.

A complete plan or one specific service

Some couples want to plan their wedding from the beginning, while others are already looking for a particular service. Drawing on 24 think-aloud sessions and 15 written responses, we designed two entry points that accommodate these different starting points within the same planning model.

A budget that stays connected to the plan

The planner works through style, date, guest count and selected services, then allocates the budget across them. If a couple changes the total, their chosen proportions are retained so their priorities carry through as planning continues.

Interactive planning within an editorial website

Astro serves the guides and content pages, while Solid manages inputs and calculations in the planner. German and English pages use the same logic through to the enquiry, which is sent via Node and Resend. Playwright checks cover these connected journeys.

Research into interconnected decisions

Guest count, venue, style and budget are closely connected in wedding planning: one decision often changes the options elsewhere. Through 24 think-aloud sessions and 15 written responses, we examined how couples handle these dependencies on the service pages and in the planner, and what information they need to make their choices.

Images and text serve different purposes here. A gallery conveys style and atmosphere, while explanations need to make clear what a service includes. We connected the guides, gallery and planner so couples can explore their ideas and then translate them into a specific selection.

Two starting points, one planning model

The full plan collects information in 23 steps, while people looking for a particular service can begin directly through quick start. Both routes use the same planning model, which needs to respect their different starting points when someone switches between them.

Switching routes must not carry names, guest counts or services from an abandoned full plan into a new individual selection. Our browser test reproduces this case and checks the starting state of the new plan so the displayed selection belongs to the current enquiry.

Priorities retained when the budget changes

When a couple adjusts the total, their existing priorities should carry through. The calculation distributes the new budget according to the current service shares, taking minimums, maximums and the defined increments into account. This avoids restarting the allocation after every budget change.

The selection questions also need to reflect how weddings are planned. Since several formats can be combined, we replaced a single-choice question with multiple selection and carried that change through the data model so saving, resuming and summarising all use the same information.

Content, interaction and enquiries in one application

The technical split follows the platform’s tasks: Astro serves editorial content, while Solid handles inputs and calculations in the browser. German and English routes have their own copy but share product logic, so planning decisions are processed consistently in both languages.

On submission, the selected plan is passed to the Node backend and sent through Resend. Our functional checks include this handover, while visual browser checks cover areas such as small screens and the opening collage. This lets us assess both the interface and the path of the information through to the enquiry.

Inside the project

Bridagency · Product video

Design and technology in context.

Astro, Solid and TypeScript separate editorial pages from interactive planning. Node and Resend handle enquiry delivery, while Playwright checks the main journeys.

Visit website