Backstory
Over the summer, I interned with the university’s IT department and gained insights into the challenges faced by the IT staff. One particular thing stood out — network administrators routinely traveled between buildings on golf carts as part of their troubleshooting process for resolving issues.
It struck me right away: Is there a way to make this process more efficient and thus less time-consuming?
Design Process
Research was absolutely necessary in order to understand the core of the problem as well as what is doable with the constraints. Having taken Computer Networking and System Admin, I had a solid idea of how the app could work. However, I learned a lot more throughout designing the user experience.
I will address the learnings as we go through this case study.
Problem Space
The university currently lacks an app to track network connectivity, meaning there is no way of seeing why a certain building lost connection other than manually.
These are the key significant issues —
- No insight into network connectivity issues from office. Network administrators manually ping switches and go through a series of buildings to figure out the origin of the issue.
- Physically assessing issues. Network administrators often go and physically examine the connections because pinging is not sufficient.
- No clear hierarchy in task management.
All of these problems make the troubleshooting time consuming and inefficient, so let’s see what we can do about it!
Business Metric Goals
Although a concept project, the goal would be to improve the following:
- Task Completion Time — the time taken to resolve network issues from the moment they are detected to their resolution and compare to times we previously had
- Operational Efficiency — the time spent on manual tasks, such as physically checking switches, leading to more efficient use of the network administrators’ time
How does the app work?
To fully understand the solution, we will go over network fundamentals:
- Network core — the central hub spreading internet to buildings through wires
- Switch — hardware connecting devices on a network, inside of a building
- Stack — a combination of two or more switches with a functionality of a single switch
- Pinging — sending a small data packet to check if switches and stacks are reachable and working
Solution
Periodically ping switches multiple times per hour to test their connection status. It is sufficient for a building to lose connection if one switch is down.
What happens when a building loses connection?
Switches and stacks are a medium for connection. Buildings have a parent-child relationship. If a building loses connection, then each succeeding building will lose connection.
I. Task Management
1. Understanding the card system
If a switch is unresponsive, automatically stack a card of the respective building in the “To Do” list, indicating that the building has lost connection. The other two lists are “In Progress” and “Archive”.
Let’s take a look at the logic behind different priorities.
The Archive screen has a different layout. Originally, it was meant for a Done list. However, after consulting with Dr. Fuller, the dean of School of Science and Technology at the university, we decided to use it as a temporary storage for tasks for 30 days before permanent removal, considering the common reoccurrence of network issues.
2. Moving Cards through different lists
The only way to know which list a card belongs to is to manually adjust it based on what is happening on-ground with troubleshooting. The original idea is to drag-and-drop on Web and introduce another bottom sheet by clicking the three dots in the corner for mobile.
However, after consulting a more experienced colleague, Vojislav Vitkovac, I was advised to keep the drag-and-drop pattern on the phone as well and include a tutorial.
II. Task Creation
1. Manually creating tasks
If office of IT gets many tickets but there aren’t any ping issues, let admins manually create tasks instead of relying only on software.
Let’s take a look at a flow of creating a task for a certain building:
After a task has been created, all users are informed about a new task.
III. Interactive Map
Users can access the map either by clicking on a card, or by clicking on Map in the nav bar.
1. Map — Inside of a Building
2. Map — Outside of a Building
IV. Connectivity Issue Information
In these assets, we see whether a building has an external issue or an internal issue:
V. Edge Case when Creating a Task
When entering a stack, internet goes to the first switch, then to the second switch, then to the third, etc.
At my university, all stacks consist of exactly two switches — for the sake of simplicity, further called Top Switch and Bottom Switch.
After talking to Melissa Page, the head of IT department at the university, I learned that the non-responsiveness of the Top Switch might be due to an issue in the internal communication of the Stack. Checking the entire stack allows us to assess the broader network environment.
If the top switch doesn’t respond and the bottom switch responds, then it is good practice to investigate the entire stack for potential issues right away.
But why is it important?
If the user is creating a task and selects a top switch of a stack, the app suggests checking the stack.
Note: During the summer, I designed a very simple web app and a friend of mine, Frangil Ramirez, developed it.
However, the goal of this project was to expand on it. This product associates hardware that is down with respective buildings and connects all of it into an intuitive UI. It also allows for task management.
Web screens have been omitted not to make the case study too long.
Learnings
Although having previous networking knowledge, the biggest takeaway from this project is that asking and learning can only benefit a product. Addressing small details, looking at edge cases and thoroughly understanding the problem can make a big difference for the solution.
A big thank you to the people mentioned in the case study that helped me understand the hierarchy of the problems when designing the solution. The hours you put in are truly appreciated.
That’s a wrap!
Thank you to everyone who took time to read my first case study! Feel free to hit me up if you have any questions! And don’t forget to leave some claps if you enjoyed reading!
Hey, I’m Luka, a product designer. Feel free to reach me at ilicludes@gmail.com or LinkedIn!
