Case study · Web App · UX/UI Design

Amorea

Wedding guest management, without the spreadsheets and group chats.

Role  Solo UX/UI Designer, end to end Platform  Responsive web Scope  Research, product strategy, design system, visual identity, conversational UX

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.

Amorea website homepage

The obvious product was beautiful invitations. The real opportunity was knowing who's coming.

When I started, the obvious product was "make beautiful digital invitations." Research kept pulling me somewhere else.

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. Every couple I looked at was running the same manual reconciliation in their head, over and over, with no way to trust the number they landed on.

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.

The invitation was never the problem. Visibility was.

Research first, then structure, then screens

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.

Maria Garcia persona and journey map
Persona and journey map used to locate the sharpest pain points before any screen design began.
Amorea information architecture
Full site structure, mapped before UI, navigation organized around how couples think, not how the data is stored.

Designing around one question: who's coming?

Amorea desktop and mobile views
Responsive by default, the dashboard holds up identically under wedding week pressure on mobile as it does months out on desktop.

70+ components, zero duplication

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 implementation stays efficient. No duplicated components, no one off screens.

Amorea design system
Component library built before the bulk of screen design, not retrofitted after the fact.

Couples don't want to log in just to ask "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.

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.

Core interaction rules

Action authority matrix

Request typeWhere it resolves
Check RSVP statusComplete in chat
Send a reminderInitiate in chat, finish in app
Edit guest detailsNever executes, always redirects
Discuss venue or budgetOut of scope, acknowledged warmly, redirected
Amorea assistant conversational experience
The assistant's read only model: it informs and summarizes, then hands off anything that changes data.

Designed limits, not just designed features

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.

Amorea assistant voice dos and don'ts
Voice guidelines for the assistant, what it says, what it never says.
Amorea assistant interaction patterns
Interaction patterns 3 and 4: the out of scope repair, and the conversation to UI handoff.
Designing the conversational layer meant thinking like a product owner, not just a screen designer: scope, data permissions, escalation paths, voice, and edge cases.

One place to see the whole guest list clearly

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.

35+
screens designed across the full flow, from invitation through RSVP dashboard
70+
reusable components with zero duplication, cutting future design and build time
4
distinct RSVP states, confirmed, declined, pending, no response, handled in one clear view

Good product design is as much about narrowing focus as adding features

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 balancing usability, emotional context, and technical scalability is what turns a nice idea into something real.

Selected screens