March 23, 2026
AI-native design isn't a chatbot on top
The hard design work is deciding when the system acts, asks and stays quiet.

A normal interface waits for input. An AI product can interpret, suggest and act before the user has described every step.
That sounds like a model capability. In practice it is a design problem.
I have spent more than twenty years moving between product, design and technology. Games at DICE, retail at Marks & Spencer, financial products and now an AI venture studio. AI is the first shift where the behaviour of the system is part of the interface, not merely something behind it.
The chatbot is usually the easy way out
A text box can be useful. It can also hide the fact that nobody designed the workflow.
If the user has to explain their job from scratch, know what the model can do and translate every result back into the product, the intelligence has been bolted on. The old product is still doing the real work.
An AI-native product makes different decisions:
- What context should already be available?
- When should the system act and when should it ask?
- How does it expose uncertainty?
- What needs confirmation before it becomes irreversible?
- Can the user see what happened, correct it and recover?

Those questions determine whether the product feels useful or slightly possessed. The model choice matters. The interaction contract matters more.
Designing behaviour, not only screens
Traditional product design gives us a fairly stable object. Press this button, get this result. The interesting variables are hierarchy, flow, feedback and state.
AI adds judgement to the system. The same request can produce different plans. Context can be incomplete. A correct action can still happen at the wrong time.
The design material now includes:
- initiative
- restraint
- confidence
- memory
- permission
- provenance
- recovery
None of those fits neatly into a Figma component library.
The design is not finished when the happy path looks polished. It is finished when a user can tell what the system believes, why it acted and how to stop or undo it.
Games taught me more about this than chatbots did
At DICE, a HUD had to communicate state while someone was driving a tank, getting shot at and deciding what to do next. If the interface demanded interpretation at the wrong moment, it failed.
AI products have the same problem in a less cinematic outfit. They carry hidden state, make recommendations and sometimes take action. The user should not need to reverse-engineer the system while trying to finish the actual job.
Good AI interaction reduces that uncertainty. It makes the important state visible and leaves the rest alone.
Design has to move upstream
In an AI product, architecture creates experience directly.
A retention policy changes what the product remembers. A permission model changes whether it feels trustworthy. Tool access changes what it can do. A verification loop changes whether the output deserves to be shown as complete.
Those are engineering decisions and product decisions and design decisions at the same time. Waiting for a finished technical plan and then designing the surface is too late.
This is how we work at kerber.ai: define the behaviour, boundaries and evidence before polishing the interface. Not because visuals matter less. Because a beautiful surface cannot rescue a system that acts without judgement.
AI-native design is not a new aesthetic. It is the craft of making intelligence legible, interruptible and useful.
The interface is no longer only what the product shows. It is what the product decides to do.