Keurig Smart Brewers

Keurig’s newest smart brewers were capable machines wrapped in an experience that hadn’t kept up. The hardware could do far more than the interface let on, so the real question was never “make it prettier.” It was “why aren’t owners using what they already paid for?” I owned that answer across two surfaces at once: the phone in your hand and the panel on the machine.

My bet was to treat the app and the brewer’s screen as one connected system, not two products, and to protect the everyday path (wake, choose, brew) ahead of feature breadth. Every interaction had to answer three questions on sight: what’s happening, what to do next, and what just changed.

The experience was more complicated than the coffee it made. Controls weren’t intuitive, feedback was unclear, and simple tasks took more steps than they should. That friction landed at exactly the wrong moment, when someone just wanted a cup of coffee, and it quietly undercut the whole reason to pay for a “smart” brewer in the first place.

Research narrowed it to three recurring failures: people couldn’t tell what state the machine was in, got no clear confirmation when something worked, and had to relearn the controls almost every time. Those three became the bar the redesign had to clear.

I drove the redesign across a cross-functional team, owning the calls and keeping everyone pointed at the same outcome:

I started by listening. We interviewed 15 owners to find where the experience actually broke down, and the pattern held: fewer steps, clearer feedback, controls that didn’t need a manual. I paired that with a competitive teardown of other smart brewers to see where the category had set expectations and where there was room to do better. That work turned a vague “make it better” brief into three problems we could measure against.

With the problems mapped, I made a deliberate scope call: win the everyday path (brew, choose a size, schedule) before anything else. Instead of adding features, we cut steps and made state and feedback impossible to miss. Keeping the flows on the existing component library was a product decision too: it let the work ship without rebuilding the system, so the win landed sooner.

I built high-fidelity, interactive prototypes to feel the flows in motion: how the brewer wakes, how a brew progresses, how it tells you it’s done. They surfaced hardware constraints early instead of at launch. The on-device screen was the hardest tradeoff, since it has to say a lot with very little, so every light and label had to earn its place. Prototyping those states let us settle arguments with something real instead of opinions.

Finally I extended the experience to mobile, holding the app and the brewer to one visual language and one mental model. Moving between your phone and the machine should feel like the same product, and that was the point. The technology gets out of the way of a good cup of coffee, whichever screen you’re on.

The payoff was a brewing experience that feels obvious instead of fiddly: clear controls, honest feedback, and one consistent product from the app to the brewer itself. In testing and after launch, owners moved through brewing tasks faster and kept telling us how much easier the machine had become to use. It shipped on schedule and hit its satisfaction goals.

The lasting lesson was a product one, not a visual one. The fastest way to make a “smart” device feel smart is to remove steps and remove doubt, not to add features. Optimize the path people actually take, and the technology finally gets out of the way.