How to brief a smart glasses developer:
what to have before the first call

A platform name is not a brief

The most common way a smart glasses brief arrives: "We want to do something on Snap Spectacles." Sometimes it is Meta Ray-Bans. Sometimes it is both, in the same sentence, as if they are interchangeable. There is usually a mood board attached, a campaign theme, and a timeline. What there almost never is: any description of what a person is actually doing when they put the glasses on.

That is the gap. A platform preference tells a developer which hardware you want to use. It says nothing about the experience you want to build, the person you are building it for, or the moment in which they encounter it. And without those three things, a developer cannot produce a proposal, let alone a build. The first call becomes a session of questions that the agency should have answered before picking up the phone.

This article is for brand teams and agencies who want to commission a smart glasses experience and want to arrive at that first call with something a developer can actually work with. It is written from the perspective of a studio that has received too many briefs that were not briefs, and lost time on both sides as a result.

What are the user's hands doing? That question unlocks the brief

Before you write anything else, answer this: what are the user's hands doing during this experience?

If the answer is "nothing, they are free": smart glasses have a genuine advantage. The hands-free nature of the format is a real benefit here. A technician following assembly instructions, a visitor navigating a venue, a shopper comparing products in-aisle: these are use cases where removing the phone from the equation changes the experience meaningfully.

If the answer is "they are on their phone": you may not need glasses at all. A phone-based AR experience will reach more people, cost less to build, and require no hardware logistics. Smart glasses are not the premium version of phone AR. They are a different medium, with different strengths. Using them when a phone does the job better is not ambitious. It is a hardware preference dressed up as a concept.

If the answer is genuinely unclear, that is also useful information. It means the use case has not been defined yet, and the first conversation with a developer should be about that, not about deliverables.

What a developer needs from you

To move from first call to proposal, a developer needs four things. Not a technical specification. Not a budget breakdown. Four things about a person in a place.

The physical context

Where is the user when they put the glasses on? A trade show booth, a retail floor, a music festival, a private event space, a professional workshop? The environment is not set dressing. It determines everything from anchoring strategy (can content be fixed to a physical location?) to lighting conditions (outdoor daylight is the hardest environment for AR overlays) to interaction model (a crowd of passers-by requires a completely different design from a fixed invited audience).

Do not say "events." Say "a 200-person product launch in a hotel ballroom, set up two hours before guests arrive, running across a four-hour window." The specificity is what makes the build possible.

The trigger

What makes the user reach for the glasses or activate the experience? Is it a QR code on a product? A staff member handing them the device? A designated activation zone they walk into? A voice command they already know? The trigger defines the onboarding moment, and onboarding on glasses is harder than onboarding on a phone. There is no tap to start. There is no familiar home screen. The first five seconds matter more than almost any other design decision, and they start with the trigger.

The desired outcome

What has changed for the user after the interaction? Not "they experienced something cool." What specifically? Did they learn how to use a product? Did they generate a shareable piece of content? Did they receive information that helped them make a decision? Did they complete a task they could not have done as easily without the glasses? The outcome is the thing the experience should be designed backwards from. Without it, a developer is building a demo, not an experience.

The constraint

How long does the session last? Is this a three-day event or an eight-week installation? Is the space public (any passerby could engage) or private (ticketed attendees, controlled access)? Is the device worn by one person at a time or passed between users? These constraints are not limitations to negotiate around. They are parameters that define the scope of the build, the interaction model, the content structure, and the hardware logistics. A developer who does not know them cannot give you an honest estimate.

What the developer will ask that agencies do not expect

Even with those four things in hand, there are questions a developer will ask in the first call that most agencies have not considered. They are worth thinking about before you get on the call.

Is the physical environment consistent or variable?

Anchored AR, where digital content is fixed to a real-world position, works very differently depending on whether the space is static or changes between uses. A branded pop-up built once and left in place for a week is anchored AR in a controlled environment: the developer can map the space precisely. A retail store or a real-world street is a changing environment: lighting shifts, objects move, the physical context you mapped yesterday is different today. These require different technical approaches and different expectations about reliability. Know which one you are describing before you brief for it.

What is the lighting situation?

Outdoor daylight is the hardest environment for optical AR overlays. On most current smart glasses hardware, bright direct sunlight reduces display visibility significantly. If your activation is outdoors, a developer needs to know that from the first conversation. The answer may not be "don't do it outside." It may be audio-first, it may be a shaded zone, it may be a different platform choice. But it cannot be discovered for the first time during an on-site test two days before launch.

Is there a fixed audience or a crowd of passers-by?

These require completely different interaction design. A fixed invited audience can be onboarded, can be given context in advance, and can be expected to spend five to fifteen minutes with the experience. A crowd of passers-by has seconds of attention, no prior context, and no patience for an onboarding flow. Designing for one and deploying to the other produces an experience that fails in ways that look like technology problems but are actually brief problems.

Platform guidance: what to brief for what

Platform selection should follow use case, not preference. Here is a practical guide to which platform suits which brief.

The mistake is to pick a platform and then search for a use case that fits it. Start with what the user needs to do, and the platform choice follows naturally. A developer will push back if your use case and your platform do not match. That pushback is not obstruction. It is the first useful thing a smart glasses studio can do for you.

Red flags in your own brief

Before you send the brief, read it and check for these. They are signs that the concept is not ready yet.

• The glasses are the hero of the campaign, not the experience they create. If the brief is primarily about being seen to use smart glasses technology, the experience will feel like a demonstration, not a destination. Audiences sense this immediately.
• The success metric is "people will see we have glasses tech." Visibility of technology is not a campaign outcome. Dwell time, conversion, content created, tasks completed: these are outcomes. Tech visibility is a vanity metric that a developer cannot design for.
• There is no answer to "why does this need to be on glasses and not a phone?" If the honest answer is "it doesn't," the brief needs to be rethought, not briefed. The best smart glasses experiences exist because glasses genuinely do something a phone cannot do in that context. Find that thing first.
• The brief describes what you want to build, not what the user will do. A brief full of design direction and no user journey is a spec without a concept. The developer will produce what you described, and it will feel like it was built inside out.

The six-point brief: what to have before the first call

You do not need a technical specification. You do not need a detailed production plan. You need a clear story about a person in a place doing something. These six points are the structure for that story.

The pool is small and selective

The developer pool for smart glasses experiences is small. The studios that have shipped real work on Snap Spectacles, Meta hardware, and comparable platforms can be counted in dozens, not hundreds. The good ones are selective about what they take on, not because of ego but because the work is technically demanding, the build windows are tight, and badly specified projects burn time that cannot be recovered.

Arriving with a clear brief is how you get the best work. Not because it makes you look organised, but because it signals that you understand what you are asking for, and that the time spent on a proposal will be time spent productively. Studios will always go further for a client who has done the thinking.

Read this, fill in the six points, and then get in touch. The first call will be a better conversation for both sides.

Frequently asked questions