Connected Devices

Before diving into this work, I reviewed existing research that informed this feature’s requirements.

This allowed me to gain more insight on our users’ priorities and showed me that users want more direct control over who is accessing their network. I made it a priority to include a ‘remove device’ feature.

Research feedback

I got inspired by conducting a competitor and comparative analysis.

Analyzing a competitor (Spectrum) and other products under the Comcast umbrella (Xfinity/WiFi Pro) allowed me to evaluate how they treated some of the interactions we wanted to implement. I also analyzed Gmail and used it as inspiration for how to organize the information to allow for bulk actions.

Competitor/comparative analysis

This large feature upgrade required some prioritization.

Initially we wanted to allow the user to set an additional downtime restriction. However after seeing that a segment of users already had this enhancement through the WiFi Pro add-on, we decided that the ‘pause device’ functionality we were already building into Connected Devices would meet the user’s needs without the additional dev lift.

I was now ready to begin wireframing and determining the information architecture of this feature.

I started out by making a list of considerations and then broke down the structures of this page into a bulleted list. I then made some quick task flows to illustrate a few of the most important actions.

Questions

User flows

I played around with having both Devices and Groups side by side, but concluded this wouldn’t work well. Since the list of devices was the primary aspect of this feature, I kept that front and center and defaulted users to this view. This led me to a tabbed approach from which users could click into any device or group to see further usage and spec details.

Early sketches

Early design exploration

We had to navigate pushback from our dev partners and advocate for the best user experience.

This was a very interaction-heavy feature, requiring the user to go through various steps to complete certain actions. Because of this, we decided side panels were appropriate for certain actions to keep the user anchored in the experience. Our dev team was very sensitive to introducing side panels as they were difficult to maintain. After meeting with the rest of the UX team and conducting additional usability research, we felt it was appropriate to continue advocating for these designs.

In our following dev refinement call, I presented a more contextual deck clarifying our reasoning for the few side panels we were introducing and also showed some alternative failed design explorations we attempted. The dev team clarified their hesitation with nested side panels which we didn’t have. This additional communication and collaboration between our teams allowed us to agree upon this solution.