Google Daydream
Turning emerging tech into product reality across Google
I joined Google in 2017, when a wave of new tech was unlocking product possibilities that simply didn't exist before. Computer vision was getting more and more competent, and mobile phones could track and recognize the world. AR had just become reliable on normal phones. My job was to work with other designers and prototypers to determine how these new technologies could drive more value for products across Google.
I was the AR and VR specialist on a small team built to answer exactly that. We embedded with product groups across Google to find where these technologies created real value, and where they were just technology for its own sake. My role was equal parts designer and prototyper, building the working proof that told us whether an idea actually had legs.
Ensuring users come first in R&D
Finding the user value in emerging tech
Our team operated like an internal studio for emerging technology. We would partner with product groups and ask, could AR do something useful here? What about computer vision? What about AI translation?
Our process always started with a large design-led brainstorm where we brought everyone in the product group together, and guided the room toward ideas we all thought we could invest in.
We then took the rough sketches and sticky notes and turned them into designs and prototypes that reflected the strongest user-value propositions, exploring how the next generation of technology could come to life inside flagship products like Waymo, Maps, Lens, and more.
Making the new experiences real, tightly coupled to user needs, was the secret sauce we used to ensure that Google products had access to cutting-edge tech - but not for its own sake, for the users'.
Making it real to build conviction
If the team had a superpower, it was building prototypes fast. We treated prototypes the way most teams treat sketches: the quickest way to find out if an idea was any good. A spatial concept can sound great in a meeting and fall apart the moment it's in your hands, so we got to something working as early as possible and put it in front of people constantly.
That meant design and engineering moving as one. On an AR feature, what's technically possible and what feels right are the same conversation, so we ran them together instead of handing work back and forth. A lot of the talks I gave were really about this method, because it turned out to be the transferable part: a repeatable way to find product fit for technology nobody had patterns for yet.
Bringing developers along
Teaching a platform what good AR feels like
The understanding we built embedding with Google's product teams also helped us deliver insights to the ARCore team. We helped provide feedback on what to give developers, how to frame it, and which of their challenges to solve first.
Developers needed more than an SDK. They needed to know what good mobile AR actually looked like in practice.
The hard problems were behavioral. People have no muscle memory for moving a phone as an input device; they default to touch, so every pattern had to teach a brand-new behavior in seconds. A working sample does that in a way that goes beyond documentation - but it also gives devs something easy to "copy paste" for common problems so they can focus on what makes their app amazing without having to rediscover solutions to common patterns such as object placement.
Designing for when the model is wrong
Teaching the camera to shop
Google Lens was applied computer vision before the LLM era, and it taught me the lesson that now defines my approach to AI product design: the model will be wrong, and the product has to be useful anyway.
Lens brought us in to help unlock new thinking and prototype explorations. One example is with shopping - an exact product match is incredibly difficult to achieve, but the user goal is most likely to find similar products as opposed to that exact product. When the model can't pin down your exact lamp, a shelf of lamps in the same style is still a great answer. We hunted for use cases shaped like that, where the failure mode is itself a feature. Design the near miss first.
AR as a feature
Two years across the company produced a clear playbook: AR succeeds as a feature, not a destination. The camera has to earn its place, the interaction has to borrow heavily from patterns people are used to, and the failure modes deserve as much design as the happy path.