Telecom Enterprise Client Portal

Internet equipment remote restart

Project

A new feature within a telecom enterprise client portal where organizations can self-troubleshoot internet issues by remotely restarting their internet equipment.

UX research says

Technical clients want more self-serve options in the client portal so they don’t have to spend time calling tech support for something they can do on their own.

Digging in

Because self-serve troubleshooting was new to our client portal, we needed to understand not only the user flow but also what happened within our tools and systems. After kickoff with product, we got to work on the userflow and connecting with different areas within our organization.

User flow

Cross-functional collaboration

Technical subject matter experts (SMEs): Technical support team members showed us exactly what happens on their screens when they manually remote restarted equipment. This helped us understand our clients might be without internet access for 2 to 10 minutes when they restart their equipment.

Content design peers: Small business and residential divisions within our organization already had this function, and content designers walked us through the screens they co-designed with their product design peers. This left us questioning the best word for this process: restart, reset or reboot. They used restart and reboot interchangeably, but that confused us even more.

Technical SME: We went back to a technical support team member and asked them exactly what word they use with the clients who call for this troubleshooting step. He told us they used the word reset.

More questions

Design and product teams gathered again to discuss some questions that remained:

  • Would an in-process modal stay on the screen and transition to the success or failure modal if clients were restarting equipment, and disconnecting from the internet entirely?

  • Or would they have to sign back into the client portal?

  • Would enterprise clients think the word reset might mean factory reset - meaning changing custom settings? Would this cause ambiguity in what was supposed to be a simple task?

Looking for answers

Our team is scattered in multiple areas of the US, so we decided to test our home internet providers' remote restart/reset/reboot function. We each signed into a website (personally, my bank) and took screenshots of the process to analyze as a team. We wanted to see how multiple residential internet providers presented this process and also if we stayed signed in.

What we learned

  • We all stayed signed in.

  • Progress modals transitioned to success modals even though we disconnected from the internet.

  • Restart was the term used most frequently. Given that’s literally what happened - our modems turned on and off - we felt comfortable moving forward with restart for clarity, even though one SME told us he says reset. If a client questioned the loss of custom settings over the phone, he could explain. We needed clarity without explanation. I also filled out a research intake form to validate our clients felt comfortable with the word restart. It went into their backlog, and we’ll make changes if need be.

That was enough to get started on designs, but we still needed our product manager to get answers to one final question: outside of losing internet access for 2 to 10 minutes, is there anything else we have to prepare our clients for if they choose to restart their internet equipment?

Off to Figma

We started designing wireframes in Figma. On my team, content designers work directly in Figma for a single source of design truth. Some content design areas of work included:

  • CTA to start the restart process

  • Roadblock modal for confirmation they want to move forward

  • Sending signal to your equipment modal

  • Restart in-progress modal

  • Success messaging with options to continue troubleshooting if internet issues didn’t resolve

  • Troubleshooting instructions if restarting equipment didn’t solve their issues

  • Failure messaging

Answers found

The product manager found the answer to our remaining question: some clients may lose phone access, too. This means they would be unable to call 911 in an emergency. This information impacted the messaging on the roadblock modal.

Iteration + reviews

Design:

Once we felt good about the process of restarting and our designs felt solid, we presented them at a design review. Design reviews are a common occurrence at this organization. It’s a time to show other designers work and hear what they see that we might have missed. Design reviews can confirm our choices or, sometimes, send us back to the drawing board. The conversation mainly focused on choosing our progress bar component vs the spinner that we typically used.

Research:

Usability testing showed that 100% of people could find their equipment status, locate the piece of equipment that was offline and navigate the equipment restart flow to completion.

Devs:

As the dev team worked through the process, we learned we shouldn’t present a modal that said a signal was being sent to the equipment because it would transition to the in-progress modal so quickly that no one would be able to read it. We removed that modal and went from the roadblock modal to the in-progress modal.

Accessibility:

Accessibility confirmed compliance, and we made minor design updates for design consistency and clarity in refinement with the dev team.

Designs

Available upon request.

Outcome

For the client: A remote restart feature that will put our clients in control and save them time and effort.

For the business: A possible reduction in calls to support given this self-service option.

For our team: A unique opportunity to collaborate on a project where we were all learning about the feature at the same time.

For myself: The opportunity to work with new-to-me SMEs and deepen my connections within a large corporation.

This project reinforced

  • Research isn’t always done by researchers. Some projects have more upfront work than others. Design comes after the research.

  • SMEs often welcome questions and time spent together. They want success for the client as much as anyone else.

  • If a word or label doesn’t feel right, keep digging until you find one that does.

  • Rely on product peers to help find answers you don’t have. You’re all on the same team.

  • Partnership within product and content design is the best to get things done in UX design.

  • Lead Content designer: Me

    Lead Product designer: Jasin

    Product designer: Andrew

    UX Researcher: Katie

    Product manager: Rebecca

    Product owner: Ben

    Dev team: Thuy & Shushant

    Accessibility architect: MD

  • 6 months

Next
Next

Enterprise style guide