
Notch
Role
Product Designer
Timeline
1.5 years
Scope
End-to-end design — UX, UI, design system, prototyping, testing
Contributors
Myself
The world of paid ads is largely constrained by one thing: creative volume. Every marketer wants to test more ideas, iterate faster, and outpace the competition. This used to be a slow and tedious process, but the rise of generative AI has upended the industry.
Founded by two ex-Meta cofounders, Notch uses generative AI to solve this problem. As the first full-time employee and the sole designer on the team, I had my hands on nearly every aspect of the product from pitch deck to public launch and everything in between.
Onboarding
Problem: Neo in the void
Our first pass at onboarding was an empty screen with a series of questions in the middle — the "Neo in the void" approach. No context, no sense of what's on the other side. Just answer these questions. 🔫
It had huge falloff.

Hello Neo…
Apple or Adobe can hold you hostage because you need to get through their setup. Plucky startups don't have that luxury. When low-intent users are greeted with a void and a demand for information…they just leave.
Our first reaction was to reduce friction—ask fewer questions, get people into the product faster. But this created its own problem: worse initial ad quality, which lead to more churn. We'd optimized for the tourists at the expense of the people we actually wanted. I wrote about a closely-related problem here.
Solution: all roads lead to Rome
Things improved when we started showing onboarding content in a dialog on top of the actual app UI. Now there's context: get through this and you'll get to access that.
Not only that — you can close the dialog and explore first. Poke around and get a feel for things. When you try to generate an ad, we bring you back into the flow. By that point hopefully you've warmed up a bit and are ready to commit.
Even with more steps, this performed much better.
Features vs workflows
As builders, we're often tempted to work on novel technical features — things users can't get anywhere else. Unfortunately these are often highly complex and take months to implement. Since everything is a tradeoff, that usually means you're not building simple things that can often move the needle more. Here's an example.
Early on, we started to gain traction with small agencies that needed to produce a high volume of ads for lots of different clients. They liked the creation tools, but their biggest pain point was getting ads out of the system and in front of clients for review.
We decided to take a week and build a simple workflow to make their lives easier: Share boards. Save ads to a board, get a public URL, and send it to anyone — no Notch account required. We even had an existing commenting system, originally built for teams discussing ads internally. Add some approve/reject buttons on each ad and you're good to go. Logged-in users can customize a board's name, URL, email sender name, or even copy embed code for their own site.
One week of work, and we solidified our first set of loyal users.

Boards grid view

Board detail view

White-label customization settings
We eat with our eyes
Early on, we thought what marketers really wanted was data-backed proof that an ad was likely to perform. To that end, we built things like predicted performance scores and insight snippets — "78% of your past winning ads also used this headline." — that kind of thing. Spoiler alert: past performance attribution, and especially prediction, are nearly impossible.

An old version of the ad review screen. In this case "show your work" didn't apply
The problem is that marketers are usually pretty well attuned to what works for their brand. They don't need a system to tell them. If you show someone a high score but it doesn't match their gut feeling, they'll go with their gut 100% of the time.
There wasn't any definitive moment that we discarded this notion. It just withered on the vine. Nobody ever mentioned it, and over time we stripped it out entirely.
The learning was clear: people just want to see the ad. "I'll know it when I see it" is real — it's how people actually operate. Once you accept that, the product questions get clearer: How do we get as many ads in front of people as possible, and how do we increase the hit rate?
Don't fight the tide
Especially in the early days, AI imagery was rarely perfect, and this meant people needed to edit the output. Typically ads are built as layered files, so "change the text" or "fix the logo" are simple edits, but not so when you're dealing with raster imagery. Through talking to users, we learned that most of them were using Canva in their existing workflows. Canva's array of raster editing tools gave us a familiar pattern to anchor on for our static editor UI.

Vertical tabs with tools on the upper left

The best-performing version of the edit screen
Gallery
Writing about every feature would turn this into a novel, but I know when I look at portfolios I like to see visuals, so here's a sample collection of screens from the product.
Reflection
Working as the sole designer at an early-stage startup has taught me many things, but chief among them is how to strip away the superfluous and focus on what’s important. At a startup you need to take a lot of shots, and that means speed and simplicity. We always want to spend time perfecting things, but you need to constantly remind yourself that there are 10 other high-leverage things you could be working on. As much as we may hate to admit it, there is such a thing as good enough, and you need to learn how to recognize it. As with many things it’s one thing to know the concept of an MVP, and another thing entirely to feel it.
I’ve over-designed things that never got implemented because a developer saw an easier way and took a shortcut. I’ve worked on features for weeks or months, only to abruptly abandon it and move on to the next thing. This experience has taught me to not be precious about my work. I’ve learned how to adapt my work to the need at hand. Move quickly when needed, and go deep and refine if warranted.
I’ve also learned that as a designer, we often play an absolutely critical role in shaping the back end. Most people (even developers) are visual thinkers — we react to what we see. Early prototypes can profoundly shape the how the back end of an app is structured. What data needs to be fetched when, and what to do with it. Being in touch with what’s possible in the dev domain can be hugely beneficial. If you can learn to paint a picture and communicate with the devs, you can move much more efficiently.







