Real Wedding Submissions

Editors + competitors

Feedback thread, competitor forms

Redlines

Every ask checked against the build

Journeys

Three submitter paths in FigJam

Lo-fi prototype

Revised flow, prototyped with AI

Design system

Built on the shared components

Full size

Where this starts

Iron Diamond Media publishes seven bridal magazines, and every real wedding they print starts as a submission. Before this, that meant a fillable PDF from SharePoint, emailed to a shared inbox. Staff opened gallery links by hand, wrote back for whatever was missing, and tracked every submission in a color-coded Excel sheet. With a national site launching in early 2027, the number of submissions was about to grow past what that process could handle.

Reading the editors against the build

1. 01
   Galleries.

   Both editors asked for "Dropbox or other photo gallery" links. The validator only accepted dropbox.com, so a Pixieset or Pic-Time gallery failed with "Enter a valid Dropbox link."

2. 02
   Instagram.

   The editors settled on mandatory, with "N/A" as the escape hatch. The handle pattern rejected N/A.

3. 03
   Addresses.

   The editors wanted the submitter's address required and the couple's optional, since they collect it during factcheck. The build had it backwards.

The flow

The publications step was the one I removed. A submission belongs to the publication whose site you started on, so the form reads the brand from the host instead of asking for it.

"The photographer" option became "The vendor". A vendor picks their role inside the same card, because the magazine mails copies to the submitter, the photographer and the couple, and it needs to know which one you are. A photographer gets their own step first. Everyone else gives their details, then names the photographer.

Full size

Vendor credits are sorted by category: venue, planner, photographer, videographer and florist come pre-filled, and each one has its own search. Adding a category opens the picker with focus already in it, and choosing a category opens its search. If nothing is listed under that category, the form goes straight to the fields for entering a vendor by hand.

The review step the shell never had shows each section on its own row with an Edit link, says how many things still need attention, and ends on the consent line editorial required: "I confirm everyone named here has agreed to publication."

Every page

Each step as it shipped, at desktop width with the header and footer in place, in the order a vendor sees them. Open any page to flip through them all.

How it moves

Each step change runs as a React <ViewTransition> with forward and back types. The step that's leaving fades out fast and the next one fades in more slowly, so the old content gets out of the way before the new content arrives.

--motion-exit-duration: 150ms;
--motion-enter-duration: 210ms;
--motion-move-duration: 400ms;
--motion-credit-duration: 480ms;
--motion-credit-ease: cubic-bezier(0.22, 1, 0.36, 1);

Loading states are shaped like the step they stand in for, and the app-wide skeleton changed from a pulse to a sheen. With reduced motion on, every transition runs at zero duration, the sheen stops, and scrolling a new vendor category into view jumps there instantly.

How I worked

I researched competitors and talked with the digital editors, then used what I learned to map the journeys in FigJam. I used AI to prototype a low-fidelity version of the revised flow. In a second pass I swapped the design system in for everything, and my coding agents helped implement the design on it.

Handing it to engineering

Full size

My branch came to 73 files. The engineer split it into a stack of eleven PRs, each under about a thousand lines and reviewable on its own, and merged it in order. The engineer refactored it afterward: the step model became explicit per-persona orders, the photographer step became a single search with inline email and Instagram fields, and the image rail and some "(optional)" labels came back.

Full size