I stopped thinking in screens

For a long time, a huge part of my work ended up on a screen.

That is not strange. I have spent years working across UI, UX, product design and creative direction, and interfaces were normally the point where everything became visible. Research, user needs, product decisions, brand, hierarchy, flows. At some point, all of that had to become something people could actually use.

But I was never only designing screens.

Even when I was working mainly as a consultant or Creative Director, a lot of the important work happened before Figma. What are we building? Why does it need to exist? Who is it really for? How should the product behave? What should feel simple and what can afford to be complex? What belongs to the brand and what is just decoration?

UI and UX were a huge part of my work, but they were never the whole thing.

What has changed over the last couple of years is that I can now follow those decisions much further into the product.

That has changed the way I think.

A few years ago, if I designed an interaction, I was thinking mainly about what the user needed to do, what information they needed to see and how the experience should behave.

I still think about all of that. But now I am also thinking about where the information comes from, what happens if the service fails, what the system should store, which part of the logic should be deterministic, where AI is useful, where AI should absolutely not be making the decision, and what happens when the model gets something wrong.

That is a very different way of looking at an interface.

At Pleo, this became very obvious to me.

I was working around things like KYC, due diligence, onboarding and expense approvals. In those systems, AI is not a fun layer that you add because it looks good in a demo. There are rules, internal processes, data, exceptions, case managers, company policies and decisions that can have real consequences.

The model is only one piece of it.

That was probably one of the moments where I started thinking less about “the AI feature” and more about the system around the AI.

What information can it use? What action is it allowed to take? When does somebody need to review the result? How do you show confidence? What happens if the AI does not know? What happens when the data is incomplete?

Those are product decisions.

And increasingly, I can investigate those things myself instead of waiting until much later in the process.

I can go into a codebase and understand enough of what is happening to ask better questions. I can inspect data, look at an API response, trace why something is failing, change part of a prototype and test the behaviour again.

Two years ago, I could understand many of those things conceptually. I just could not interrogate them directly in the same way.

That difference is bigger than I expected.

It also changed what a prototype means to me.

For years, I used prototypes to answer questions like: does this flow make sense? Can somebody understand this? Is the hierarchy right? Can the user complete the task?

Those are still exactly the questions I care about.

But now I can also make something that uses real data, calls a real service, keeps state or includes an actual AI behaviour.

And then it breaks.

Which is useful.

Figma is very polite. A real system is not.

A prototype can make a complicated interaction look completely reasonable because all the difficult parts have been simulated. Once the thing actually works, you suddenly discover that the response is too slow, the edge case happens all the time, the system needs information you never accounted for, or the AI gives you a perfectly valid answer that is completely useless to the person using it.

That is the point where design becomes much more interesting to me.

Because those are not engineering problems that happen after design.

They are part of the product experience.

This has also changed how I work with Pedro.

I do not suddenly want to become the engineer in the room, and I definitely do not think AI means designers should work alone. Quite the opposite.

But our conversations are different now because there is more overlap in what we both understand.

I can come to him with something that already works rather than only describing the behaviour. I can understand more of the technical consequences of a product decision. He can challenge what I am proposing much earlier. Sometimes I will build something and realise myself that the idea is unnecessarily complicated before we even discuss it.

That is good.

It means the feedback loop is much shorter.

The same happens when we test with real people. We can observe something, understand why it is happening, make a change and test again without turning every adjustment into a long handoff between disciplines.

For me, that is probably the biggest improvement.

AI has made me more technical, but I do not think it has made me less of a designer.

I think the opposite happened.

The design experience I already had gives me a way to judge what all of this new capability is actually for.

Being able to generate code quickly is useful. It does not tell you what should exist.

Understanding an API is useful. It does not tell you whether the experience is good.

Connecting a model to a workflow is relatively easy now. Designing the right role for that model inside a product is much harder.

That is where I think a lot of the interesting design work is moving.

Not “how should the AI screen look?”

More like: what is the AI allowed to do here, what should remain under human control, and how do we make that understandable to the person using the product?

The interface still matters enormously to me. Probably more now, because I understand more of what it is representing.

But I no longer see the screen as the place where the design ends.

It is the visible part of a much bigger system.

And once you start working that way, it is very difficult to unsee everything behind it.