{props.sub}
: null}{props.intro}
: null}{props.after}
: null}{m.does}
{s.p}
Designing an assistant that knows when to act, and when to stay out of the way.
The broader MySubaru redesign established a strong opportunity for preemptive guidance: owners responded well when the system surfaced useful context before they knew where to look. Making a product proactive, though, creates a new problem. More assistance is not always better.
The design challenge was not: how do we add AI to MySubaru? It was: when should an intelligent vehicle companion interrupt,{" "} ask permission, or{" "} remain silent?
{f.p}
{m.p}
Proactivity was welcomed when it helped people prepare a trip, resolve a maintenance issue, schedule an action, or coordinate during travel. In each of those moments the owner still had a decision ahead of them, and the system was reducing the cost of making it.
The same level of intervention became less welcome once the trip was complete. Nothing about the assistant changed: only the moment did. The experience had crossed from assistance into intrusion.
Over 80% of participants said they would use the service again and would be willing to pay for it. That number says the concept is wanted. It does not say how the assistant should behave, and the behavioral finding underneath it mattered more: an intelligent assistant should not maximize automation. It should calibrate its right to intervene.
Calibrated proactivity: the system earns its right to intervene from the moment it is in, not from the capability it happens to have.
The rule underneath: high consequence, interrupt. Potential value, invite. Low urgency or retrospective value, wait. This is a system governing autonomous behavior, not a set of three AI features that happened to ship together.
{m.p}
Shape, not scores. The direction of each line and the position of the turning point are what the per-moment session ratings established. The underlying rating values are not published here, and the vertical axis carries no scale.
The turning point sits at arrival. Everything before it is assistance: the owner still has a decision ahead of them and the system reduces its cost. Everything after it competes with the moment the owner is actually in. That is the boundary the three modes are built around.
of participants said they would use the tested service again and would be willing to pay for it.
Reported willingness inside a simulation study, from participants who had just experienced the concept. It establishes appetite for an intelligent vehicle companion. It is not a purchase, a conversion rate, or a claim about the shipped MySubaru product.
{s[1]}
The point of the list is what is missing from it. There is no continuously refreshed vehicle model, and no behavior in the concept depends on one. Prediction was the implementation. Preparedness was the value.
A live model can justify acting on what it currently observes. An inference cannot. Confidence therefore sits between the signal and the mode: the less certain the read, the further the system moves down the interruption scale, from interrupt to invite to wait.
Scheduling a service appointment is reversible and low cost if the inference was wrong. Interrupting a moment is not: attention taken cannot be given back. Reversibility is what separates the behaviors the assistant may perform from the behaviors it must propose.
This is the factor the study surfaced and the one an architecture diagram would never have produced. It is also cheap to compute from signals the system already has, which is why it survived the reframe intact while real-time prediction did not.
This revision is the part of the case I would defend hardest. The easy responses were to keep the ambitious architecture in the deck and let it fail later, or to drop the concept because its first implementation was unaffordable. Separating the value from the mechanism was what let the concept keep going.
One build carries all three behaviors on purpose. If the modes lived in separate demos, the model would look like three features. Sitting in the same app, the difference between them is visibly a difference in permission: what each one is willing to cost the owner.
The maintenance assistant earns attention by responding to a condition with meaningful safety consequences. Extreme low tire pressure, before tomorrow morning's trip, with heavy rain forecast. The experience moves from alert, to explanation, to recommended action, to service resolution: the interruption is only defensible if it ends somewhere.
Every screen after the first exists to repay the interruption. The design test for this mode is simple: if the owner has to go and work out what to do next, the assistant should not have interrupted them.
The trip assistant recognizes an opportunity but does not assume permission. In the build it appears at the top of Trip Planning, telling the owner the Riverside trip starts tomorrow at 9:00 AM and everything is mapped, then asking whether to start it now. The owner can accept the help or leave it, without losing control of the experience.
{v.p}
The card in this build offers the accept path and a secondary route into managing the trip, and it can be hidden. The genuine Maybe later, a deferral with its own behavior that keeps the opportunity visible and does not re-ask, is specified in the model and is the interaction this mode exists to protect. Calling it out honestly matters more than pretending the build already ships it: a decorative secondary button is precisely the failure this mode was designed against.
Memory demonstrates the opposite side of the system. The assistant can create value after the journey without demanding attention at the moment the owner is most likely to want the product to disappear. In the build, the completed Maine trip has already resolved into a summary: three destinations, 950 miles, total cost, average efficiency. Nothing announces it. It is simply there when the owner comes back.
This is the mode that proves the model is not simply an argument for more automation. A system that only knew how to be helpful would have pushed the summary the moment the trip ended, and that is exactly where the study said the experience crossed into intrusion.
The presentation build of the assistant concept. Externally hosted, so it is linked rather than embedded here.
of participants indicated they would use the tested service again and would be willing to pay for it.
interruption rights, decided by consequence and moment: interrupt, invite, wait.
factors the system weighs before it decides which mode answers a moment.
Use intelligence to reduce effort and uncertainty, while preserving a clear boundary around user attention and control.
The goal is not to defend the most advanced architecture in the deck. It is to keep the value intact when technical reality changes. Real-time prediction was unaffordable. Confidence, reassurance, timely help, and fewer decisions under stress were not, once I stopped treating them as properties of the architecture.
A feature test would have returned a preference. Running one arc twice, and rating each moment inside it, returned a rule. When the design question is about initiative, timing, or attention, the study has to have time in it.
This assistant is a concept validated in a simulation study and prototyped as a working app state. It is not a shipped MySubaru feature, and it was not launched to owners. The retention, enrollment, and usage numbers reported in the MySubaru cases come from the staged rollout of the redesign and the onboarding work: none of them are attributable to this assistant, and this case makes no claim on them.
MySubaru Experience Redesign: the vehicle, trip, service, and guidance system that made this assistant possible.
That case covers the homepage, the information architecture, and the retention work this concept sits on top of. Open it from All Work, or from the case paging at the foot of this page.