Tamaggo 360 LiveCam

Fine-tuning the Bluetooth and Wifi connection process.

Background​

Tamaggo is a hobbyist level 360 camera with live streaming capabilities.

Our team was hired to created an iOS and Android app to control the camera, as well as build the underlying technology (SDK) to accelerate future development on the platform.

This case study focuses on simplifying the process of connecting to the device from the mobile app, which was identified as a common pain point in competing products.

Experience Goals

Simplify the Pairing Process  Obscure complexity from the user and provide a simple experience when connecting to the device.

Allow Setup from a Single Device  Avoid forcing the user to switch between the camera's small screen and the phone when connecting.

Create an Accessible Nomenclature   Create a common understanding among the development and design team betweens the subtle differences in connection types.

The Outcome

· Through several iterations, we created a user flow that balanced predictive optimizations with user-choice in key places.

· Extensive user testing was implemented at an organization accustomed to defining user experience based solely on client review.

My Role

· User Experience Lead and Product Manager.

· Defined user flows for UI and Development teams.

· Created technical capability document for x-functional team.

· Managed design team and development of camera SDK.

· Organized and executed usability testing.

· Supervised creation of visual design.

A Look Ahead​
Screens from the Tamaggo iOS app, hidden behind a daunting connection process

Opportunity to Excel 

The Common Issue of Connecting

Our initial research examined existing products on the market. Price was a differentiator for Tamaggo but that advantage was to be short lived. We sought ways to create a user experience that was more seamless than the competition.

We identified an opportunity in the experience of connecting to the camera. Online merchants were were flooded with reviews of confused customers unable to consistently connect to their devices.

Our team identified app-to-camera connection issues as a key point of failure for competing products.

 

Communicating Complex Concepts to a Non-technical Audience

The complexity of the Tamaggo connection process became apparent in discussions with development and design team. With three overlapping methods of connecting over a combination of bluetooth and wifi, the team lacked a shared understanding.

Below is a document that explains the three connection processes and how they work. These were internal facing documents which I created for the team.

If our developers were confused, our users were sure to be as well.

wireless lan.png
 

Connection Flow Design

Designing with Technical Capabilities

Due to the intensive bandwidth requirements of streaming 4k 360 video, a connection via a wireless network (not a mobile network) was highly preferable.

However, while the connection strength was superior, the process was the most laborious. It required the user to input the network name (SSID) and wifi password.

Initial design efforts attempted to direct users to the option most friendly to Livestreaming.

First Pass: Design Decisions

Using Invision prototypes, versions of this flow were tested at a co-working space. Prior formal usability testing, decisions were made based the fundamental goals of the projects and design best practices.

Promote Livestreaming  In order to promote livestreaming capabilities, the flow automatically guided users to connect to Wifi in cases where we detected their phone's connection to Wifi. This also reduced the number of decisions the user had to make.

 Paradox of Choice  Rather than giving users three options and allowing them to wonder whether they made the right choice we limited them to the best two connection options on each platform (Android and iOS). 

We removed some options altogether in order to limit decision fatigue.

Use of App over Small Device Controls  We leveraged the fact that the Tamaggo was always broadcasting in order to send the Wifi information over a Bluetooth connection.This meant more upfront loading time but far superior ergonomics for the user.

Basic connection flow for first user tests. Testing was conducted using a "think aloud" protocol.

User Testing

  ISSUE  

Correct Actions but Low User Confidence

Testing began with the initial Invision prototype shown above. Somewhat counterintuitively, the largest revelation from the was that, more steps were needed in order to establish a clear mental model for connection.

 

In his book Don't Make Me Think, Steve Krug writes that “It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.” While we had limited the number of steps, users reported low confidence.

  ISSUE → SOLUTION  

More Steps, One Concept Per Screen

We initially placed users directly on the password entry screen if they were connected to wifi.

In response to feedback, we switched from automatically directing users to the best path, and instead showed them both options, alongside simple advice on the best course of action.

Combining steps reduced time to completion -- but at the expense of confidence

Before Revisions

Initiate connection process

Show network name, prompt to enter password

After Revisions

Ask if user has access to wifi

Tell user the name of network camera is going to connect to

Enter Wifi password

Adapting to New Technical Constraints

The hardware and firmware capabilities of the device were a moving target. Much of the development was done on analogous hardware. ​User testing on a more advanced hardware build revealed new issues.

 

In these sessions both the design and development teams were present to witness the hang-ups thats users experiences.

The arrival of final hardware specs shifted a number of our assumptions.

  ISSUE  

Time to Connect Varies Greatly Across Different Wifi Networks

Testing revealed wide inconsistencies in connection time over wifi. We initially assumed that the importance of livestreaming justified the slightly longer connection process.  This was no longer true.

The tradeoff of Wifi connection time no longer made sense.

  ISSUE → SOLUTION  

Explaining Benefits + Deferring Troubleshooting

We identified that the risk of connection difficulties over wifi was significant; those using the app for the first time expressed a desire to use it's functionality as quickly as possible. In response, we allowed users to reconnect later over wifi when they wanted to use livestreaming.

 

The subsequent design reintroduced user choice and clarified the benefits of the two connection types.

We moved away from assuming for the user and further towards explaining pros and cons.

Before Revisions
After Revisions

Assumes Wifi is preferred

User selects the connection type

Prompt to switch to Wifi when needed

Technical Design Refinement

The new flow presented an opportunity for further optimization,  in that users connecting directly to the camera's access point, did not need to wait for the full BLE pairing process.

In order to accomplish the new flow, camera commands had to be sent over wifi and not Bluetooth. Working with the Tamaggo firmware team, we created new  commands that could be sent over Wifi Instead of Bluetooth. That way the bluetooth process could be bypassed.

Bypassing Bluetooth with New Wifi Commands

Reshuffling the connection steps occurring behind the scenes optimized our flow.

Outcomes and Results

Involving the entire development and design team in think-alouds, many of whom were initially skeptical of the practice, effectively evangelized the practice at the organization. Developers become more motivated about revisions to problematic flows, and the most skeptical were asking when we could run more tests.

A pilot run of hardware was released to friends and family, which revealed several problematic issues outside of the connection flow. Especially problematic was the mental model of saving media to the camera vs. to the phone vs to both. Where did a picture live and when? Using the same practices discussed above we were able to iterate to novel solution.

Developers and designers once resistant to user-testing began championing the practice themselves.

We advised Tamaggo on the experience of the app in addition to livestreaming, creation of the web viewing experience, and supporting firmware features, ensuring the end-to-end journey was as frictionless as the connection process.

The product is now for sale and beginning to garner positive reviews, with the app as an integral part of the product.

An End to End Experience - And We're Live!

Usability Increased over Course of the Pilot

Establishing Company User Testing Practices