Bridagency
A bilingual (DE/EN) wedding-vendor platform for couples who don't want to compare dozens of portfolios cold. A 23-step planning wizard turns their style, guest count, timeline and budget into matched service recommendations — the budget splits proportionally across whatever they choose, and stays adjustable afterward.
My scope: UX research (thinking-aloud testing, a written survey), the planning wizard's interaction design, and the full-stack build — Astro, Solid, and the Node backend.
30-SECOND PROJECT READ
The project at a glance.
- Challenge
- Help couples compare wedding services and plan a budget without opening dozens of supplier pages.
- My role
- UX research, interaction design and full-stack implementation of the bilingual planning experience.
- Team
- Independent product work, tested with prospective users.
- Timeline
- Product platform · 2026
- What shipped
- A bilingual vendor platform and adjustable 23-step planning wizard with proportional budget allocation.
- Outcome
- 24 thinking-aloud sessions and 15 written replies shaped the flow; browser smoke tests caught state-management and mobile layout bugs before launch.
Design system
Selection controls, provider cards and budget displays recur throughout planning, so couples do not have to learn new controls at every step. German and English use the same patterns.
Working with stakeholders
A private investor commissioned the project. Prospective users tried the flow in think-aloud sessions and provided written feedback. Their responses showed where the planning process remained unclear.
Endless portfolios, no clearer
Couples need to compare vendors against their date, budget and preferences. The homepage introduces a planning flow that collects those requirements before suggesting services.
“If you do not want to keep comparing dozens of portfolios only to feel even less sure, this is a better place to start.”
Bridagency homepage copyWhat 24 sessions and 15 written replies actually said
Thinking-aloud sessions covered the planning wizard and service guide pages. A written survey added feedback on the offer.
Sessions run
Across the planning wizard and the service guide pages.
Named visuals as the main decision factor
Of the 15 written replies — the strongest single signal in the data.
Wanted more explanation before choosing
Not more options — more context for the options already there.
Uncertainty became an entry point, not a dead end
The wizard splits into two entry modes: a full planning walkthrough, or a direct jump to one service, because couples arrive with wildly different amounts of certainty. Change the overall budget and each service's share adjusts to it, keeping the relative weight you'd already set rather than resetting to even splits.
“Uncertainty turned out to be valid input, not a problem to eliminate.”
Design note, Bridagency planning wizardThe interface, wired straight to its code
Screens from the application are paired with the code that controls the interactions.
Real bugs, found before launch
Playwright smoke tests exercise the planning flows in the browser.
Duplicate images in the intro collage
The same photo could appear twice in the opening collage — caught by a visual smoke test, not someone scrolling past it.
Stale draft leaking into quick-start
See the annotated screen above — a real state-management bug between the two entry modes.
Mobile horizontal overflow
The wizard could scroll sideways on small screens — a layout bug no desktop-only QA pass would have surfaced.
The released application
Astro 6 for the static/editorial pages (service guides, gallery, legal), with a single Solid island carrying all the stateful planning logic. Astro i18n routes German and English as separate trees. Contact and planning submissions go through Astro Actions to a Node server, emailed via Resend. Deployed on Coolify.
Findings from the small study
15 written replies and 24 thinking-aloud sessions — a small, real sample, not a statistically representative one. Treated as directional, not proof: the reason the guide pages got more explanatory copy and the service pages got more imagery, not a claim about all couples using the site.
What I would do differently
Test the quick-start path as hard as the full one
Most of the early testing focused on the full 23-step flow — the stale-draft bug only surfaced once quick-start got equal attention.
Ship the guide pages before the wizard, not after
Couples read the service guides to decide whether to trust the wizard at all — sequencing them second undersold that.
The written survey is 15 replies — real, but small. The 86% / 67% figures describe this sample, not a claim about all couples using the site.
More thinking-aloud rounds specifically on the quick-start path — it got the least attention early on, and the one bug that shipped anyway (the stale-draft leak) came from that gap.
