We Keep Redesigning the Interface. Maybe We Should Redesign the Way We Design

A button used to be enough.

For a long time, product design was mostly about figuring out where that button should go, what it should look like, and what should happen when someone clicked it.

Then interfaces changed.

We moved from command lines to graphical interfaces. From desktop applications to the web. From menus and navigation to search. From mouse and keyboard to touch. From screens to voice. And now we are moving toward interfaces where we can simply describe what we want and let the system figure out how to do it.

When I look at this evolution, I don’t think the most interesting change is the interface itself. It is how much the user has to understand about the system before they can use it.

That has been changing for decades. And I think that is also changing what it means to be a product designer.

The interface was always a translation layer

Think about a command line.

The machine can do a lot of things, but you need to know the language of the machine to ask it to do them. You have to remember commands, syntax, and the right way to express an action.

The computer is powerful. But the burden is on you.

Graphical interfaces changed this relationship. Instead of remembering a command, you could see a file, click an icon, open a menu, or drag something from one place to another.

The computer didn’t suddenly become less complicated. The interface became better at translating the computer’s capabilities into something people could understand.

That distinction is important because I think we sometimes talk about interface evolution as if every new interface simply replaces the previous one.

It doesn’t.

Each new interaction model changes how much of the system the user has to understand.

The shift looks something like this:

The interesting part is the direction of that movement.

We keep asking the user to understand less about how the system works and focus more on what they want to accomplish.

That is a much bigger change than replacing a menu with a chat box.

From controls to flows

Early product design naturally focused on controls.

• There was a button.
• There was an input.
• There was a dropdown.
• There was a menu.

The designer’s job was to make those things understandable and usable.

But as products became more complex, a single interaction was rarely the whole experience. Clicking a button might open another screen, which might require another decision, which might lead to a confirmation, which might produce an error.

So we started thinking in flows.

Instead of asking only, “Where should this button go?”, we started asking, “What happens before this? What happens after this? What does the user need to do next?”

That was an important shift.

Then products became even more complex. Hundreds of screens couldn’t each behave differently. So we started designing systems: components, patterns, rules, states, and design systems.

The designer was no longer only designing a screen. They were designing the rules behind many screens.

And now AI is pushing that idea one step further. We are starting to design behavior.

The screen is no longer the whole product

This is probably the part of AI product design that interests me the most.

When we open Figma to design a traditional product, we usually have a fairly good idea of what we are designing.

• A screen.
• A flow.
• A set of interactions.

But imagine a user saying:

Find the best flight for next weekend, check the baggage rules, and book it if everything looks good.

That isn’t really a screen problem.

There might be a screen where the user starts. But after that, the system may need to search, compare results, understand preferences, check information, make decisions, and perhaps ask for approval before completing the booking.

The user’s interaction could be very simple. The system’s work behind that interaction could be extremely complicated.

This changes the model we have been designing around. Traditionally, it looks something like: User → Interface → Action → Result

The user sees the interface, chooses an action, and the system responds.

With AI, it starts looking more like:
User → Intent → Context → System → Action → Result

• The user doesn’t necessarily specify every action anymore.
• They express an intention.
• The system figures out some of the work required to get there.

And that means the interface isn’t necessarily the most important part of the interaction anymore.

The interesting design questions move underneath it.

• What does the system need to know?
• What should it figure out itself?
• What should it ask the user?
• What should remain visible?
• What should happen in the background?
• Where should the user be able to intervene?

These are not really visual-design questions.

But they are becoming product-design questions.

This doesn’t mean everything should become AI

There is also a trap here.

Once we start thinking about intent and agents, it is easy to assume that every interaction should become conversational.

I don’t think that is true.

• If I want to turn Wi-Fi on, I don’t want to have a conversation with my phone.
• If I want to choose a date, a calendar is probably better than typing a sentence.
• If I want to move an object around a canvas, direct manipulation makes more sense than explaining where I want it to go.

The interesting question isn’t “How can we add AI to this?” It is: What is the best interaction for this task?

• Sometimes that is a button.
• Sometimes it is search.
• Sometimes it is a form.
• Sometimes it is a conversation.
• Sometimes it is automation.
• And sometimes it is an agent that can take care of several steps for us.

AI doesn’t replace these interactions. It gives us another one.

And sometimes it changes what happens between the user’s request and the final result.

The system itself becomes part of the experience

This is where designing AI products gets different. In a traditional interface, we spend a lot of time thinking about what the user sees when they click something.

But what happens when the system itself is doing work?

• It might be searching.
• It might be deciding.
• It might be using a tool.
• It might be waiting for another system.
• It might have found something but still be checking it.
• It might fail halfway through.
• It might ask the user a question because it doesn’t have enough information.

A simple loading spinner doesn’t really explain any of this.

The user needs some understanding of what is happening, especially when the system is taking actions on their behalf.

This doesn’t mean showing every technical detail. It means giving people enough context to maintain a mental model of the system.

• If an AI says, “Done,” I should have some idea what it actually did.
• If it says, “I couldn’t complete this,” I should know where it stopped.
• If it needs my approval, I should understand what I am approving.

We are no longer designing only what the user does. We are designing what the system does while the user waits, watches, decides, and corrects.

That is a very different design problem.

More autonomy creates a new design problem

The more capable these systems become, the more we have to think about control.

Suppose an AI can do something for me.

• Should it just do it?
• Should it show me what it plans to do first?
• Should it ask for confirmation?
• Should I be able to undo it afterwards?

The answer depends on the task.

• If the action is harmless and reversible, the system can probably take more initiative.
• If it affects money, data, other people, or something difficult to reverse, I probably want to see more before it happens.

This creates an interesting relationship between automation and control.

The goal isn’t maximum automation. It is the right amount of automation.

A good AI product doesn’t necessarily make the user do less at every step.

• Sometimes the best experience is for the system to handle everything quietly.
• Sometimes the best experience is for the system to stop and say, “Here’s what I found. This is what I’m about to do. Do you want me to continue?”

That moment of stopping is not necessarily a failure of AI. It can actually be good product design. Because the system is powerful enough to know when the human should remain involved.

We also have to design for system mistakes

There is another subtle change. For years, UX talked a lot about user error.

• What happens if someone enters the wrong password?
• What happens if they delete something accidentally?
• What happens if they make the wrong selection?

We designed validation, confirmation messages, undo, and recovery around those situations.

With AI, the system itself can be wrong.

• It can misunderstand the request.
• It can use the wrong information.
• It can make an incorrect assumption.
• It can take the wrong action.

And sometimes it can sound completely confident while doing it. That means recovery becomes even more important.

The product needs ways to correct the system, edit its output, undo its action, provide better context, and try again. This is why I don’t think the goal of AI product design should be to make the AI look perfect.

The goal should be to make the product resilient when the AI isn’t perfect.

That is a very different mindset.

Instead of asking only, “How do we make this experience feel intelligent?”, we also need to ask, “What happens when the intelligence is wrong?”

Maybe the interface isn’t disappearing

There is a lot of discussion about AI making interfaces disappear.

I am not sure that is what is actually happening.

The interface may become visually simpler. A complicated application might have one input field where today it has twenty controls. But the product underneath that input field can become much more complicated.

That one field may now hide context, permissions, memory, search, tools, decisions, progress, failures, and actions.

So we may end up with an interesting contradiction.

The simpler the interface looks, the more complicated the system behind it might be.

And that makes the designer’s job harder, not easier.

• When we show someone twenty controls, we can see the complexity.
• When we show them one box, we hide it.

But hidden complexity still needs to be designed.

The fewer controls we show, the more carefully we may need to design everything happening behind them.

So what does a product designer design now?

I don’t think the role suddenly becomes “AI designer.”

That label doesn’t really explain the change. The bigger change is that the object we design keeps getting larger.

• First, we designed controls.
• Then we designed flows.
• Then we designed systems.
• Now we are increasingly designing behavior.

The question has moved from “What should this button do?” to “What should the product do when the user expresses an intention?”

That sounds like a small difference, but it changes where we begin.

• Maybe we shouldn’t start by opening Figma and drawing the interface.
• Maybe we should start with the user’s goal.
• What are they actually trying to accomplish?
• What information does the system need?
• What part of the work should the system handle?
• What part should the human handle?
• Where does the human need visibility?
• Where does the human need control?
• And what happens when either side gets something wrong?

Only after answering those questions should we decide whether the interaction needs a screen, a search box, a conversation, a notification, an approval step, or something that happens completely in the background.

The interface comes later.

We have been designing the distance between humans and machines

When I look back at the history of interfaces this way, it feels less like a history of visual styles and more like a history of responsibility.

• The command line asked humans to understand the machine.
• The graphical interface made the machine easier to operate.
• The web gave us a way to navigate an enormous amount of information.
• Search let us describe what we were looking for without knowing where it lived.
• Mobile made interaction more direct and more contextual.
• Conversational interfaces let us express things in our own language.
• And AI systems are starting to let us describe an outcome and leave some of the work to the system.

The interface keeps changing because the relationship between the human and the machine keeps changing. Maybe that is why simply learning how to design the next interface isn’t enough anymore.

We need to understand who is responsible for what.

• What should humans do?
• What should machines do?
• What should the system decide?
• What should it ask?
• And where should the interface sit between the two?

That, to me, is the more interesting future of product design. Not just designing a better interface.

But redesigning the way we think about what an interface is in the first place.

We Keep Redesigning the Interface. Maybe We Should Redesign the Way We Design was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.