The first was: wow this is so good.

The second was: I can’t believe they shipped this.

Instead of opening the familiar full-screen iPhone camera, ChatGPT keeps you inside the conversation. You take a photo, it collapses into the composer, and you keep going. It feels like one continuous action.

But ChatGPT isn’t a small app quietly testing design concepts. More than 900 million people use it every week. The familiar camera also carries years of solved problems: zoom, flash, grid lines, accessibility, and muscle memory. Build your own and they become your problems. Zoom is your bug now. Flash is your bug now.

I couldn’t stop thinking about the tradeoff. Was this innovative or reckless?

When should you reinvent an interface people already know?

Everything the default was doing

Here is a quick video of what the default iPhone camera looks like. It should feel pretty familiar to everyone:

And then here is the new version I built based on the ChatGPT camera:

I built my own version for Amy. Somewhere between the first prototype and the finished version, I started arguing with myself a bit.

What happens in a dark restaurant when someone needs flash? What if they want to zoom or rely on grid lines? Was I simplifying the task, or removing useful controls because the result looked better in a demo?

Familiar interfaces are easy to underestimate. They look generic because we no longer see the decisions inside them. The default camera isn’t just a collection of buttons. It’s compressed history: edge cases, platform conventions, accessibility work, and learned behavior.

Use the default and you inherit that work for free. Replace it and you inherit the responsibility.

That doesn’t mean familiar interfaces should never change. ChatGPT made a convincing case that the default can be designed for a much broader job than the one in front of you. But reinvention has a cost: you can make one path feel unusually coherent while reopening problems the old version already solved.

Who ships something like this?

I got curious about the team that would ship a change this bold. I went looking for a postmortem and never found one. What I found instead was better: the people who built it were talking about it in public.

A few days after launch, OpenAI design engineer Naman Kedia posted the flow. He described the attach menu, camera, and final attachment as “one continuous action.” That was exactly what had caught my attention.

He asked for feedback too. When someone flagged unreliable autofocus and no tap-to-focus, he said it was fixed and would roll out that week. That doesn’t tell me what happened before launch. But it does tell me they weren’t hiding from what was missing.

At an older company, I can imagine this becoming 10,000 meetings. One about flash. One about zoom. One about accessibility. Some would be about real problems. And somewhere in the middle of them all, the idea just dies.

I keep going back and forth on whether shipping first is brave or reckless. Part of me finds it incredibly inspiring that they just shipped it and listened. Part of me wonders how many solved camera problems they just made their own again.

The closest thing I found to an answer was an interview with Ian Silber, OpenAI’s head of product design. He said a lot of their work starts as a prototype the team can actually use inside the product. Then they iterate, see how it fits with everything else, and decide whether it should ship to everyone.

He wasn’t just arguing for speed, either. Rushing one thing out without seeing how related work could fit together is, in his words, “bad systems thinking.” He never mentioned this camera, and I don’t know if it followed that process. But his description made more sense to me than a simple “move fast” lesson. Get a real version in your hands. Use it. See how it fits. Then decide if it belongs. That was easy to admire when it was someone else’s product. It got harder when it was mine.

Then I had to make the decision myself

Admiring ChatGPT’s camera didn’t make it right for Amy. The question that helped me decide wasn’t really about cameras: What is the person trying to make?

On Instagram, the photo is the final product. I might adjust the framing, use grid lines, change the zoom, or take several versions. How it looks matters. That’s not what’s happening in Amy.

In Amy, I just want a calorie estimate. I’m not trying to take a beautiful photo, and I probably won’t edit, share, or look at it again. The photo isn’t the product. It’s disposable input. The camera is closer to a scanner than a creative tool.

Once I saw it that way, the tradeoff got clearer. I wasn’t removing controls from someone composing a photograph. I was removing decisions from a quick scan. The default camera supports every kind of photography. Amy’s only needs to help someone point at food, take a usable photo, and move on. So I kept the custom version.

I kept the camera. I kept the doubt.

Familiarity is a feature. A custom interface needs a better reason than simply feeling more distinctive.

In Amy, the narrower camera earns its place because the job is narrow. It keeps the interaction in context and removes controls that rarely matter for this photo. If people need flash more than I expected, or use food photos in ways I didn’t anticipate, I’ll revisit it. A clean interaction isn’t useful if it stays clean by ignoring what people need.

That’s what I find most interesting about OpenAI’s decision. They didn’t discover the universally correct camera. They treated a familiar interface as something that could still be questioned. Older companies can confuse deliberation with care. Faster ones can confuse motion with courage. I’m not sure either failure mode is better.

The rule I’m trying to use now: before reinventing an interface, understand what the default quietly does for you. Be specific about the narrower job your version serves. Know which problems you’re willing to reintroduce. Stay humble enough to put something back when the evidence changes.

The goal isn’t to make everything custom. It’s to know when the familiar interface was built for a different job. That’s much harder than making a new one.

We’ll see if i keep this camera in Amy.

Imagine you’re sitting inside Goobne Chicken with your food in front of you and your phone in your hand.

You open Amy, my calorie-tracking app, hold down the microphone, and say, “Two side dishes and Korean barbecue from Goobne.”

Somewhere in the middle of saying it, you have a quiet second thought: there’s absolutely no way it gets that.

An In-N-Out burger with fries is one thing. The words are common, and the restaurant name is familiar. Goobne is exactly the kind of name speech recognition can turn into something plausible and completely wrong. It might understand every other word in the order and still miss the one word that matters.

Then Amy just logs it. Goobne Chicken, spelled correctly, sitting in your food log like it was never in doubt.

The meal appears. No correction. No list asking which restaurant you meant. Nothing celebrates. It just works, and for a second you think: wait, how did it know that?

That little beat is the thing I’m chasing when I build.

People who build products talk constantly about “surprise and delight.” I’ve heard that phrase so many times it has almost stopped meaning anything. Usually it gets translated into confetti, a cute animation, or a clever empty state. I like those things. But building Amy has forced me to get more specific about what I actually mean: a moment that feels almost impossible to the person using the app.

Not flashy. Almost impossible.

So let me ruin the trick, because the reason that moment works is completely hidden.

When someone turns the feature on, Amy quietly looks up the restaurants around them when the app loads. It caches up to twenty nearby names, cleans them into keyterms, and sends those keyterms along with the audio when dictation happens. Goobne is no longer just a strange sound the system has to guess from scratch. It’s one of a short list of likely restaurant names nearby.

There’s no restaurant picker and no extra question. You say the order, Amy gets a better chance of understanding the difficult part, and you move on.

This feature is completely opt-in. It’s off by default. During onboarding, Amy explains why location helps and lets you choose whether to turn it on. Privacy was one of the first things I considered: Amy uses your location on-device to find nearby restaurants, but only the restaurant names are sent along as transcription hints. Your coordinates never leave the device.

I talked about this exact example in my video, How I Make Apps Feel Premium. I’ve started it at the restaurant section below.

This might be my favorite detail in Amy precisely because there’s almost nothing to show. Most product work is easy to point at. A new screen, a redesigned icon, a cleaner chart. You can put it in a screenshot and explain what changed.

This work disappears into the mistake that didn’t happen.

That’s what “surprise and delight” has started to mean to me. It isn’t necessarily an extra layer added after the real work is done. Sometimes it’s the invisible work that makes the obvious path succeed. The product does more thinking, so the person using it can do less.

If you’ve come across another “wait, how did it know that?” moment, let me know. I’m always looking for more examples like this.

Designs that inspire me

Every week, I’m going to share one or two interfaces that inspire me. I’m obsessed with designs that stop me from scrolling. Not because I love every part of them, but because there’s usually one idea inside them that I want to understand.

Dictation that feels like the default

This Monogram interaction caught my attention immediately. After the prompt is submitted, the words briefly bend and ripple as the interface gives way to the result. It’s a tiny transition, but it makes the whole surface feel unusually alive.

What I find most interesting is the keyboard button on the right. In the clip, the prompt is typed. But look at the hierarchy: the microphone is the big, obvious target, while the keyboard is a smaller control off to the side. Most apps do the opposite, with the keyboard first and dictation as the alternative. This layout suggests they expect you to speak. If you want to type, there’s still a dedicated button waiting for you.

I rarely see an app make the keyboard something you deliberately summon. It’s a small decision, but it says a lot about what the designers think the primary interaction should be.

The liquid treatment immediately reminded me of Wabi. I don’t know if that was actually the reference, but I like seeing that visual language on an interface that seems built around voice.

A background that becomes part of the subject

There’s a lot about this screen I don’t like, or at least haven’t made up my mind about. I’m going to ignore the bottom half entirely.

The top half, though, stopped me immediately.

The yellow gradient matches the book cover so well that the background feels like it’s coming out of the book itself. The book is still the focal point, but its color seems to spill into the rest of the screen. It makes the entire composition feel much more alive.

This is what I keep coming back to. The background is doing almost nothing structurally, yet the relationship between it and the book is powerful enough to stop the scroll. I’m increasingly interested in interfaces that borrow their atmosphere from the thing they’re framing.

Unfortunately, I don’t know where this image originally came from. I found it on Twitter, but I’m fairly sure the person who shared it found it somewhere else. If you know the original source, please email me so I can attribute it properly.