Case study · Designing for AI · Microsoft
Bulk drive classification, powered by machine learning.
An ML feature that turned a chore users did one drive at a time into a reviewable bulk action, and lifted the metric MileIQ runs on.
I led design end to end for a feature that uses machine learning to recommend how users classify their drives, turning a chore done one drive at a time into a reviewable bulk action, and lifted MileIQ's core engagement metric, the share of drives users actually classify, by 10–20 percentage points.
Microsoft filed a patent on the ML model behind the feature. As the only designer on the team, I owned the work from problem framing through final visual design.
The problem
Classifying drives is the one thing MileIQ exists to do.
Every drive the app logs has to be marked Business or Personal, because that's what becomes a tax deduction, and it was exactly the thing users were failing to keep up with.
Across user interviews, surveys, feedback, and CX tickets, classification issues were the single biggest problem by volume. Two causes dominated.
Too manual. There were simply too many drives to classify one at a time.
Accuracy anxiety. Without classifying right away, users couldn't recall a drive's context later, so they guessed or skipped it.
For the user, an unclassified drive is money left on the table, up to $6,200/year in deductions on a $59.99/year subscription. For the business, classification is the product's value, because a user who stops classifying is a user about to churn.
- Daily drives: 8–10 · 79% Business / 16% Personal / 5% unclassified
- Archetype: construction workers, realtors, freelancers
- Classifies: weekly, monthly, or once a year
Make classification less manual, more efficient, and more accurate, at the same time.
My role
Sole designer,
end to end.
I worked as Product Design Lead over six weeks on a team of one PM, one UX writer, one data scientist, and four engineers. I owned design from problem framing through final visual work, and led the design reviews that kept the team aligned on each decision.
- Practices: problem framing, design strategy, user research, design reviews
- Deliverables: user flows, interaction design, wireframes, prototype, visual design
- Team: 1 PM, 1 UX writer, 1 data scientist, 4 engineers
Because I was the only designer, every design decision in this case study was mine, so there's no team attribution to untangle.
Key decisions
Three calls that shaped the feature.
ML recommendations, not more automation
MileIQ already had automation, rules that classified repeated drives (a daily commute, say) the same way each time. It wasn't moving the rate enough, because rules only catch predictable patterns and real driving isn't fully predictable. Rather than add more rules, I reframed the problem from "automate more" to "make the app intelligent", using the user's own classification history to recommend classifications for everything else, applied in bulk.
A recommendation can be wrong in a way a deterministic rule can't. That made trust, not accuracy alone, the central design problem of the project.
A list, not buckets, cards, or tabs
I explored several ways to present recommendations (grouped buckets, a session summary, tabs, and a plain list) and tested them with users. Buckets and cards looked cleaner but hid the individual drives behind a summary, and the whole point was for users to review the model's guesses, not accept them blind. Tabs fragmented the set across views, which broke the bulk action. The list won because it kept every drive scannable and individually correctable while still letting one action classify them all. Readable enough to trust, granular enough to fix.
I capped each session at 10 drives to keep the list scannable, so a user with 40 unclassified drives moves through four sessions. I took the friction in exchange for a list that never became an overwhelming wall (see reflection).
A Floating Action Button as the entry point
I put the feature behind a FAB rather than threading it into the existing feed. A persistent, consistent entry point meant users always knew where recommendations lived, kept the interaction linear and easy, and let me introduce an entirely new ML feature without disrupting the classification flow users already knew.
The FAB stays on screen even when there are no recommendations to show. I judged a predictable home users could always find worth more than a perfectly contextual button.
Designing for trust
An ML recommendation is only useful if the user believes it.
The harder half of this project wasn't the flow. It was making an imperfect, probabilistic feature feel trustworthy while keeping the user in control. Three moves did that work.
1 Set expectations about the ML itself
I framed the feature around a learning curve, not a promise of perfection. The model starts in a learning period and builds confidence as the user classifies more. That reframes an early wrong guess from "this is broken" into "this is still learning," and makes the user's corrections feel like training the system rather than cleaning up after it.
2 Keep the user in control
Every recommendation is reviewable and editable before it's applied. The user is never classified by the machine or made to classify for it. They review its suggestions, correct what's off, and commit in bulk. Control is what makes delegation feel safe.
3 Make the value legible
Working with our UX writer, I tied the language to payoff and progress. "Review, Edit and Classify" sets the task, "10 Drives Classified: that's a $90.23 value" makes the benefit concrete the instant it lands, and a completion state closes the loop.
I also reused MileIQ's existing star icon, long used in the app to mark task completion, so a brand new feature read as native rather than bolted on. The recommendation mark folds the classified drives into the star.
Final design
Readable, actionable, clear.
From the feed's star entry point, through the intro, the reviewable list, and a completion state that reports the value just unlocked.
Outcome
The feature moved the metric that matters most to MileIQ, the share of drives users classify, by roughly 10–20 percentage points on the product's core engagement number. Users also reported more confidence in their classifications, directly answering the accuracy anxiety the research had surfaced.
I left before the numbers fully settled, so I hold these as directional rather than exact, but the trend was unambiguous. More drives classified, more accurately, with far less manual effort.
Why it mattered
Classification is the one function the whole product depends on, and every unclassified drive is value the user paid for and didn't capture. Lifting the rate protects retention and the renewal case. That’s design tied directly to the business, not just the interface.
Microsoft Patent Award
Microsoft filed a patent on the ML model behind the feature, and the team, including me as its product designer, received the Microsoft Patent Award. The patent covers the model itself. My contribution was the experience it ships inside. How users review and correct, the patterns that build trust and control, and the bulk classification flow.
What I'd do differently
Capping sessions at 10 drives was the right call for launch but the first thing I'd revisit. For users with large backlogs it turns one decision into several sessions. I'd test a progressively loading list or an adjustable batch size, keeping the list scannable without forcing repetition.