Bernardo Presser

Working inside AI-first teams changes what design is responsible for. This isn’t about learning to code or becoming a data scientist. It’s about designing with models, constraints, and uncertainty from day one.

The shift took me a while to understand. Traditional features are predictable once shipped. A button does what it does. But models are probabilistic, stateful, shaped by data you don’t fully control. Design can’t assume consistency or completeness.

In this context, the design artifacts change. You stop designing screens and start collaborating with data scientists to design behavior over time.

→ Designing conversations

Take conversation design. Early on, I approached it like writing a script, mapping out what the system would say and when. That instinct was wrong for that project. Scripts feel scripted.

What worked was defining intent, attitude, and flow. Instead of delivering to data scientists the exact words I wanted the system to output, we had to work on the shape of the exchange. A script became a reference point – something to align the team around – while the actual conversation stayed loose enough to respond to what users brought in.

That meant spending more time on tone of voice and narrative structure than on specific UI patterns. I used flow diagrams to show how a single exchange could branch into variations, but the conversation always stayed one level above the exact words I expected as output.

→ Memory

Memory required the same shift in thinking. On the surface, it seems like a feature: the system remembers what you told it. But the design questions ran deeper. What gets remembered? Where does it surface? How is it phrased? What can users do with it?

Working with data scientists, we went deep into types of memory, for example. Events in someone’s life versus stable traits. Memories that fade without confirmation, relevance that shifts over time based on new data.

These can sound like backend technicalities, but they actually shape how a product feels, whether it comes across as attentive or invasive.

→ Output

Then there’s the constant negotiation around output. Models don’t naturally respect your layout. Getting structured responses (pulling out quotes, enforcing length, controlling hierarchy) meant designing constraints the model could follow without sounding robotic. The interface and the prompt became one system.

→ Mental models

Conversations, memory, output structure… each required finding a concept users already understood and mapping the model’s behavior onto it.

We had discussions about calling “memories” something else, for example. But “Memory” works because people know what memory is. They have intuitions about it: some things stick, others fade, context matters. We could design around those intuitions instead of explaining a retrieval system from scratch.

But not every model behavior has an obvious parallel to people’s experience. Part of the job was finding those bridges: names, metaphors, interaction patterns that made unfamiliar capabilities feel graspable.

When we couldn’t find one, the feature felt abstract no matter how well it performed.

That’s a fascinating space AI product design operates in. Not styling interfaces for outputs. Translating what models can do into things people already know how to use.