The sidebar menu is an apology, and we have mistaken it for design. Business software opens by showing everything the product can do, and somewhere in there is the thing you came to do. Find it. Good luck.
The menu exists because for forty years software could not understand what a person wanted, so it did the only honest thing available and laid out the full inventory of what it was capable of. The user supplied the one thing the machine could not: the translation from what I need to which screens, in which order, with which fields filled in.
That translation was the machine’s job, left undone because the machine could not do it. It can now. And most products have responded by adding a chat box in the corner and calling it done.
The interface was a workaround, not a principle
It helps to notice how much of standard interface design is scar tissue from a limitation that no longer applies.
Navigation hierarchies exist because the product cannot ask what you are here for. Empty states exist because the product cannot start the work for you. Onboarding tours exist because the product cannot notice you are stuck and step in at that moment. Documentation exists because the product cannot explain itself in the context where the question came up. Filters, saved views, dashboards you configure yourself: each one is a mechanism for the user to manually narrow a general-purpose tool down to their specific situation, because the tool cannot narrow itself.
Every one of those is a workaround for the same missing capability. And the missing capability arrived.
The mistake almost everyone is making right now is treating that arrival as a feature to add rather than an assumption to revisit. You end up with the old menu plus a chat box, which is worse than either: the product now has two front doors and no opinion about which one you should use, so the user carries the extra decision of which interface do I use for this on top of the decision they already had.
The flip: from a surface of options to a sequence of outcomes
The change I would make to most products is much larger than a chat box.
Today the product’s model of the user is a person looking at a screen. The unit of interaction is the click. The product’s job is to render every possibility, correctly and accessibly, and wait.
The version worth building models the user as a person with a queue of things that must be true by Friday. The unit of interaction is the task. The product’s job is to know that queue, order it, start each item, and bring the user in at exactly the points where their judgment is actually required.
Picture an operations manager’s Monday — an invented one, to show the shape. Three invoices need approving, one supplier’s details are stale, a report is due to a client, two new team members need access, and a renewal quietly lapses in nine days. Today, that person opens six screens across two products, remembers the renewal or doesn’t, and spends most of their attention on navigation rather than decisions.
The product already knows all six of those things. It has the invoices, the stale record, the report schedule, the pending users, and the renewal date. It has never once assembled them into a list and said: here is your Monday, in order, let’s go.
That is the whole flip: same data and the same permissions, and the product takes responsibility for the outcome instead of waiting to be navigated.
What “walking someone through” actually means
The phrase invites a bad implementation, so here is the shape.
It is a queue, not a conversation. Chat is a terrible primary interface for repeated work, because it makes the user compose a request every time for something the product should already know. A person opening their tool on a Monday should see the ordered list of what needs to happen rather than a blinking cursor asking how it can help. Conversation is the right medium for the ambiguous ten percent; the routine ninety wants a list.
Each item arrives already attempted. The item reads “I have filled in the supplier’s details from the two invoices they sent and matched their registration number; here is what I changed, confirm or correct it”, where a notification would have said “the supplier record is incomplete”. The difference between a notification and a draft is the difference between the product knowing about your work and the product doing it. One adds an item to your list. The other removes one.
Ordering is a product decision, and it is the hard part. Nine tasks presented as nine equal cards is a menu wearing new clothes. The renewal lapsing in nine days outranks the report due Friday, which outranks the two access requests, and the product should say so and be right often enough to be trusted. Getting that order wrong in a visible way costs more trust than never having offered it, which is exactly why most teams will build the cards and skip the ranking.
The user’s judgment is invited at every step. Every item needs a clear view of what will happen and a real undo. The goal is to remove the person from the parts of the loop that never needed them, so their attention lands on the parts that do. I have written before about the cost of letting AI erode the judgment layer, and this is where that line sits: the machine should own the sequence and the setup, and the person should own the call.
Nothing irreversible happens without a person. Send the money, delete the records, email the client: those are decisions, and they stay decisions. Everything up to the last click is preparation, and preparation is what the product should have been doing all along.
Guidance is a promise, and it can be broken
The reason this is harder than it sounds is that a guided product makes a much stronger claim than a menu does.
A menu promises nothing. It shows you the options and the outcome is your responsibility. That is why menus are safe, and it is a large part of why they have survived a capability shift that should have killed them.
The moment a product says here is your Monday, in order, it has taken on the promise that the list is complete and correctly ranked. A missing item is now the product’s fault, where before it was the user’s oversight. That is a genuine transfer of liability, and I think it is the actual reason most teams will not make this change: an unwillingness to be responsible for the outcome, well ahead of model costs or engineering effort.
Which is also why it is worth doing. A product that takes on that promise and keeps it becomes very difficult to leave, because switching means taking the responsibility back.
Two failure modes are worth naming for anyone attempting it. The first is confident wrongness: a queue that is subtly mis-ranked trains the user to check everything, and once they are checking everything you have added work rather than removed it. The second is silent scope creep, where the product’s helpfulness quietly extends into decisions the user assumed were theirs, and they only discover the boundary moved when something goes wrong. Both are trust failures rather than accuracy failures, and both are fixed by being explicit about what the product will do without asking. I have made the narrower version of this argument about an agent working inside a customer’s own workspace, where being wrong in someone else’s environment costs more than being wrong in your own.
Where to start, if you own one of these products
Start with a list of the things your users actually do, in the order a real week produces them.
Take one high-frequency workflow, the one your support queue is fullest of, and count the clicks between a user’s intent and the outcome. Then ask what the product already knows that would let it skip most of them. In most products the answer is nearly everything, because the data has been sitting there the whole time and the interface has simply never been the kind of thing that could use it.
Then build the guided path for that one workflow and leave the menu in place beside it. If the guided path is genuinely better, usage moves on its own and you will know within a fortnight. If it does not move, the ranking is wrong or the drafts are not good enough, and both are fixable. The interesting thing about this change is that it is measurable in a way most interface work is not: you either reduced the number of decisions between intent and outcome, or you did not.
The menu was an honest answer to a constraint that is gone; keeping it, with a chat box bolted to the corner, is choosing to make the user do the translation the product can now do for them.