Published on <a href="https://blog.prototypr.io/i-ar-guinea-pigs-a34e85ce49d6?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Jeremiah Alexander 
<h4>Lessons Learned from the wiARframe Beta</h4>
If you happen to be one of the AR enthusiasts who perhaps after reading my previous article (<a href="https://blog.prototypr.io/effortless-ar-prototyping-d0d419e85eb">Effortless AR Prototyping</a>), signed up to the wiARframe Beta, then I owe you an apology! We gave you a buggy product, with no instructions, no help popups, no, not even a tooltip. If this caused you frustration and even some disappointment then we’re sorry, but rest assured it WAS intentional!
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*SJ_YPRVZge-YBUNYVapCUQ.jpeg">Original Photo by <a href="https://unsplash.com/photos/sNwnjxm8eTY?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Dan Dimmock</a> on <a href="https://unsplash.com/?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a>
If you’re a Marketing Guru, this is the point when you may start shaking your head in disapproval. Yes, I intentionally gave out access to a product with no onboarding, no email funnel, no obvious support (I even removed intercom integration at the last minute) and potentially lost some prospective customers in the process. In part you should blame <a href="https://medium.com/u/479830773d90">Hiten Shah</a>, as I was inspired by <a href="https://blog.usejournal.com/why-trello-failed-to-build-a-1-billion-business-e1579511d5dc">his article</a>, though perhaps not in the way he intended, he said:
<blockquote>“In SaaS, you don’t win by getting there first or having the best idea. You win by continually solving the problem better”</blockquote>
I internalized this as meaning that, in order to continually solve the problem better than anyone else, I need to endeavor to understand the problem better than anyone else. Accordingly, hiding behind too much well-developed onboarding might mask things that I had inherently misunderstood and thus designed poorly.
My team and I wanted to see how similar the experience of creating an AR Prototype was to existing design tools; what parts were simply intuitive and what parts would need instructions. The rest of the article details our key learnings and what we plan to do with them.
<h3>What We’ve Learnt So Far</h3>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WZ1kgbuY5A2twyOkT88tnA.png">Guinea Pig Journey Feelings
<h4>Mapping Two Dimensions to Three Dimensions is Hard</h4>
wiARframe has two core components: A web-based Editor for creating the prototypes and a mobile App for viewing them.
The Editor gives users a canvas representing a top-down view of the scene, where 3D objects can be arranged. Positioning is in 2D, with a shadow used to show elevation in the third dimension. Our endeavor was and still is to keep the web as simple as possible and hide the complexities associated with three dimensional design.
Where we failed, is that we don’t currently have a good enough correlation between what you create in the Editor and what you see when you launch the App. Consequently, users spend a lot of time flicking back and forth between the App and the Editor.
How we aim to address this is by experimenting with different 3D Perspective &amp; Isometric Views, to find a suitable combination that allows you to still easily layout your scene in the Editor but feel confident that it’ll appear exactly as you intended in the App.
In addition, we will aim for Real-Time synchronization between App and Editor, so when you do want to preview changes, you will be able to almost instantly.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dW2AVsZiF82EB4EJ7_Hy8g.png">wiARframe Scene Layout — Before and Mockup of a Possible After
<h4>Managing Non-Linear Interactions are Hard Too</h4>
What’s really exciting about AR is the ability to interact with multiple objects in a space in any order that you desire. Clickable web or mobile app prototypes do well at showing sequences of screens, but for AR you need to be able to demonstrate overlapping sequences for multiple objects.
In wiARframe, we implement something called a <a href="https://www.google.com.sg/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=3&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwimwpzFm6vXAhUSSI8KHflKBm0QFggsMAI&amp;url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFinite-state_machine&amp;usg=AOvVaw37sgMc1DzQ_H2PQ85qy_0J">Finite State Machine</a> to represent the various configurations an object can be in. This allows us to have an object that when tapped might change from a ‘normal’ state to a ‘focused’ state, where the focussed state increases its size and also positions it closer to the user. It’s an incredibly powerful system but it’s challenging to visualize both mentally and diagrammatically, and not something that was intuitive to our guinea pigs.
Our first step to fix this is to… simply add some instructions. This is just one of those concepts that needs a bit of explaining at first. Beyond that, we’re exploring an alternative implementation focusing on sets of changes, rather than complete state changes. And beyond that, we’re also thinking about effective ways to visualize states and interactions between objects — if you have any ideas on this or great examples, I’d love to hear about them.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cHksPiOAGL0jWcdI1b2Zeg.jpeg">wiARframe User Flow
<h4>We Inherited the Problems with AR</h4>
As well as the short-comings in our application, there are also the challenges faced by AR, and as a tool looking to be at the forefront of AR, we inherit those challenges.
<blockquote>“Why can’t ARKit detect my table, when I can see it just fine?”</blockquote>
In wiARframe, we leverage the capabilities of the mobile devices our App runs on. These capabilities are themselves still developing, for example, surface detection is still quite temperamental, especially in bright, dark or reflective environments, my tiled floors for instance, are invisible to my iPad.
We could address this with onboarding and instructions in the App.
<blockquote>“Why can’t I rotate the scene to see the other side?”</blockquote>
Another category of problems in AR is the expectant experience of users. We’re so used to having content move around us on our screens, that it feels unnatural when we have to move around the content in AR. In the real-world we will walk around a car to look at it, in AR we want to be able to spin the car instead, and perhaps it should spin.
We could address this by allowing the user to reposition the scene.
<blockquote>“I can’t find my marbles!”</blockquote>
In part a problem caused by our 2D to 3D mapping but something interesting to explore none the less. Often users (myself included) load a scene and then have to look around to try and find the content — I recently span myself dizzy trying to find a 3D model, before finally realizing that I’d placed it above head height, so had to look up to find it. In a fully immersive environment this would have been obvious but looking through the small lens of a mobile device, this hidden object game becomes very common.
We could improve this in both subtle and more obvious ways, for example, adding shadows below floating objects, or adding a Mini Map on screen that shows the position of all scene objects.
<img alt="" src="https://cdn-images-1.medium.com/max/720/1*I5ZbFOZ4m9SmISX6-tBg9Q.gif">wiARframe App Usage
For the above problems, I’ve said ways in which we could improve them but I’ve not committed just yet. Features like the Mini Map, whilst useful for making the AR navigation experience easier, also force a specific implementation for solving this problem. You may have alternative solutions or intentionally want users to seek out the hard to find objects. As such, we need to be cautious of blindly masking the nuances of the AR experience.
<h4>Asset Management is a Pain</h4>
We knew that Assets were going to be a huge pain even before we started the trials. In wiARframe we include a few sample 3D Models and allow users to upload their own.
The first problem is that there are <a href="https://en.wikipedia.org/wiki/List_of_file_formats#3D_graphics">so many different 3D model file formats</a>. The second and bigger problem is that what is inside the file is often a mystery, it may actually be more than one model, it may be neatly positioned at the center or floating at some random coordinates in space. Add in animations, materials, textures, and shaders, and you’re left with a huge barrier to overcome to simply allow a user to source and display good 3D models in their prototype.
The Beta testing allowed us to identify the three most common asset requirements for our users.
<ol>
<li>They just want to prototype the interactive experience, using specific or production quality assets is not a priority.</li>
<li>They want unique models in the prototype but don’t have the resources to make them or know how to source them.</li>
<li>They have access to high-quality custom assets, but they’re stored on a cloud drive and they don’t want a convoluted workflow to use them.</li>
</ol>
We aim to address these in exactly that order by doing the following:
<ol>
<li>We’re going to build our own collections of prototyping assets, built with speed and the most common use-cases in mind.</li>
<li>We’re actually going to limit the formats that we support, and produce strict guidelines for integration, so both you and we know they’ll work well. Then hopefully platforms like <a href="https://poly.google.com">Poly</a> will become great resources for sourcing new content.</li>
<li>We’re going to add integrations with cloud storage, Dropbox, Google Drive etc. So you can just link to your existing assets in your prototype, without needing to re-upload them.</li>
</ol>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*m73x07uznwjFgihtGiMiEg.png">wiARframe Asset Picker — Before and Mockup of a Possible After
<h4>Everything Else</h4>
Above are just some of the valuable insights we were able to gain and will develop upon in the product. Other things we’re still thinking about include our use of terminology, the variety of gestures to support and the types of interactions possible. There is lots still to do but it’s exciting work and we look forward to sharing it with you.
You can expect an official launch of wiARframe in the new year. Till then, you can keep in the loop on <a href="https://medium.com/wiarframe">Medium</a>, <a href="https://twitter.com/wiarframe">Twitter</a>, and <a href="https://facebook.com/wiarframe">Facebook</a>. The Beta will also remain accessible until the end of the year, so if you’re interested in <a href="http://www.wiARframe.com">Effortless AR Prototyping then do sign up</a>.
<h3>Acknowledgements &amp; Further Reading</h3>
Huge shoutout to <a href="https://www.linkedin.com/in/manuelapfeifer/">Manuela</a>, <a href="https://www.linkedin.com/in/agneslamjy/">Agnes</a>, <a href="https://www.linkedin.com/in/ben-hweile0909/">Ben</a>, and <a href="https://www.linkedin.com/in/dee-balkissoon-274b3515/">Dee</a>; the amazing UX Design team from General Assembly who conducted the Beta trials.
Finally, a huge thank you to all the lovely AR Guinea Pigs*, who tried out the Beta. I hope you enjoyed the process and saw enough potential in the product to stick with it. With your help, we can take it from good to great.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a34e85ce49d6" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/i-ar-guinea-pigs-a34e85ce49d6">I ♥ AR Guinea Pigs</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

I ♥ AR Guinea Pigs

Lessons Learned from the wiARframe Beta

Top Stories