The life of a designer is a life of fight:
fight against the ugliness.
— Massimo Vignelli
Where should the AI live?
A concept validation study for an AI assistant inside a fleet intelligence platform
My role
Product Design Lead
Framing, concept design, test facilitation, synthesis.
Scope
Exploratory study
Output
A set of principles, four rejected directions, and one recommended direction with its open questions.
Context
The platform tracks commercial vehicles across engine health, fuel, trips, driver behaviour and breakdown prediction. It is dense, because the data is dense.
The people using it are not analysts. A fleet owner running sixty trucks wants to know why last month's diesel bill went up. An ops manager wants to know which vehicles will not make tomorrow's dispatch. A maintenance head wants to know which trucks are about to cost him money.
The pattern we kept hearing in interviews was the same loop every time. Owner messages ops manager. Ops manager opens the dashboard, filters it, screenshots it, sends it back. The translation layer between the data and the decision already existed, and it was a person.
So the question was not whether to build an assistant. It was what shape an assistant should take inside a product like this, and whether customers would use it once the novelty wore off.
Why we ran this as a study
The easy version of this project is to put a chat window on the screen and call it AI. We had seen enough of those.
The risk was not technical. It was that we would ship something structurally wrong and only discover it after it had become load bearing. So we built low fidelity, clickable versions of several placements and tested them with existing customers against questions they brought with them, rather than tasks we invented.
Philosophy
Seven principles, written before any screens. They did most of the arguing for us later.
1. Answers, not conversations.
Nobody wants to chat with a truck. Lead with the number, then the reason, then a way to go deeper. Success is the user leaving in thirty seconds, not staying for eight turns. We deliberately never treated session length as a good sign.
2. Contextual awareness.
The assistant should understand and adapt to the user's current page, their preferences and their previous questions. If the product already knows the depot, the date range and the vehicle you are looking at, making you restate it is a design failure. This principle decided almost every placement question in the study, and it is the reason a per widget assistant was tempting in the first place.
3. Transparency.
Clearly articulate how the answer was reached. Plain language over model language, visual cues over prose, and a stated basis for every number: how many vehicles, what date range, which data source, last synced when.
4. Robust handling of edge cases and unpredicted scenarios.
Design for graceful degradation. When the assistant hits something outside what it can do, it says so, names the limit, and offers the nearest thing it can actually answer. It may decline. It may not approximate. Silence beats a confident guess, because in this domain a plausible wrong number travels further than a missing one. Where a question needs a human, the assistant hands off rather than improvising.
5. Thoughtful safety measures and user control.
Clear human in the loop mechanisms, so people can understand, override or take full control of anything automated, particularly when the stakes are high. The assistant proposes, the human disposes. No dispatching, no reassigning drivers, no closing faults. Anything with a financial or safety consequence gets prepared for a person, not executed for them.
This one was validated hard in testing. Ops managers wanted confirmation on every automated action, and their reasoning was sound. If the assistant books the wrong service slot, the vendor still bills them.
6. It ends where the product begins.
A shortcut into the product, not a replacement for it. Every answer can push a filtered view into the dashboard, and the assistant never becomes the only way to reach something.
7. Fluent in the language of the yard.
People type in Hinglish, say gaadi rather than vehicle, challan rather than violation, and abbreviate registration numbers. Meet that vocabulary rather than training people out of it.
The real question: where does it live?
This turned out to be the whole project. Three explorations, in the order we ran them.
Exploration 1: A destination in the left nav, or a bubble that follows you everywhere
The left nav entry treats the assistant as a place you go. Permanent home, room for history and saved answers, and it signals a feature with depth rather than a gimmick.
The cost is that you leave whatever you were looking at to get there. You arrive at an empty input box having just abandoned the exact context your question was about, then type that context back in by hand. A left nav item also sets the wrong expectation, because every other item in that list replaces the page. People clicked it braced to navigate away.
The global bubble solves the context problem in theory by being available at the point of need. Two things went wrong in practice. A bubble anchored bottom right is so strongly coded as support chat that people brought it password resets and billing questions before they brought it anything about their fleet. And on a dense dashboard it sits on top of the data, which is the one thing it must not do.
The more useful finding was that the placement debate was a proxy for something else. An omnipresent assistant that does not know which screen you are on is not omnipresent, it is just always in the way. Presence without context inheritance is decoration.
What we took forward: the entry point belongs in the persistent frame of the app rather than floating over content, and clicking it should open a panel beside the data, not navigate away from it.
Exploration 2: An assistant inline on every widget
The appeal came straight out of principle 2. Ask from the fuel widget and it already knows the metric, the depot and the date range. Zero setup, every time.
It broke on history, and worse than we expected.
Ten widgets meant ten conversation histories. People do not remember questions by widget, they remember them by question. "I asked this last Tuesday" became a hunt across cards, and once someone could not reliably find a previous answer they stopped treating the assistant as something that accumulated value.
The second failure was structural. The most valuable questions cross widgets. "Is fuel cost up because of the route or the driver" touches three cards. An assistant living inside one widget can only answer the narrow questions, which are the ones the dashboard already answers.
Third, a sparkle icon on every card teaches people to ignore sparkle icons.
The reframe that saved the idea: what we wanted from inline placement was context inheritance, not a chatbot per widget. Those are separable. One assistant, one history, invoked from anywhere. Trigger it from a widget and it opens pre scoped to that widget's filters, shown as editable chips. Context comes for free, history stays in one place, cross widget questions stay possible.
What we took forward: an "ask about this" affordance on widgets that opens the single assistant, pre scoped.
Exploration 3: the fifty-fifty split
The most complete version we built. Half the screen carried the important widgets, half carried a persistent assistant. Answers on one side could change the view on the other.
It demoed beautifully and failed in use.
Halving the canvas is a permanent cost paid for an occasional interaction. Widgets designed for full width reflowed badly, charts became unreadable, tables lost the columns that made them worth reading. Tolerable on a wide monitor, collapsed on a laptop, and a meaningful share of ops work happens on smaller screens.
The chat half also sits empty most of the time. An always visible empty input is not neutral. It creates a low grade obligation to use it, and people noticed the assistant more while ignoring it than while using it. Two competing focal points meant nobody knew where to look first.
The part worth keeping was the coupling. An answer changing the view next to it felt genuinely good, and it is the behaviour that makes an assistant feel like part of the product rather than something bolted on. That coupling does not require a permanent split. It requires a panel that opens on demand beside the content and can be dismissed.
What we took forward: the coupling, not the layout.
A smaller decision that mattered: which side
The panel opens from the right, and the reasoning is about role rather than convention.
Where a conversation produces the artifact, the chat belongs on the left as the input column, with the output beside it. That is the pattern in generative tools like Figma Make and Lovable. Where a conversation comments on an artifact that already exists, it belongs on the right, alongside inspectors, filters and detail panels. Cursor is the useful check here, since its chat sits right for exactly that reason.
Our assistant is the second kind. The data is already on screen and the assistant interprets it. The right edge is also the only free one, since the left already carries navigation, and anchoring right keeps the nav and the content from shifting when the panel opens.
Persistence: what the assistant is allowed to remember
The placement questions were answerable in a week. These took longer, and they are the ones that decide whether the thing survives daily use.
Navigating does not close the panel. Panel state is chrome state, not page state. If it closed on every navigation it would read as a per page widget, and people would stop opening it because reopening costs more than the answer is worth.
Context attaches to the message, not the session. This is the trap. If a thread silently re-scopes when you change pages, every answer above becomes misleading, because it now sits under a context that was not true when it was asked. Each question captures its scope at the moment it is asked and carries its own chips. Old answers keep their old chips forever. On navigation the assistant drops a quiet divider naming the new context, and the next question inherits it. One history, no contamination.
Three different lifetimes, not one.
Panel open or closed persists across navigation and reload, per device, and resets to closed on a fresh login. You do not impose the assistant on someone who has not asked for it today.
Thread content persists indefinitely in a history list, searchable by question. This is what rescued Exploration 2. A new thread begins on a new day or on an explicit new chat, so the panel never opens onto three weeks of scroll.
Answer validity is the shortest lifetime and the one most easily forgotten. An answer from last Tuesday said fuel cost was a certain figure per km. It is still on screen, still looks authoritative, and may now be wrong. Answers carry a timestamp, visibly age into a muted state past a threshold, and offer a re-run. Never re-run silently. A number changing underneath someone is worse than a stale one they can see is stale.
Logging out is two cases, not one.
Same person, same machine: history restored, panel closed, threads intact.
Different person, same machine: common in depot offices with shared terminals. History is scoped to the account and cleared from local storage on logout, not merely hidden. A thread full of fleet numbers surviving into the next person's session is a straightforward data leak.
There is a permissions case underneath both. If someone's access to a depot is revoked, cached answers containing that depot's numbers must not keep rendering. Answers resolve against current permissions at render time rather than being stored as finished strings.
Other concepts we set aside
Chat as the home screen. Replacing the dashboard with an input box. Experienced users regressed immediately, and for less confident users a blank input was the most hostile empty state we had ever put in front of anyone. People do not know what a system can do until it shows them.
Free text only, with no suggested prompts. We wanted to avoid training wheels. Most first attempts returned nothing useful and most people did not try again. Suggested starters went back in, organised by job rather than by feature: Costs, Uptime, Drivers, Compliance.
A mascot with personality. Tested fine in isolation and fell apart in context. This product tells you a truck has broken down three hundred kilometres from anywhere. A cheerful character delivering that read as unserious. Personality is a liability when the content is bad news.
An assistant that could act. A copilot that could create maintenance tickets, reassign drivers and schedule service. Ops managers wanted confirmation on every action, which made it slower than the existing UI, and their reasoning was sound. If the assistant books the wrong service slot, the vendor still bills them. The autonomy we were designing was the part nobody wanted. It became principle 7.
Proactive alerts from the assistant. Deferred rather than rejected. We already had an alerting system and a real alert fatigue problem, and a second uninvited voice would have made it worse.
Charts generated inside the reply. They looked great and travelled badly. People screenshotted them and forwarded them, stripped of date range and vehicle scope, then argued about the number in a group chat. Context did not survive the screenshot. Visualisation moved into the handoff.
Where we landed
One assistant, one history, entered from a fixed spot in the top bar rather than a bubble floating over the dashboard.
Opens as a dismissible panel on the right, beside the content and never over it. The user does not leave the screen they were working on.
Scope shown as editable chips per message, so ambiguity is resolved by correction rather than by the assistant asking clarifying questions.
Threads persist and are searchable, individual answers visibly age, and history is scoped to the account and cleared on logout.
Answers follow one fixed anatomy, and every answer can push a filtered view into the dashboard
What we still do not know
Whether the recurring questions are narrow enough that five well placed buttons would outperform any of this. If most demand collapses onto a handful of repeated questions, the honest first version may not need a language model at all. That is the next thing worth testing, and it should be tested before anything gets built.
Other Projects
Fleet Monitoring System
We designed a platform that consolidated competitor tracking, market share trends, and sales performance into one workspace, giving teams a clear read on where they were winning, where they were losing ground, and why.
Password Protected
Video Telematics System
Designed an intelligent video telematics experience that leverages in-cabin and on-road smart dashcams to identify unsafe driving events, deliver timely interventions, and help fleets build safer driving habits.
Password Protected
