Nokia Internship 2019, designing features for technical users

I worked closely with a senior interaction designer to create an experience around leveraging automation to help network engineers save time and reduce risk of human error.

Role

Mockup of an interface on a Mac desktop

Context

The IP/MPLS Simulation web app is a sandbox that network engineers can use to import a version of their IP network, play around with network configurations and simulate what-if scenarios.

I designed the Worst Case Failure Scenarios tool for IP/MPLS Simulation, which allows engineers to choose any number of objects in their network and generate scenarios to see the consequences of that object failing.

Define

Problem Statement

Network engineers must create contingencies in the event of network failure to avoid causing cause disruptions to internet service for customers. Since networks can include up to thousands of objects, simulating and analyzing failure scenarios one at a time is extremely time consuming and creates a large margin for human error.

Define

Value Proposition

  1. Reduce the margin of error while analyzing data. Data is displayed in a simple table organized into relevant categories of information. Infotips are used where necessary for improved readability and understanding.
  2. Free up time for engineers to spend on other tasks. Automating this task frees up engineers to work on other tasks, allowing them to get more done in the same amount of time.

Design

Preliminary Explorations

The first thing I did was facilitate a meeting with the developers, QA, and product manager, to start everyone on the same page about the general functionality. I recorded requirements from the meeting to keep me on the project road map as I began my design explorations.

Breaking down the flow into three chunks allowed me to understand the user’s perspective and thoughts at different stages of the process.

Step 1

Selecting Objects

What information does the user need to decide if they want to include an object or not?

How many will they want to select at once?

Step 2

Generating the Scenarios

How long will it take?

Can the user use the app while it’s generating scenarios?

What if the user decides to cancel the simulation?

Step 3

Viewing Results

What information do users want to know about the scenarios?

How can we break down the information to avoid overwhelming the user?

I presented a preliminary navigation chart to the product team, which kept the team informed about my progress and generated discussion. This resulted in feedback that helped direct my next round of iterating.

Refine

Iterating

How might we make the waiting stage simple and painless?

Since the scenarios could take hours to generate, I considered the experience from the user’s perspective to identify pain points that needed to be addressed, and in what order of priority. The most critical pain point was any outcome where the user would have to run the scenarios all over again, possibly due to lost or corrupt data.

Solution

A GUI-blocking dialog prevents user actions that might cause inaccuracy or loss of data, and provides assurance to users about the progress of the scenarios.

Mockup of the feature's in-progress state

How might we take a large amount of data and make it accessible?

I maintained close communication with our team’s domain experts to learn what data our domain expert user needed and why. Knowing that different users may have different requirements, my goal was not to give them the “right” answer. My goal was to make the data accessible so they can easily find what they need when they need it.

Solution

The large amount of data is broken up into two levels: a big picture view sorted by most critical to least critical scenarios, and a detailed view for advanced troubleshooting.

Interaction flow of results pages

Deliver

Evolving design and documentation

After reviewing the initial design with the team and incorporating their feedback, I produced interaction flow charts with detailed specs. These documents were constantly evolving as the product team moved from one iteration to the next. As project road markers moved or changed, I updated these documents to provide a single source of truth for the product team.

Blurred out screenshot of interaction documents

Reflection

A major challenge was putting myself into the user’s shoes. As a design student, I was as far away from our intended user as you could get. For me, an interface full of technical jargon would be overwhelming and confusing. For our user, it might be just right. I continuously improved my understanding of the domain by corresponding with domain experts on my team.

The more I learned, the more I began to empathize with our user, allowing me to strike a balance of designing for general usability versus the specialized needs of our extremely technical expert user.

This experience gave me the confidence to know that no matter what domain I step into next, I have the problem-solving and troubleshootings skills necessary to adapt and empathize.

Interested in chatting about this project?

Connect with me on LinkedIn or shoot me an email!