The AI headshot space in 2024 was crowded, fast-moving, and — let’s be honest — mostly cheap-looking. Everyone was selling the same promise: upload a selfie then get your LinkedIn photo. The difference was going to have to be in how it felt to use it, and how much you trusted it before you ever clicked upload.

That was the design problem. Everything else followed from there.

The market looks like a scam. Your product can’t.

AI imaging tools in 2024 had a branding problem. The category was dominated by flashy landing pages, suspicious-looking before/afters, and the kind of copy that makes you check if your credit card is still in your wallet. Aurawave needed to sit in the same space without looking like it belonged there.

The brand work started with a single constraint: it had to feel like software a professional would actually recommend to their colleague. That meant restraint. Maybe a tighter color palette, typography that leaned editorial, and a visual language that communicated precision over hype. The goal wasn’t to look expensive. It was to look trustworthy.

You’re asking people to hand you their face.
That’s not a small ask.

The UX challenge that doesn’t show up in briefs: people are weird about photos of themselves. Add AI into the equation, and the anxiety compounds. Users needed to feel like they were in control of the outcome before they committed to the process, not after.

Moving fast without making a mess.

Six months from nothing to shipped, with a team that was still being assembled while the product was being built. The design system wasn’t a nice-to-have — it was the thing that kept the whole project from becoming a pile of inconsistent screens.

The component library was built lean on purpose. Design tokens for color, spacing, and type meant that brand decisions made in week two weren’t being manually hunted down in week ten. Components were documented for engineers who hadn’t joined yet, in language that assumed nothing. That last part mattered more than expected. Onboarding a developer to a design system you built is a completely different problem than building the system.

What shipped, and what I can actually own.

The MVP launched on schedule. The brand had a clear identity, something the AI headshot space genuinely lacked at the time. The design system was documented, tokenized, and handed off with enough structure that an incoming team could build on it without starting from guesswork. Engineers were onboarded to the component library before I stepped back. The flows were tested with real users before development locked anything in.

What happened to the product after handoff isn’t mine to speak to. I’m not in touch with the team anymore, and the live site today reflects decisions made after my involvement ended. What I can say is that what we handed off was solid, and the gap between that and what’s live is an implementation story, not a design one.

What I’d do differently.

The onboarding flow worked, but it was validated after development had already started.
One earlier round of user testing — even informal — would have surfaced friction points while there was still room to fix them cleanly. Lightweight research at the start is almost always worth the delay. Almost.

The bigger lesson was about handoff. A design system is only as durable as the people maintaining it after you leave. Documentation helps, but it’s not a substitute for overlap time — a period where the incoming team builds with you, not just from your files. I’d push harder for that on any project with a team transition built into the timeline.