
The scene from Men in Black remains very clear in the minds of all those who have seen it. Agent K removes a small silver pen, the Neuralyzer, and in a single move erases the last few minutes of a stranger’s memory. Since no trauma is inflicted and no confusion arises, all that is left is a blank surface in the place where the flying saucer had been. The person then leaves believing that it had been an unusual night and that nothing else had occurred.
Product designers could easily make use of one of these nowadays. This is not because all that we’ve learned about building SaaS is incorrect, but rather since, after many years of working with dashboards, workflows, forms, tables, filters, and notifications, our instinctive responses have become conditioned to deal with a type of model that changes faster than we can adapt to.
The initial model supposes that the user carries out the operation with the software, while the new one supposes that the software acts on the user’s behalf; this kind of change is greater than one might at first think.
The old process ran on manual effort
With traditional SaaS the setup was very simple — you supplied us with your data, set up the platform, kept your records in order, got used to our procedures, and in return we would assist you in staying organized. Even the most efficient of the products in this area still required a good deal of human involvement. Someone had to input the information, establish the links between the various services, keep an eye on the dashboard, read the report, detect any anomalies, carry out the necessary task, follow up with a colleague, and then put all of this together into a story that was worth telling.
Because of improved navigation, fewer clicks, more sensible defaults, and cleaner dashboards — all of which were genuine advances — we became very good at making the process less tedious, even though it was still up to the individual to carry out the task.
At the moment, people are having AI rewrite agreements, hoping that the system will understand their situation, pick out the key points, suggest actions, and carry out the various routine tasks with only a moderate degree of oversight. Their request has boiled down to this: show me what you have, let me know what I should do, make a recommendation, look after the routine work, and help me to achieve the desired result. This is not merely a desire for a more attractive dashboard; it is in fact asking for leverage.
Forget the interface-first instinct
An experienced designer remembers a variety of patterns, and in most cases this is an asset. A big dataset is placed in table form. Filters are used to handle the complexity. Performance is displayed on a dashboard. A process is turned into a wizard. Any missing information is made into a form. All the points that are worth noting are converted into notifications. Confusion is dealt with through documentation.
It by no means renders it outdated; on the contrary, the risk is that the pattern will emerge before we have actually addressed the question.
If a customer asks, “I need to find out which contracts are putting our renewal target at risk,” the usual answer is to offer a configurable reporting screen. The present approach, however, is like this: “Three of the renewals are in a position of missing this quarter’s target — one has declining engagement, another has pending legal terms, and the third has no executive sponsor. I’ve already determined the recommended actions and have assigned responsibility for each one. Shall I carry on?”
The first version allows a person to obtain information whereas the second gives them a sense of momentum. This short description encompasses the whole change since it changes what a designer is actually responsible for. We no longer require every gear and lever to be operated by the user manually. Rather, we determine what the system should notice, what it should infer, when it should intervene, what it may do without any human input, and where a human must always be involved.
AI is the foundation, not a feature you bolt on
Another idea put forward by Clark is to treat AI in the same way as we do other design materials, such as typography, data, or CSS. All these different materials have their own features; some are suitable for certain types of tasks while being resistant to others. AI is genuinely useful for recommendation, prediction, classification, clustering, and generation, providing a far greater range of tools than simply having a chatbox in a corner.
The recommendations determine which items actually warrant someone’s attention. Predictions are able to identify potential problems before they turn into fire drills. Classification is useful for organising the huge amount of information that is received. Clustering can uncover patterns that nobody would discover simply by scrolling. Generation can produce draft versions, prepare summaries, and examine various options even if a person hasn’t had the time to write them out themselves.
The true design issue is not really about ‘where can we integrate AI?’ but rather ‘which of these capabilities actually helps this person to make a better decision, to skip over something tedious, or to achieve their goal more quickly?’ In some cases an agent with such capabilities is indeed necessary. In other cases, however, it is sufficient to offer what Clark refers to as ‘casual intelligence’ — that is, a gentle suggestion, a clever default, or a minor nudge which eliminates any friction. The sentience level need not be set all the way up to ten on every screen. In fact, the best AI experience is usually the one that goes completely unnoticed, just as happens with the kind of agents dressed in black: they work most effectively when people are not even aware that they have been in the room.
Erase the assumptions, not the human
We need to be careful about using the metaphor of the Neuralyzer in this case, since K’s flash didn’t get rid of the person’s identity but merely eliminated one particular misleading memory in order that they might continue to live their real life without having a record which didn’t make sense. That kind of erasure is also the one we desire.
We must not discard years of user research or assume that the basic needs of humans have disappeared; since people still require clarity, accessibility, a sense of control, feedback, safety, and trust, all of these qualities should be maintained. The idea that our previous behaviour can serve as a guide to what people will want in the future has to be taken into account.
The fact that users keep going to the dashboard does not mean that they want a dashboard; it might simply be that the dashboard was the only way of obtaining an answer. The fact that people export all the data into a spreadsheet does not prove that the export function is useful; it’s possible that the product had never actually helped them in thinking about the data. The fact that people continually request more filters doesn’t show that they want more manual control; it may only indicate that they want the system to find the information for them. You should keep focus on the basic need and ask whether the earlier method in fact met that need.
Design for a partner, not a replacement
The book Sentient Design by Josh Clark is not intended for the sake of automation; rather, it aims at improving upon human decision-making than replacing it. The significance of this point is greater than almost any other aspect throughout the entire transition.
Clark refers to these experiences as being collaborative, so that he remains an active partner at every stage of the process. They are multimodal since they make use of text, speech, touch and visuals according to the situation. The experiences are continuous and work in the background, appearing when it is appropriate and remaining quiet when they aren’t. Moreover, they are deferential in that they provide suggestions rather than imposing them and always align with the individual’s own objectives rather than their own.
A far more reasonable question to concentrate on is not “how many tasks can this agent automate?”. The key issue is whether the system helps a person to think, decide, create, and lead. From the very start our aim has been to get people involved in meaningful work rather than removing them from it; in fact, what we really want is to alleviate the administrative burden from the kind of work that is important.
From tools to teammates
A tool is ready and can be picked up and put into action; one of the team members notices the situation, understands it, makes a proposal, and in some cases deals with it oneself, which is why the designers are given a entirely different range of materials to work on.
Instead of offering a menu system, the product should recognise the user’s role, their objectives, the task they are currently engaged in, and their history, rather than asking them to go through a menu. Rather than simply making insights visible, it should give recommendations since nearly nobody actually wants ‘more insights’; what they really want to know is what has changed, why it is important and what action they should take next. Instead of asking users to go through the entire workflow, the system should allow them to delegate an outcome together with the appropriate constraints and approval limits, rather than requiring them to carry out each of the intermediate steps themselves. Rather than demanding that users be constantly monitoring the system, it should only interrupt the user when there is a change or a risk that calls for human involvement. Success should be measured by outcomes and not by the number of records updated, since it is not the number of updates that matters but what has in fact been achieved by them. Furthermore, the product should adapt rather than be configured by slowly learning the user’s preferences and by showing how it reaches its decisions, rather than insisting that a settings page be completed before it will offer any assistance at all.
Even though the number of observable interactions is small, the result can still have a great deal more value if the action is carried out well.
Trust has to be built into the workflow itself
The advantage of using agents is that they require less effort, while the disadvantage is a loss of control; this compromise will only work if trust is built into the system from the very start rather than being added later as a response to a problem.
Even though generative systems may appear convincing, this does not prove that they are correct. As Clark points out, rather than viewing them as answer machines we should consider them to be devices that generate signals and possibilities worth examining. It follows that they cannot simply be dealt with by means of a refined user interface.
It is essential that people be able to see the information on which the system has based its decisions, the assumptions it has made, the level of confidence it has in them, the action it intends to take, the cases in which human approval is needed, and how to reverse things if anything goes wrong. The aim is not to achieve the highest possible degree of automation but rather to have the appropriate amount of autonomy. A trustworthy agent should know when to act, when to request permission, when to explain its actions, and when to stay inactive, just as it is natural that an agent dressed in a black suit should in fact perform well rather than merely appear intimidating.
A new set of questions to start with
If you really do want to reset the mind of an experienced SaaS designer, it is useful to include a deliberate phase of distraction when starting a new project. For a time, stop thinking about the screens you currently have. Stop worrying about the stack of feature requests. Stop considering the way things have always been done.
Begin by focusing on the actual outcome that the person wants to achieve. Identify which aspects genuinely need a human to judge and which are included simply because the system lacks sufficient context to handle them. What can the product notice, get ready, recommend, or carry out without any involvement from the user? What should attract the person’s attention and what should remain unseen? How should the experience be structured to align with what they are trying to do at this moment? What actually makes a recommendation trustworthy? In what situations does the person have to make the final decision? How easy is it to detect and correct an error? And how can the system indicate that an outcome has occurred without having to produce extra reporting?
One must decide whether or not a dashboard, a conversation, an approval queue, an active briefing, or indeed no visible interface at all is necessary only after having considered those questions.
Everyone still wants to be the hero
No one genuinely hopes that AI will take on the role of hero in their own work; what they really want is for it to get rid of the administrative workload that has been stopping them from becoming the hero themselves. They would like to walk into a meeting already knowing what changes have been made. They want any possible risks to be identified before they turn into emergencies. They tend to prefer to be given a suggested course of action rather than just more raw data. They want routine tasks to be carried out smoothly. At the same time, important decisions should be brought to their attention, and they want to reach their destination without having to spend hours reconstructing the idea that the designer’s role hadn’t really been about making the software easier to click through; it had been about identifying things that someone should never have to do again, and about finding out where a bit of intelligence can help people become better at the parts that still matter.
Go ahead and flash the Neuralyzer; you don’t have to be concerned about the fact that the software has to be used on one screen at a time. It is not accurate to say that engagement consists of clicks. You should not suppose that visibility guarantees value. Likewise, you must not believe that the workaround which was used yesterday will be required tomorrow. Moreover, you must not think that the term “AI” automatically means there is a chat box in the corner.
In the same way that when K moved away from the flash and yet remained entirely himself, grasp onto all the things that truly matter — human agency, sound judgment, honesty about how things work, accessibility, trust, and the simple desire to be involved in work that is worthy of pride.
The future of product design doesn’t involve getting rid of all the knowledge that we currently have; instead, it means identifying the essential elements that remain and then rethinking the way they affect the experiences of the future.



