eero OTA
Updates on demand
background

One of the underlying keys to changing the traditional router was the ability to  update the eero OS hardware whenever they are available. Additionally, eero is an ever changing product; we want our customers, new and existing, to have access to our suite of software features without having to purchase new hardware.

Research & discovery

// Competitive Analysis
// Stakeholder Interviews
// Understanding Feasibility

Research & discovery

On the surface, this seemed like a straight forward feature with a button to enable update. As I would find out, there were many engineering constraints that I needed to understand.

I held meetings with various engineers throughout the software and hardware engineering organizations to understand the pit falls that users could run into. In addition to understanding our limitations, I looked into how new competitors on the market were handling these cases along with other types of smart devices that allow users to update their hardware OS’s.

Problem statement

How might we allow users to update their eero OS on demand so that they have the latest features available?

goals

• Allow users to update their eero OS on demand
• Create an experience that gives users a sense of progress through a strenuous process

Process flows

One of the most challenging tasks throughout this project was understanding feasibility. What made it difficult was that not only did I have trouble understanding when users could run into issues, so did the engineers. It was a process that we had to work through together. To help us all be on the same page, I created process flows that allowed us to communicate efficiently.

Explorations

Utilizing the process flows, I identified touch points for users; where and when they would be able to receive feedback on what was going on with their update.

Knowing that the process would take anywhere between 10-15minutes, the engineers and I initially explored animation concepts that would engage the users frequently. Due to time constraints, we realized that our efforts needed to be spent on the dozens of edge cases users could fall into. Ultimately, we ended up utilizing existing animations from setup and additional copy to show progress.

first mvp

After a quick 6 weeks, we launched user initiated software updates. We covered cases ranging from the various ways a user can enter this flow to things like “what if someone unplugs their eeros?”.

further iterations & updates

After our initial launch, we received feedback that users felt trapped in the app and weren’t sure if the updates were working due to the length of the update.

Originally, we had locked the progress screen because users wouldn’t be able to make any changes to their network while the system was updating. From the feedback we received, we realized that while changes couldn’t be made, unlocking the screen allowed users to not feel trapped and made them more likely to come back and check progress later.

In Fall of 2017, we unlocked the progress screen to allow users to move around in the app and updated the flows to match our new design system.

the team

My Role: Interaction Designer, Visual Designer, Motion Designer
Product Manager: Paul Nangeroni
Mobile Engineers: Jordan Jozwiak, Christine Wang, Charlie Jacobson
Cloud Engineers: Vlad Bukhin