Amorea
Amorea is a responsive web app that helps couples manage their wedding guest list and RSVPs without the spreadsheets, group chats, and guesswork. I designed it end to end, from research and product strategy through the design system and visual identity, and I'm currently building the landing page in HTML and CSS.
The decision that defined Amorea
When I started, the obvious product was "make beautiful digital invitations." But research kept surfacing the same frustration: couples weren't stressed about how invitations looked, they were stressed about not knowing who was actually coming. Responses were scattered across texts, calls, and emails, with no single source of truth. So I made a deliberate call: invitation creation would be a feature, but guest management would be the core of the product. Every later decision, the dashboard, real time RSVP states, the information architecture, flowed from that one reframe.
How I got there
I ran user research to understand how couples actually plan, then synthesized it into personas and a journey map to locate the sharpest pain points. Before touching UI, I mapped the full site structure so navigation reflected how couples think about their event, not how the data happens to be organized.
Key decisions
- Guest management as the core, not invitations. Focused the product on the real source of stress.
- A dashboard that answers one question instantly: who's coming? Confirmed, declined, and pending surfaced at a glance.
- Real time RSVP tracking so the picture is always current, with no manual tallying.
- Responsive by default, designed to work as well on a phone the night before the wedding as on a laptop months ahead.
A system built to scale
I built Amorea's design system early, not as cleanup at the end. Components are reusable, responsive, and structured to map cleanly onto React, variants, states, and consistent patterns, so the same building blocks hold up as the product grows and so implementation stays efficient. No duplicated components, no one off screens.
Amorea assistant
Couples don't want to log into a web app every time they wonder "who's still coming?" They want a quick answer on the phone that's already in their hand. So I extended Amorea with a WhatsApp assistant: a read only conversational layer that surfaces RSVP status, pending guests, reminders, and the wedding countdown through chat, then hands off to the dashboard for anything that changes data. This wasn't a bolt on feature. It's a direct extension of Amorea's core insight: the real problem was never the invitation, it was visibility into who's coming. The assistant makes that visibility ambient.
Designing the assistant's behavior, not just its screens
The hardest part of conversational design isn't the UI, it's defining how the assistant thinks. I authored a full system prompt that specifies its identity, scope, tone, data access, and action authority. Some of the decisions I made:
- A strict scope boundary: The assistant helps with guest management and nothing else. It won't discuss venues, vendors, or budgets, and it says so warmly instead of dead ending. Defining what a product refuses to do is as important as what it does.
- A read only model with a clear handoff: The assistant can read and summarize, but every action that changes data (sending a reminder, editing a guest, resending an invitation) routes to the dashboard. I formalized this as an action authority matrix: complete in chat, initiate in chat and finish in app, or never execute and always redirect.
- A defined voice with hard rules: Warm but not a cheerleader, elegant but casual for the channel. Exclamation marks reserved for genuine milestones. No dashes as connectors, because they make a message read as machine generated.
A system built to scale
The assistant is honest about its limits, and the design turns those limits into a feature. When a couple asks for something it can't do in chat, it acknowledges the request, explains what it can do, and offers the relevant dashboard link. The five interaction patterns map this end to end: the happy path that informs and closes, the proactive nudge with conditional reminder logic, the out of scope repair, the conversation to UI bridge where the channel handoff begins, and the connected state with an easy exit.
Designing the conversational layer meant thinking like a product owner, not just a screen designer: scope, data permissions, escalation paths, voice, and edge cases. It's the part of this project I'm proudest of, because it shows design decisions that live in behavior.
The result
Amorea gives couples one place to manage guests, track responses as they come in, and see their attendance picture clearly, replacing scattered messages and mental math with a calm, organized view.
What it delivered
- Designed 35+ screens across the full flow, from invitation through RSVP dashboard.
- Built a reusable system of 70+ components with zero duplication, cutting future design and build time.
- Handled distinct RSVP states (confirmed, declined, pending, no response) in one clear view.
What I took away
The strongest design move on this project wasn't a screen, it was deciding what not to build. Letting research override the obvious "pretty invitations" framing, and committing to guest management as the core, made the whole product clearer. It reminded me that good product design is as much about narrowing focus as adding features, and that balancing usability, emotional context, and technical scalability is what turns a nice idea into something real.
Final Product
