Designing the operating system for culture’s most exclusive events

The principle: design each surface for its moment

Every screen served a different kind of moment, so I stopped treating them as one interface.

• Curating: a moment of judgment. Show what informs the decision, in the row.

• Negotiating and confirming: a moment of commitment. Make the current state and next step unmistakable.

• At the door: a moment of speed. Remove everything that is not the next action.

• Operating: a moment of oversight. Favor density and hierarchy over exploration.

Decision 1: One lifecycle for every guest, on every surface

A guest on Rumor is not a name on a list. They are invited, request access, negotiate terms, confirm, and sometimes decline or get flagged as spam. Without a shared model, each screen would invent its own labels and a host could never tell at a glance where someone stood.

I used a single status vocabulary everywhere: as tabs on the host's event page (Invited, Requests, Negotiating, Confirmed, Declined), as a status menu in the Manage Guest modal (adding Draft and Spam), and as the filters in the guest's own mobile experience (Confirmed, Invited, Applied). The same words mean the same thing for hosts, ops and guests.

I also designed Manage Guest to adapt to what the platform knows. For members it shows rank, total reach, compensation and deliverables. For non-members it collapses to a reduced form, so the modal stays useful when there is no profile data. Designing for missing data from the start meant the flow did not break the first time a host added someone Rumor had never seen.

What I chose not to do: give each surface its own terminology, or hide the negotiation stage. Negotiating is a real state in this product, and pretending otherwise would have pushed it into side channels.

Decision 2: Put the curation signals in the row

Choosing guests means trading off reach, fit and budget. In the Invite Member flow, I built a sortable table that shows per-platform following, total reach, rank, category and favorites directly in each row. Filters cover platform plus follower range, category, location and saved lists. A host can bulk-select and send invites, or invite one person in a single tap, and the button changes to Invite sent so there is no doubt about what already happened.

The reasoning was simple: if a host has to open a profile to compare two people, curation becomes a slow, memory-heavy task. Surfacing the comparison data in the list turns it into scanning. The member profile then carries the deeper layer (audience age, gender and location, past and upcoming events, notes, favorites and custom lists) for the decisions that deserve a closer look.

What I chose not to do: make the host open each profile to compare candidates, or bury filters in a settings panel.

Decision 3: Designing the door for speed and for exceptions

Check-in was designed from scratch, with no existing flow to build on and no chance to observe one. So I worked from the constraints of the situation and treated them as assumptions to verify: someone at the door, on a phone, often standing, with a guest waiting.

• The main screen is a large, high-contrast attendee list with search and sort, and a one-tap check-in control on every row. The primary action is the biggest thing on the screen.

• Walk-ups are treated as normal, not as errors. Add Guest offers two explicit paths, Add and Check In and Add Only, so the person at the door can resolve an unexpected arrival in one step instead of leaving the flow.

• Everything that was not needed at the door (analytics, editing, negotiation detail) stays out of this view.

What I chose not to do: reuse the dense desktop table, or force a guest onto the list before they could be admitted.

Supporting decisions

• Dashboard for oversight. The host dashboard leads with four headline numbers, an upcoming-events table with attendance progress against capacity, and a top-attendees view with social reach. I iterated on it across three versions. In the later versions the headline metrics separate pending attendees from total confirmed, so a host can see how much of the room is still open.

• A blocked state that explains itself. Before an event is approved, the invite actions are disabled and a tooltip says why and how to reach support. The user is never left guessing why a button does nothing.

• Event creation as a configurable RSVP. Hosts choose which guest fields are required, add custom questions, allow plus-ones, and decide whether the full address is shared only after RSVP, which matters at invite-only events. A Preview step comes before Publish.
  
  

  Result

  I would rather be precise than impressive here. I did not have access to usage data, and there was no formal testing, so I will not claim metrics.

  What the work produced:

  • A complete set of connected flows across the host product and internal dashboard: event creation, discovery and invitation, guest management and negotiation, check-in and walk-ups, and an oversight dashboard.

  • A shared status model that gave hosts, ops and guests the same language for where a guest stands.

  • A clear separation of interface density by moment: dense for oversight and curation, minimal for the door.

  • Design decisions recorded with their assumptions, so they can be checked against real events rather than defended on taste.

  How I would measure it:

  • Time to check in a guest, and how often a walk-up needs more than one step.

  • Time for a host to go from opening the directory to sending a set of invites.

  • How often hosts or ops need support to find a guest's status.

  • Whether the dashboard's confirmed versus pending split changes how early hosts follow up.
    
    

  What I would do differently

  I would build a lightweight feedback loop into the first live events: a short debrief with the people at the door and the ops team, and a few timed check-ins. The decisions here are assumption-driven by necessity. Real events would have turned the strongest assumptions into evidence and exposed the weakest ones quickly.
  
  

  Reflection

  The thing I would carry into a founding role is the habit of asking what moment a screen is for before deciding how it looks. Rumor was one product with several different jobs, and most of the design work was refusing to flatten them into one interface.