In our ongoing AR careers series, we’re inviting members from the Spark AR team to share their career journeys and experiences, and to provide their perspective and advice for others exploring career paths in AR. Our latest series contributor is Austin McCasland from the Spark AR product design team.

Hey everyone, I’m Austin McCasland, and I’m a product designer and prototyper. My colleagues Stef and Dana recently shared their perspectives on user research careers and best practices — today, I wanted to share some thoughts and tips on AR prototyping from a product design perspective.

Prototyping effectively is hard. I’ve seen (and been a part of) many well-intentioned, but ultimately ineffective prototyping efforts — but I’ve also had the pleasure of seeing (and being a part of) quite a few successful ones as well. In this post, I’ll share some of the tools in my kit that you can use to help hone your prototyping practice for product efficacy, as well as some pitfalls to avoid. Let’s dig in!

Prototypes are product questions in disguise

Prototypes can push multiple types of products forward in many ways ranging from feature iteration on existing products, to understanding and developing never-before-seen concepts. Ultimately, however, it’s fair to say that we build prototypes to answer tricky product questions as fast as possible.

Every good prototype has a question at its core. These questions can be as general as “Will people find this idea valuable?”, or as concise as “Does changing one specific thing here help people better understand this flow?” If you can’t clearly define the question you are trying to answer with a prototype, you should reconsider if it’s worth making at all.

Additionally, even if your question is clear, you should critically assess if you can get the answers without the typically challenging and time-intensive process of prototyping. Product questions don’t always need a prototype to be answered; literature reviews, user experience research, concept testing, and even common sense, can help. You should critically evaluate whether the time and effort you’d put into prototyping would be worth it vs. other methods to answer the same line of inquiry.

Often, the answer is “Yes! We need to build something so we can see it, feel it, and really understand how it will work, and properly understand specific questions we have.” In these situations, prototypes are excellent tools and here are four initial tips you can apply:

Tip #1: Understand your product’s needs and choose your prototyping method accordingly

There’s a handful of questions you should ask yourself about your prototype based on the product’s stage in its life cycle.

• How fast do I need to complete this prototype?
• How broad / concise is the question my prototype will answer?
• Will this prototype address user value, design execution, or tech validation? Or some combination?
• What’s the minimum level of effort required to create something that can validate or invalidate the product hypothesis?

Questions like these will help you understand what type of prototyping methods you should choose, based on your approach. Often, I see prototypers who use a favorite tool by default for every project. I’m guilty of giddily diving into advanced computer vision prototypes leveraging ML models for AR in Unity, when having ‘pre-defined’ prototype moments would be just fine for testing (or probably even a storyboard!). Advanced tools are often well-suited to complex prototypes, but ultimately take longer than simpler methods. Don’t be afraid to branch out of your prototyping comfort zone in favor of lower fidelity methods. Or more simply put, don’t be a one-tool-wonder.

Prototypes come in many forms, ranging from paper prototypes, all the way up to fully functioning code-heavy prototypes that precisely convey the user experience. I’ve always liked this graphic, it captures the range of options nicely:

When deciding which type of prototype to create, you can usually let your prototype’s core question guide you. Simple prototyping methods are fast, but may provide less granular feedback, so are typically best for broad questions, concept valuation, and problem space discovery. Complex prototyping methods are slower, but can give you much more precise feedback and are good for interactions, interconnected systems, and usability.

Determine the right type of prototype for your product question, always asking if you could get the answer more quickly by doing something more simply.

Tip #2: Prototyping is about speed, so cut the right corners

You want to get a good answer to the question your prototype is asking as quickly as possible. The reason why you aren’t answering your question by building the full product right away is because doing so is expensive in time/resources; by minimizing the amount of time you spend getting an answer to your prototype’s question, you lower the cost of your investment if your prototype invalidates your hypothesis or reveals an ineffective approach.

This doesn’t mean you should create rough-around-the-edges prototypes by default, but you need to be judicious in how you spend your time creating them. Certain questions don’t need a high degree of prototyping polish. For example, if you are simply testing if a new flow will work, or wondering if a core feature concept is valuable to users, you may choose to err on the side of less polish.

On the other hand, certain questions may need a prototype with a high level of polish and complexity before you can answer them with confidence. If you are trying to understand usability, complex interconnected systems, or something that just can’t be replicated simply, it may be the case that the ‘minimum polish bar’ to answer your question requires you to create something highly refined.

The trick to effectively prototyping for speed is to ‘cut the right corners’ for your use case. Don’t worry about things like the cleanliness of your code unless it’s necessary for collaboration. Don’t worry about optimizations unless that’s part of what you’re testing. Don’t worry about edge cases unless they could easily disrupt the core user journey.

Always ask yourself if you really need to spend time on something, keeping in mind that you’re building a prototype, not a product.

A related pitfall, scope creep, can occur when we get excited about a new opportunity we’ve discovered while making a prototype and think “Wouldn’t it be even cooler if we just showed everyone this interesting new opportunity too?” It’s natural to get excited about the new product possibilities you uncover as you prototype, but you should avoid deviating too drastically from your original prototyping plan unless you have plenty of time.

Many prototyping projects lose momentum, fizzle, and fade (or get completed too late to matter) because a well-meaning, excited prototyper dove down too many rabbit holes. Avoiding scope creep takes discipline, but it pays dividends in terms of an efficient prototyping practice.

Tip #3: Prototype fidelity has diminishing returns

Most prototypes don’t need to be perfect to be effective. A serious factor of diminishing returns often looms over highly polished prototypes, as the last 20% of the polish can end up taking as much time as the first 80% of the core work. More often than not, it makes more sense to accept that you’ll deliver a prototype that isn’t fully polished but contains the important elements needed to clearly answer your product hypothesis. Be mindful any time you find yourself ‘polishing things up’, and be sure you’re not spending a disproportionate amount of time there for the value you’ll get.

On the flip side, there is a minimum bar of quality for every prototype; you don’t want to cut too many corners and neglect the overall refinement to the detriment of the project. Too rough a prototype will likely make the answer to your question unclear, or even worse may render the prototype unuseful as a tool to give your team conviction on product direction. I’ve seen many prototypes fail to drive impact due to too many debug menus, uncleaned developer settings, and inconsistent interface elements.

The key here is to hug the line for minimum polish as closely as possible. As people who pride ourselves on making exceptional things, that’s a big ask, which brings me to tip #4…

Tip #4: Don’t let your ego slow you down

Prototyping often takes special skills and special tools that are difficult to master. As a result, it’s easy to be proud of what a good ‘prototyper’ you are, and the complex and high quality things you can create. However, the point of a prototype is to answer questions as quickly as possible, not for you to prove how exceptional you are at your craft.

One of the keys to level up your prototyping is to avoid doing things just because you have the ability to do them. Always ask: “Is this portion of my prototype going to help me answer my question?"

Flexing your skills for their own sake, while gratifying, is one of the single most deadly ways to slow down a prototype. It’s likely that making a prototype amazing is important to you, but that doesn’t necessarily mean it’s important for the prototype to be amazing to function as a learning tool for your product.

When you are about to add ‘bells and whistles’, ‘generalize this functionality for further use in future projects’, ‘clean up edge cases’, or ‘go the extra mile’, critically assess if you are nerd sniping, and save those tasks for last. Only address them after all the other important pieces are in place (and only if there’s time).

Ultimately, prototypes hinge on questions

There’re many aspects to effectively prototyping, but most of them owe their lineage to the notion that you can bring something to life to answer a question. I hope you’ve found some of the advice above helpful and actionable for your own prototyping practice.

Our thanks to Austin for sharing his perspective today. If you would like to learn more about a career in AR/VR product design, please check out our career opportunities page.

Subscribe to the Meta Spark Blog