In 2016, I had the opportunity to be an interaction designer for a 3D capture project by Matterport. The agency I was working with, Punchcut, was brought in before launch to help with the UX.

The biggest area of discussion when designing the interaction design for for Matterport Scenes was around navigating 3D space on a touchscreen. We went through several iterations on the use of single tap when navigating a scene. Unlike other Matterport products, there aren't designated discs to move to or lines to follow. The technology isn't stitches photographs, but point cloud capture and has different information than their professional 360 rigs. 

A Note on Point Cloud Capture: To way oversimplify the situation, an infrared camera sends out a tiny beam of light and places a dot where it landed. It does this thousands of times and a whole bunch of dots become an image. Add color, and you start to have an image with fairly accurate measurement information, and a whole bunch of dots.

Dual Stick Controls

Pulling from mobile games, using on screen stick controls was a possibility, but limited the user's ability to look around. Adding a second 'look' control made the navigation too rooted in game mechanics and made it inaccessible to users.

Targets and Paths

Reusing the patterns from other Matterport projects seemed like a good way to have brand consistency. Matterport products using the 360 Pro camera used onscreen UI to give users tap targets for the best 360 views. However, without knowing where or how a capture is taken or intended to be used, placement of targets became arbitrary and didn't provide the best view experience. Looking to Google street view, movement paths seemed like a possibility, but had similar problems with placement. While both of these options work well for stitched 360 views and navigation, they didn't work well for point cloud renders. 

Tap to Move

The simplicity of tapping where you want to go seemed like an obvious choice. However, the more we iterated a the variations of tap to move, the less it seemed to work. There is a detailed breakdown of the various (and ultimately rejected).

• difficult to determine where a user tapped

• limited to forward movement

• hides the primary move method

• navigation would change during editing when tap is used for tools

What works: Seems like the simplest solution

What doesn’t: Taking a user to the point they tapped on would usually put them inside a wall or object. It's hard to know what they were intending to tap on. 

What works: You can see the place you wanted to go to

What doesn’t: You can’t move somewhere else in the scene that doesn’t have point data. You can’t control how close or far you are from the point. 

What works: It allows a user to see the object they tapped on more clearly without going inside of it. 

What doesn’t: An inconsistent jump distance seemed confusing and this model was never tested on device.

What works: When tap doesn’t work, users will instinctively try other gestures. In hallway testing users almost immediately understood that pinch zoom was move and were able to use that across all navigable spaces. 

What doesn’t: Tapping to show and reveal tools was not familiar to some users. It took a few seconds for users to pinch and zoom. 

What works: Zoom and move have the same effect in this app. You get closer to a thing and that thing is bigger. Pinch to move gives the user greater control over where they are moving and by how much. It also gives them the ability to move forward or backward. 

What doesn't: It took some users a few seconds to figure out how to move if they didn't see the tutorial marks. It can take a while to move long distances.

... so why can't I tap?

• It's limited to forward movement

• It's hard to know what point a user tapped on

• It hides the pinch to move gesture

• Tap is used for crop and measure, so you couldn't navigate while in those modes