A list of equipment to install in the My Spectrum app.

My Spectrum app equipment checklist

How might we improve customers' identification of internet and TV equipment, while reducing the design and dev effort to scale it?

Spectrum wanted to add the ability for customers to self-install their internet and TV equipment using the My Spectrum app. When I joined the project, the team was building the MVP and planning to run a pilot in a test market.

As we looked beyond MVP, however, we realized that the equipment checklist screen that kicked off the self-install flow posed some challenges for all of the additional use cases we knew we’d be supporting.

challenge one

high design & dev effort to support unique illustrations for every equipment package

The original equipment checklist screen worked great for our MVP use case: a customer that has internet and WiFi and is using the latest Spectrum equipment. However, Spectrum supports and ships dozens of modems, TV receivers and routers, and they all look a little different.

Creating unique illustrations for all possible equipment packages would be a hefty request of our small but mighty internal illustration team. We thought we might be able to programmatically show each piece of equipment within the illustration template, but a dev spike revealed that it wouldn’t be feasible.

challenge two

customers couldn’t confidently identify the equipment and its purpose from the existing screen

From a research readout I received upon joining the project, I learned 64% of testers were unsure or incorrect in identifying the modem and router by looking at the equipment checklist. Because the original design didn’t explicitly associate the equipment image with its name, users were essentially guessing which equipment was which.

“In the very first part that showed the router and modem, I'd like to see them labeled to avoid confusion about their identity.”
“I was curious about what the modem and the router do specifically and why I need both.”
“The most confusing part was that I didn't know the differences between the two functions.”

The research also showed that not being able to identify the equipment resulted in users feeling less confident in being able to successfully self-install their equipment. I also knew from previous research that customers not knowing the purpose of each piece of equipment—even at a basic level—contributed to challenges in troubleshooting down the road. There seemed to be an opportunity to educate and empower at this very early stage of becoming a Spectrum customer.

The original equipment checklist screen.

Project goals

  • Improve customer identification of the equipment in their self-install kit and its purpose.
  • Create a design that can scale to support all equipment and service use cases.
  • Create a design that reduces the team’s dependency on a small illustration team, and reduces complexity in development.

Research also showed that women typically underestimated their ability to identify their equipment, while men typically overestimated their ability.

This illustration worked well for the MVP use case but didn’t scale for the dozens of equipment and service packages we’d have to eventually support.

From 60+ models to 9
culling the image list

For all intents and purposes, most internet and TV equipment looks similar, so my product manager and I wondered if we could use equipment “archetypes” based on the most common modems, routers and TV receivers in market instead of unique illustrations for the dozens of variations.

Working with supply chain, we reviewed all of the modems, routers and TV receivers in market, and chose the top three models in each category that would be illustrated. This culled our illustration list from more than 60 to just nine.

An Excel document that tracks the different illustrations needed to support different combinations of modems and routers.

Next, I worked with our internal illustration team to create illustrations for these three “archetypes.”

choose your fighter

three modem illustrations to cover all use cases

The three illustrations types we choose to represent all of our modem inventory: a Spectrum-brand modem, a generic vertical modem and a generic horizontal modem.
My colleagues Brayden Love and Leah Roides created an illustration for the Spectrum Modem, as well as a generic vertical and horizontal modem based on the two most common models of each in market.

Now it was time to tackle the layout of the screen itself.

I used this matrix to keep track of the illustrations and animations we’d need to cover all of the internet and WiFi equipment. This was *after* determining the “generic” renderings we’d use to represent all of the legacy in-market equipment, and doesn’t include TV equipment.

how might we
reimagining the equipment “checklist”

Our cross-functional, 16-person team was made up of developers, two product managers, business leads, a data analyst, and me, the sole designer. Knowing that we wanted to avoid any unforeseen snags as we scaled the self-install project, I organized a design studio to sketch ideas for the new equipment checklist screen with our entire team.

It was not only our first design studio as a team, but it was also entirely remote due to COVID. After explaining the problem statement, I used Mural to gather each team member’s sketches. Each person explained their idea, and then we voted on the ones we thought would best solve the problem statement.

A snapshot of sketches from the team during a virtual design studio.

Two concepts emerged as the most popular: a list concept and a swiping concept.

A sketch that shows the equipment in small cards, organized as a list.
A sketch that shows the equipment with its name, image and definition, organized in a carousel.

exploring lists and inventories

With these two concepts in mind, I began researching list and sliding card patterns to get a sense of how I could bring these ideas to life in our UI. I looked at several examples of different apps that use lists and/or inventories to understand best practices and also the other types of lists and inventories customers may be using day to day.

Next, I started sketching some ideas for both concepts. In the process, many questions came up:

  • How best to balance image size with showing all of the items in the list?
  • Because the order in which you set up equipment matters, what cues in the UI would indicate the sequence?
  • Conversely, should we indicate which equipment is “unavailable” to set up (because there’s prerequisite equipment)?
  • How much detail do we need in the equipment description so that customers understand its purpose? How would customers describe each piece of equipment’s purpose in their own words?
  • Do customers expect or want to see equipment they’ve set up successfully?

These questions informed a lot my early explorations.

Some examples of early explorations I did of displaying the equipment in list format.
Initially, I experimented with different ways of making equipment look "unavailable" or "locked" until the prerequisite equipment had been installed. I also played around with an enlarged view of the equipment that was next to be installed.

Eventually, I came up with a more solid proposal for the list concept, as well as a swipeable card concept.

Early explorations of the swipeable cards concept.
Early explorations of the swipeable cards concept.

OK, but how hard would this be to build?

At this point, I had conversations with the product manager and dev architect about the level of effort to build each concept. Fortunately, the time to build each concept wasn’t significantly different, and both concepts would scale well to support all of the use cases. Although the sliding card concept would require a bit more work, dev was on board with going with whichever concept tested better and addressed the user questions. We planned to regroup again after I’d refined the concepts.

refining the concepts

After getting some feedback from two design peers who also worked on the app, I refined the list and swiping cards concepts.

the list

optimizing for several pieces of equipment

A strength of the list concept is that you can see all or most of your equipment on screen without scrolling or swiping. A little more than 50% of new customers would have a 2-4 pieces of equipment, but 40% would have a 4-6. My hypothesis was that a list would give customers a better overview of their setup and make it easier to take inventory of what they received in their self-install kit.

However, a potential disadvantage of the list is the image thumbnail could be too small for the customer to identify the equipment in their box. I decided to mitigate this weakness by adding a bottom sheet with a larger image that appears when you tap the list item.

The list version of the checklist that we tested, which shows each piece of a equipment in a vertical list. Each equipment cell has a thumbnail illustration, and a brief description of what that equipment does.
An animation of the list version of the checklist that simulates a customer going through the setup flow. After a piece of equipment has been set up, an animated green checkmark appears in the equipment cell.
JS prototype (right) done by Joe Dalton.
swipeable cards

optimizing for equipment image size

On the other hand, swipeable cards showed a larger image for each piece of equipment. If we were trying to improve customer identification of the equipment, perhaps a larger image was the way to go.

The obvious disadvantage of this concept was that a customer would have to swipe through all of the cards to view each piece of equipment. It may not be a big deal if the customer only has a modem and router to install, but could pose problems for larger self-install kits.

The version of the swipeable cards that we tested. The card has the equipment illustration, MAC address, and brief description of what the equipment does.
An animation of the swipeable card version of the checklist. It simulates the customer swiping through to see each equipment card, then setting up the modem. When it's set up successfully, a green checkmark appears.
JS prototype (right) done by Joe Dalton.
testing two approaches
prototyping and testing

Next, I partnered with a UX engineer to create a high-fidelity JS prototype of each design, and worked with our UX researcher and product manager to develop a test plan.

User feedback

the list had a slight edge

We tested with 20 participants total—10 participants testing the list version of the prototype and 10 testing the card version. Here’s what we learned:

  • List order wasn’t interpreted as order of setup. Only 40% of participants who tested the list version correctly communicated the intended order of equipment setup, versus 70% who tested the card version.
  • 30% of participants struggled to navigate the swiping in the card version, which reduced their task success rate.
  • Participants did not try to skip the intended order of setup in each prototype.
  • All participants liked the illustrations, but those who tested the list version rated the illustrations slightly better for being easy to distinguish, easy to see, and having descriptions that were easy to understand.
“Each equipment illustration on the ‘Your Equipment’ screen is easy for me to see.”
“If I was tested, I could easily distinguish each equipment illustration from one another.”

From the results and verbatims, it also seemed there’s a slight advantage to presenting this screen as an equipment setup “overview” that displays most of the equipment and illustrations at once (AKA the list), instead of showing only one item at a time (AKA the swipeable cards).

Overall, the list version had fewer pain points compared to the card version, and it was also easier to iterate on the list version to address those pain points. These results, coupled with the shorter time to build, made the list our winning design.

This was surprising. I’d assumed the order of the items in the list would translate to the perceived order of setup.

This was also surprising since the illustrations were bigger in the card version.

what happened next?

Based on testing, the next steps were clear:

  • Make the order of setup more explicit. Because the order of the items in the list wasn’t interpreted as the order of setup, I needed to explore ways to more explicitly communicate that, perhaps by adding a numeral to each list item.
  • Improve the equipment description copy by applying the “function + relationship to other equipment” formula we uncovered in testing and incorporating testers’ exact language where appropriate.


learning how to run better design studios

This was not only the first design studio I ran on my own, but it was the first I’d done virtually due to the pandemic. To get feedback on how to improve design studios for the future, I sent out a survey to my team.

A snapshot of the Google Form I used to collect the team's feedback on our first design studio. The questions include, "How valuable was this activity to you?" and "What did you think of the tool we used (Mural)?"

Eighty-eight percent of my teammates who responded said the design studio was a valuable or very valuable experience, and 100% said they’d participate again.

My main learnings from this experience:

  • Folks love having a voice in design. The team liked collaborating and discussing different ideas. I think our devs, in particular, liked getting to have input on design from the start.
“I liked that all team members can participate in coming up with a good way to solve a problem. Helps shift people’s minds into "it would be awesome if we did it this way."
  • The idea-gathering process was clunky and didn’t work as expected. Having people sketch on paper and then upload their sketches to Mural was cumbersome and took a lot of time. Some wished we’d done a tutorial on the tool beforehand, and others wanted guidance on the expected fidelity for these sketches. With some pre-education, I think using an all-digital process with a real-time whiteboard tool like FigJam or InVision Freehand would work better.
  • 16 participants was too many. The issues we ran into with the process were compounded by the number of people participating, and it took a long time to present and discuss every idea. Five to six people would have been more manageable for maintaining engagement.
  • Make sure all disciplines are represented somewhat equally. Because everyone on our cross-functional team participated in this design studio, we had representation from design, product, data, dev and management, which was great. Dev was overrepresented, however, by a ratio of 4:1. While dev perspectives aren’t a monolith, I believe it’s important to balance the input of each discipline.

Some people couldn’t upload their designs, so they emailed them to me to upload. It got... chaotic.