The wave is real. So is the problem.
Since Meta Ray-Ban went properly mainstream and Snap opened developer access to the 5th generation Spectacles, the number of smart glasses demos has exploded. There are hundreds of them now: real-time translation, ambient note-taking, social feeds, AR menus, live sports overlays, try-on experiences, you name it. Most of them work. Most of them are technically impressive. And most of them get put down after about thirty seconds of use because there is no reason to keep going.
This is the pattern: a developer discovers a new platform, reads the SDK docs, ships something that demonstrates the hardware's capabilities, posts it online, gets traction, and moves on. The demo looks great. The use case is nowhere.
The rush is real and I understand it. When a new hardware platform opens up, there is a first-mover window and it feels important to be visible. That is true. But the developers who will define what smart glasses actually become are not the ones who shipped the quickest demo. They are the ones who asked a harder question before they opened the editor.
The ten-second test
Here is a test I run on every brief before committing to a build. It takes about two minutes and it kills more ideas than any technical feasibility review.
Describe what the user is doing ten seconds before they interact with your glasses experience. Now describe what they are doing ten seconds after.
If you can answer both halves specifically (not "they are using their phone" or "they are out in the world," but a concrete behaviour in a concrete moment) you probably have a real use case. If you find yourself reaching for vague generalities, you do not have a use case yet. You have a capability. A feature. A demo.
The reason this test works is that smart glasses are ambient devices. They live on someone's face throughout their day. They are not picked up and put down the way a phone is. That means an experience on smart glasses has to attach to real behaviour that already exists. It cannot invent a new behaviour from scratch. Nobody is going to put on glasses, open your branded AR experience, and stand somewhere waiting for it to do something interesting. They are going to be doing something else when your experience needs to be useful.
The ten-second test in practice
Ambient does not mean always-on
There is a persistent misconception about smart glasses: that because they live on your face, they should be delivering information constantly. That the value comes from the stream. This is wrong, and it is the thinking behind most of the failed notification-layer apps.
Smart glasses are ambient in the sense that they are present throughout your day. They are not ambient in the sense that they should be competing with your field of vision all the time. The human visual system is not designed for constant overlaid information. It is exhausting at ten minutes. It becomes genuinely unpleasant after twenty.
Experiences designed for phone attention patterns feel oppressive at eye level. On a phone, you choose to look. On glasses, the information is where you are already looking. That is a fundamentally different relationship, and it demands a fundamentally different approach to information density and timing.
The best smart glasses experiences are the ones that feel like they appeared exactly when they were needed and disappeared just as cleanly. Not a stream. A signal. One clear thing at the right moment, and then gone.
Where use cases actually hold up
After building on smart glasses platforms and looking at what has actually held user attention past the demo phase, three categories consistently produce real use cases.
Navigation and wayfinding
Contextual, hands-free, and anchored to a behaviour that already exists. The user is moving through space. The experience reduces friction in that movement. Eyes stay on the world. Turn prompts, proximity alerts, and contextual points of interest all fit this pattern.
Events and live experiences
A shared spatial moment where the glasses add a layer to something already happening. A concert, a sports event, an installation, a brand activation. The user is already present and already engaged. The experience augments what they are looking at, not what they are doing on a screen.
Industrial and professional
Both hands are occupied. Eyes need to stay on the task. A technician following a repair sequence, a surgeon reviewing a scan, a warehouse worker checking inventory. The glasses are not competing with the phone. They are replacing a workflow that would otherwise require stopping work to look something up.
What these three have in common is that the form factor is doing actual work. The glasses are not delivering information that a phone could deliver equally well. They are delivering it in a way that nothing else can: because the hands are busy, because the eyes need to stay on the world, or because the information has to be spatially located to make sense.
Where they fail constantly
Three categories where I see the same mistakes repeated, with different SDKs and different logos.
Social sharing
The phone does this better. Significantly better. A phone has a better camera, a better display for reviewing what you captured, a faster path to sharing it, and it does not require the person you are with to watch you tilt your head to frame a shot. Smart glasses cameras have a role in hands-free capture for specific activities. Social sharing as a primary use case is not it.
Notification layers
Nobody wants an inbox on their eye. This has been tested repeatedly and the result is always the same: users feel surveilled by their own device. Notifications on glasses feel intrusive in a way that notifications on a watch or a phone do not, because they interrupt the visual field rather than a peripheral glance. The use cases that work here are extremely narrow: a single-type alert (your next turn, your food is ready, your contact has arrived) in a context where the user cannot easily check their phone. Everything else belongs on the wrist or the pocket.
Generic brand AR
The brief is usually something like: "We want users to experience our brand in augmented reality." The output is a 3D logo or product that floats in space when you look at a trigger. It is visually interesting for about eight seconds. Then there is nothing to do. There is no behaviour attached to it. There is no moment in the user's day where they would choose to do this over anything else they could be doing. The technology is real. The use case is not.
Start with the moment, not the capability
Most developers building for smart glasses right now are asking: what can I build with this? That is the wrong question. Or rather, it is the second question. The first question is: what is the moment this solves something that nothing else solves?
That reframe changes everything. It means you are not starting from capabilities and working toward a use case. You are starting from a real human moment: a gap, a friction, a behaviour that exists but is harder than it needs to be. Then you ask whether smart glasses are the right tool to address it.
Sometimes the answer is no. Sometimes the phone is the right answer, or voice, or a dedicated device. Arriving at that answer before you spend eight weeks on an SDK is not failure. It is the job.
What building noodle taught me about constraints
noodle was a project I built for Snap Spectacles at MIT Reality Hack 2026. It won the Snap category. The brief was to create a mixed reality experience that turned your physical space into a generative AI workbench, using only hands and voice, with no prior 3D experience required. Users could go from physical sketch to 3D object in real space through a node-based AI workflow.
The use case was clear from the start: a person who has an idea they want to see in three dimensions, who is standing in a physical space, and whose hands are the primary creative tool. That constraint shaped every design decision. It told us what the experience needed to do, and more importantly, what it did not need to do.
The spatial moment that made it work: you see something in the world, you interact with it through your hands and voice, and you see a 3D version of it appear in the space around you without ever looking at a screen. Eyes stay on the world. Hands stay in the work. That is the use case. Everything else in the build was in service of that moment.
When we had features that did not fit that moment, we removed them. Not because the technology couldn't support them, but because they diluted the thing the experience was actually for. That sharpness came directly from having a clear use case before we started building. See the full build at the noodle case study.
The developers who get this right
The studios and developers who get smart glasses right will be the ones who spent more time on use case research than on the SDK. Not because the SDK is simple (it is not), but because technical fluency without use case clarity produces impressive demos and nothing else.
The technology is ready. The hardware is capable. The platforms are open. What is not ready is the thinking. The discipline to ask the harder question before the easier one. The willingness to kill an idea because it passes the technical test but fails the human one.
That is the work. And the developers who do it first will not just ship better products. They will define what these devices are actually for.
Frequently asked questions
How do you know if your smart glasses idea has a real use case?
Run the ten-second test. Describe what the user is doing ten seconds before they interact with your experience. Then describe what they are doing ten seconds after. If you cannot answer both halves clearly, you do not have a use case yet. You have a capability. A real use case slots into a moment of actual human behaviour. It does not create a new behaviour from scratch. Navigation prompts work because the user is already walking and already needs to know where to turn. That is a real use case. A branded AR filter someone opens randomly is not.
What makes a smart glasses experience feel useful vs. gimmicky?
One question: does it solve something that nothing else solves as well? If the user could reach for their phone and get the same result in the same time, the glasses are not earning their place. Useful experiences are ones where the glasses form factor is doing real work: both hands are occupied, the eyes need to stay on the world, or the information has to appear in context for it to make sense. Gimmicky experiences borrow the form factor for aesthetics. They feel exciting in a thirty-second demo and pointless after that.
Should brands build for Snap Spectacles or Meta Ray-Ban first?
It depends on what the experience needs to do. If you need visual spatial output: overlays, anchored 3D content, shared spatial moments at events, Snap Spectacles is the right starting point. The dev kit is available, the SDK is mature, and the display is capable. If your use case is ambient and conversational (a shopping assistant, a hands-free guide, something voice-led), Meta Ray-Ban Gen 2 is worth exploring first. The honest answer is to define the use case before you pick the platform. The platform should follow the behaviour, not the other way around.
How long does it take to build a smart glasses experience?
A focused Snap Spectacles experience with clear scope takes four to eight weeks from brief to testable build. That includes use case definition, spatial UX design, development in Lens Studio, and on-device testing. The variable that blows timelines is not the SDK: it is undefined use cases. When the scope is clear and the use case is sharp, the build is fast. When the team is still figuring out what the experience should do mid-build, you are looking at double that or more. The investment in use case research at the start returns its cost in build time saved.