Gather, an AI-assisted UX workflow for personal events, gifting and memories Mobile App
Overview
Gather is a mobile app that puts a personal celebration in one place: the invitation, the guest list, the gifts and the memories afterwards. I designed it end to end as a product designer, using Claude, Notion MCP and Figma as collaborators while I made every product decision.
Role | Product designer: research framing, product thinking, UX, UI, prototype |
Product | Gather, a mobile app for personal events, gifting and memories |
Tools | Notion MCP (requirements), Claude (analysis, iteration, build), Figma (design file) |
The problem
A birthday or anniversary is planned across four or five tools that do not talk to each other. Invitations go out in a messaging app, RSVPs are chased by hand, gifts are coordinated in a group chat or a spreadsheet, and the photos end up scattered across phones and social media.
The cost shows up on both sides of the event:
Hosts lose track of who has replied, answer the same questions repeatedly, and cannot see the whole event in one view.
Guests lose event details in busy chats, cannot tell whether someone has already bought a gift, find group contributions awkward, and forget to share photos and wishes afterwards.
Design question: can one connected space make a celebration easier to organise and more meaningful to remember, without asking every guest to install an app or reveal what they gave?
My AI workflow
This project was also an experiment: can Claude help move from a loosely defined problem to structured requirements and usable mobile designs while I keep control of the product thinking? I wrote the PRD myself in Notion and treated Claude as a fast, tireless collaborator that I directed, challenged and corrected.
Tool | What it did | Who decided |
Notion MCP | Held the PRD as the single source of truth and let Claude read it directly, so requirements were never retyped | Me: every requirement, non-goal and open question |
Claude | Analysed the PRD, flagged gaps, proposed flows, drafted screens, restyled them, audited spacing and built the clickable prototype | Me: I accepted, rejected or redirected each output |
Figma | The design file for refining screens, components and handoff | Me: final visual and interaction quality |
What stayed with me, not the AI
The problem framing, audience and the decision to leave weddings, ticketing and a full marketplace out of the MVP.
Privacy rules, such as what a guest can see about a reserved gift or a contribution.
The visual direction. Claude's first pass looked generic until I supplied a reference with a soft pastel, glass and light-type look, and I steered every restyle from there.
Judging whether each screen was clear, accessible and true to the PRD.
Process: seven rounds, step by step
I did not jump straight into screens. Each round had a clear input from me, an output from Claude, and a decision from me.
Write the source of truth. I wrote the PRD in Notion: problem, two audiences, goals, non-goals, MVP features, 12 functional requirements, 7 UX requirements, 12 edge cases and 10 open questions.
Read and challenge. Claude read the PRD through Notion MCP and summarised it back. I used this to check whether the requirements were clear, and to spot where it had to guess, such as who can see a reserved gift.
Turn requirements into flows. From the 11-step host journey (create, invite, respond, gift, celebrate, remember) we mapped the screens each step needs. I trimmed anything that served a non-goal.
Draft the 12 screens. Claude produced a first pass of every screen listed in the PRD, including the empty, loading, error and success states. I reviewed each against the UX requirements.
Restyle from a reference. The first look was functional but generic. I supplied a reference image with a soft pastel gradient, glass surfaces and light type, and Claude restyled all 12 screens to that language: Hanken Grotesk, one gutter of 20px, black pill actions.
Audit spacing and padding. Claude rendered every screen and measured it. This found real defects that I then approved fixes for: a wish card overlapping the navigation on the memories screen, uneven row wrapping on notifications, headings misaligned with the page gutter, and empty gaps on the create-event and invitation screens.
Make it clickable. Claude built a working prototype with shared state, so a contribution on the group gift screen updates the funded percentage on the home, details and gifts screens. I added a guided tour so reviewers can follow the host's journey without guessing what to tap.
Design decisions
The PRD left several product questions open on purpose. These are the answers I designed in, and the reasoning behind each.
Question | Decision in the design | Why |
Does a guest need the app to respond? | The invitation is a shareable link with a guest preview and one-tap Going, Maybe and Can't go | Guests should reach an answer in under 30 seconds (UX-03) |
What happens when a link is forwarded? | The new person triggers a join request that the host approves or declines, and the host can turn this off | Protects the guest list without blocking the host (edge case 11) |
Who sees a reserved gift? | Other guests see "Reserved" without a name, the person who reserved sees "Reserved by you", and the screen says this up front | Prevents duplicate gifts while staying transparent (FR-06, UX-04) |
Can I contribute privately? | Guests see the total and number of contributors, amounts stay private, and a contributor can hide their name from other guests | Group gifting without social pressure (edge case 12) |
What if the target is not reached? | A clear note explains what happens to the funds before the guest pays | No surprises with money |
What if a gift link breaks? | The item is flagged "Link unavailable" instead of showing stale availability | Never imply certainty the app cannot verify (Feature 4) |
Who sees memories? | A private space for guests of that event only. The host can feature items, and guests can remove their own | Privacy by default (UX-05) |
What if a guest declines photo access? | Photos and written wishes are separate, so a wish can still be sent | Respect the permission choice (edge case 10) |
Two accessibility rules ran through every screen: touch targets of at least 40 to 44px, and status shown with text and colour together, never colour alone.
The 12 MVP modules
The visual language is calm and light: a pastel gradient ground, frosted glass cards, light-weight headlines and black pill buttons as the single strong action on each screen.
# | Module | What it solves |
1 | Onboarding | Gets the host started with a single clear action |
2 | Home | Upcoming and past events, plus what needs attention: unanswered invitations and join requests |
3 | Create event | Essentials first: type, name, date and place. Optional details later |
4 | Event details | One page for guests, gift progress and memories |
5 | Guests and RSVPs | Live status counts, filters, nudges and join-request approval |
6 | Invitation and sharing | Guest preview, copy link, share options and the forwarded-link setting |
7 | Gifts | A wishlist with reserved, available and unavailable states, plus gift ideas |
8 | Group gift | Funding progress, contribution amounts and name privacy |
9 | Memory gallery | Photos, wishes and highlights in a private space |
10 | Photo and message upload | Add or remove photos and write a wish, with clear visibility |
11 | Notifications | RSVP changes, requests, schedule changes and gift progress |
12 | Empty, loading, error and success | The in-between states that keep trust when things go wrong |
Interactive prototype and guided tour
A static screen cannot show how gifting, privacy and RSVPs change as people act, so I built a clickable prototype in which one action updates every screen it affects. It opens with a guided tour of 12 steps that follows the host's journey and says what to tap on each screen.
What you can try:
Create an event and see its name carry into the invitation.
Respond to the invitation as a guest, then check the guest counts.
Approve a forwarded-link join request and watch the totals change.
Reserve and undo a gift, or add a gift idea.
Contribute to the group gift with your name hidden and see the funded percentage rise everywhere.
Add photos and a wish to the memory gallery.
Step through empty, loading, error and success states.
How I will validate it
These are proposed targets for usability testing. I have not run the tests yet, so they are goals, not results.
Area | Proposed target |
Event creation | 80% of participants complete it without help |
Invitation response | A guest finds and completes the RSVP within 30 seconds |
Gift coordination | 80% understand how to reserve a gift or contribute |
Memory sharing | 80% can upload or share a memory unaided |
Satisfaction | At least 4 out of 5 average |
After launch I would also watch events created per organiser, the share of invited guests who respond, gift reservation conflicts, group gift participation and memories added per event.
Reflections
What worked
A written PRD in Notion made Claude far more useful. Because the requirements, non-goals and open questions were explicit, its output could be checked against them instead of against my taste.
Rendering and measuring screens caught spacing defects that I would have missed by eye, and it made the review a conversation about specific problems.
Building the prototype with shared state exposed interaction questions, such as where a contribution total should appear, that static frames hid.
What did not, and what I did about it
Claude's first visual pass was competent but generic. Direction had to come from a reference I chose.
Claude cannot judge whether a flow feels right to a first-time guest. That needs real people, which is why the next step is testing.
The screens currently use illustrated placeholders. Real event photography is the next visual upgrade.
