{props.sub}
: null}{props.from}
{props.to}
MySubaru already performed its best known job well. Owners could start, lock, unlock, and locate their vehicle remotely, and they did. That utility created strong episodic value: real, repeatable, and genuinely sticky.
The work arrived as an engagement problem: usage was concentrated in a handful of commands, and the team wanted more of it. The available move was to optimize engagement inside the existing product structure.
I proposed a broader transformation instead: move MySubaru from remote control to vehicle ownership companion. The question I wanted the team to answer was what would make an owner open the app when they are not actively trying to unlock, locate, or start the car.
These numbers followed a staged product rollout rather than a controlled holdout. The Outcome chapter states exactly what they can and cannot be attributed to.
Two patterns emerged. Owners wanted a more personalized, integrated system that could save time and money across driving, maintenance, and travel. And they wanted help before a problem became work: alerts and recommendations that surfaced the relevant action without requiring them to know where to look.
I want one place that handles my service, billing, and trips, not five logins.
It should already know my car and stop making me re enter everything.
Tell me before something is wrong, not after I am stranded.
A nudge for the right service at the right time would actually help.
Low expectations were not a low ceiling. The category had trained customers to expect very little, so an expectations survey was measuring the market's history rather than the product's potential.
Participants described what is due, why it matters, what it may cost, when to schedule it, and where to go. The unit of value was a decision they could act on, not a record they could look up.
A less expected answer. People were not asking Subaru to rebuild Google Maps. They wanted vehicle-specific fuel economy, miles driven, estimated travel cost, vehicle condition, and useful stops chosen because of the car itself.
I positioned trip planning around those signals rather than around navigation itself. The strategy became a sentence the team could apply without me in the room: compete where connected-vehicle data makes the experience meaningfully different, and integrate rather than rebuild everywhere else.
Task click-through, completion time, perceived stress, perceived safety, and perceived control. Each emotional claim was tied to something a study could observe, so tone and reassurance could be evaluated as product behavior rather than defended as taste.
Increase engagement by making the ownership app more{" "} personalized,{" "} anticipatory, and{" "} emotionally supportive, so drivers feel safer, more certain, less stressed, and more efficient?
{p.p}
Breadth of discovery. More of the system is visible early, which helps owners find capabilities they never knew existed, and asks them to scan more at every level.
Depth of focus. Less breadth at each level and a cleaner decision, at the cost of pushing capability one tap further from the owner.
That tradeoff forced a choice between discoverability and focus. I reviewed the structures with the product owner and PMs rather than resolving them inside design, because information architecture is also a statement of product strategy: what an organization makes easy to find reveals what it believes customers should value.
The redesign treats the physical key as the mental model for the digital one. It combines vehicle status, customizable remote actions, prioritized alerts, and direct next steps in a single object the owner already understands.
Remote commands remain highly accessible, because they are a proven source of stickiness and the redesign was never an argument against them. They now sit inside a broader model of ownership rather than defining the entire product.
I created the stacked pattern with an explicit severity hierarchy so critical vehicle conditions do not compete visually with routine information. A flat list gives a service reminder the same weight as a safety issue. The stack lets one card own the moment while keeping the others countable and reachable.
Card priority order was set by user testing, not by internal preference.
{p.p}
{r.p}
Both arrangements, running side by side. They are the same application with the same commands and the same customization behavior: only the arrangement of the command set changes, which is what makes the recognition difference attributable to structure rather than to content. Each one demonstrates itself; hover to take over.
Some participants saw the contextual message, did not select it, and still reached the event more quickly. The card was doing more than providing a shortcut. It was telling the owner that the capability existed, which changed how they read the rest of the interface.
Each dimension had a winner, but no single tested version was strongest on all three. Working with our copywriter, I combined the strongest clarity and tone characteristics into one shared voice: supportive, reassuring, warm.
Entering a screen did not necessarily trigger a new vehicle-data fetch. The interface had no way of expressing the difference between a state it had just confirmed and one it had cached, so it rendered both with identical certainty.
The fastest fix was to soften the copy: your door may be open. That removes the complaint by removing the claim, and it costs nothing to implement.
The better experience required fresher state, and fresher state meant more vehicle-data calls. At Subaru's scale, vehicle-data refresh behavior created an impact on the order of five million dollars.
Honesty and frequency are different problems. A timestamp makes stale data acceptable without fetching anything, which removes the pressure to poll. An explicit refresh moves the remaining fetches to the moments an owner actually cares, and consolidating surfaces stops the same state being requested three times in one session.
The argument that ultimately landed was not simply that the design was better. It was better design at a lower cost per active user.
All three put a visible spinner where the owner is already looking, so a refresh becomes something that happened rather than something that may have happened. We shipped the two that an owner performs deliberately and left the gesture out, because a pull that fires on every accidental over-scroll is a fetch we cannot attribute to intent.
The denser end of the model. One summary answers the whole question of how the car is, the top-down illustration puts the open windows and the affected tires on the vehicle, and every value carries its own last-updated time. Information honesty went up while the number of data calls went down.
The prediction surface is also where this chapter meets the assistant work: when continuously modelled real-time vehicle data was priced out, the value it was carrying had to be rebuilt from signals we already had. That reframing is the AI Driving Assistant case.
A complaint about wrong data arrived as an engineering ticket. Treating it as an interface problem about freshness, hierarchy, and latency is what turned it into a design decision with a business case, and the business case is what made it possible to argue for the more honest experience rather than the cheaper apology.
{n.p}
There is no live vehicle connection, so status, mileage, tire pressures, trip costs, and events are fixed sample data. Refresh, alerts, and confirmations simulate latency rather than performing real calls. Navigation, command customization with drag and save, mode switching, the alert and diagnostics path, the trip plan, and the service booking flow are all real.
Subscription and activation belong to the Onboarding case, not to this one, so they are not in this set. The retailer tools, the contactless checkout, and the showroom kiosk live there for the same reason: they are the enrollment story, and this page is the ownership story.
{props.children}
Notable monthly year-over-year increases: Mar +93.6K, Oct +92.6K, Nov +124.2K, Dec +145.1K. The largest gains land in Q4, especially November and December.
Average daily returning unique visitors grew from approximately 97,600 in 2024 to 149,800 in 2025: roughly 52,000 additional returning owners per day.
Returning visitors are the retention signal this case was built to move: an owner who comes back is an owner who found a reason to.
These results followed a staged product rollout rather than a clean experimental holdout. They are evidence of product and business movement associated with the redesign, not proof that a single interface change caused the entire increase. Three of the four figures are distinct measures and are worth keeping distinct: 40.6% is year-end active usage growth, comparing November to December 2024 against the same window in 2025. The 53.4% figure is average daily returning unique visitors. The move from 399.8K to 562.1K is total daily unique visitors, returning and new together.
Returning unique visitors equals total unique visitors minus new visitors. The annual figure is the mean of the twelve monthly averages.