Who: Network operators that need to monitor multiple network instances for hours a day
What: A faster way to spot errors and where the errors are.
Why: Errors are severe and as soon as they appear they need to be spotted and reported in order to mitigate severe network problems
Impact: Any network performance issues will be solved faster
Duration:
December 2021 - March 2022
Role:
Product Designer
Tool:
Mural, Sketch
Problem statement
A network operator needs to quickly find and report errors in network instances to get the instance fixed to keep customers happy.
My Contributions
UX: I led the all of the UX tasks for this product feature here by meeting with product managers and technical architects to understand the need and technical limitations, I facilitated a workshop to understand our target user and what tasks will this feature aid and complete for our user and lastly led product discovery and research about 5G networks to see if this is a viable use case for the product feature.
UI: I designed the dashboard page low to high fidelity and the first iteration of the details page which I then handed off to another designer to take in high fidelity and gave feedback to make it align with the user needs and Carbon Design System
Visual: Annotated all of the dashboard page and co annotated the details page, created a document with all components developers need for the page and held weekly developer sessions so we can ask questions about the design.
Overview
In Cloud Pak for Network Automation (CP4NA), I focus on designing products within the telecommunication industry.
In this use case, Flow Editor is a product for network operators to view the process of how the network instance was instantiated from a network design template.
For 3 months I worked with two technical architects, a product manager, and led another designer. I hosted knowledge sessions for other CP4NA designers to learn and understand 5G slicing and how it relates to CP4NA in general. I facilitated workshops, and knowledge sessions, and hosted weekly developer scrums to guide a team of developers to build the product.
Getting Started
Flow editor would be used alongside our product Cloud Pak for Network Automation (CP4NA) and in the future, be implemented in CP4NA. We created Jill, our persona as the main person who would use Flow Editor.
Currently, our users are only using the terminal code view to work and monitor their network design and instance’s performance. They only use the interface to present demos to executive stakeholders.
They need a usable interface to design execute and monitor network instances.
Jobs to get done:
Defining our personas
Features we want to incorporate
User stories
Roadmap
User Persona
Meet Jill
She’s a network operator at T-Mobile. Her job is to monitor for performance issues on network instances that are made for T-Mobile’s clients
Jill is a network operator at T-Mobile. T-mobile creates network services for their customers. Jill will get notified when her colleague Jack, a network service engineer, instantiated one of the network templates he has designed. Jill monitors the network instance’s performance for any issues and reports said issues to be fixed.
Usually, Jill will monitor hundreds of network instances in a day.
UX Knowledge Gathering
I held weekly knowledge sessions with the technical architect to understand more about creating network services and making instances from a network service template.
This allowed us to understand where our products come in with the process of creating a network and how our users get their information for making a network for their own clients. We came to the conclusion to have Flow editor will be used after Jack, a network service engineer, has designed and tested a network template. Above are the brainstorming and knowledge session murals.
UX Workshop - Validating and learning
To get more information and get the whole team updated, I hosted a workshop with our designers, technical architects, and our PM. I made sure to include our technical architects from all of CP4NA for there to be full transparency. Through the workshop, we became more aligned on the product and personas.
Findings
We understood where in CP4NA the flow editor will be located, how Jill will be able to sort through hundreds of network instances and find the instances with failures, and what content we need to show with each step of a network being instantiated.
Jill needed to find a way to not only quickly find the right instance but also where in the process of the instance getting instantiated, an error occurred and why.
For Jill to be able to spot failures quickly and understand where this failure occurs in the process of the instance running, we decided on a workflow visual that will show each step the network instance goes through to become instantiated. Steps will be visualized in cards and the cards will show the name, and status of the step. Lastly, arrows will show the order the steps are in.
Questions we have:
What knowledge does Jill have before opening a flow editor?
What information does Jill need in order for her to create a high quality issue ticket?
Currently, what are Jill’s day to day tasks?
What does Jack need to make his job easier?
How does Jill monitor the network instance with the current tools she has?
Workshop Mural
UI Designs
Jill right now has to spend a great amount of time to find not only what instance is facing failures but also where in the production process is the instance getting a failure. With enough information, I and another designer started creating high-fidelity wireframes. The product was two screens: a dashboard and a details page.
The dashboard will show all the network instances that have been initiated or are currently getting instantiated in a workflow data visual. The network instances are ordered from a failed status at the top to a pending status at the bottom so Jill is able to see the instances she needs to quickly.
In the details pages, we want to make sure Jill can access more information about each step and also expand the flow view to view any sub-steps that may occur allowing Jill to pinpoint a very specific place in a step where an error occurred.
Second Iteration
With the second iteration of the workflow visual we were creating a data visual that was not a already set component in IBM’s Carbon Design System. Because of this we had to make sure it not only allows users to spot errors and the cause quickly but also to make sure we can be as aligned with Carbon Design system as possible.
I took this on by searching through past authors for past charts and posting on slack channels. I was able to get responses by someone from the carbon design system and two designers working on a workflow data visualization for their own product. We were able to meet and align on certain visual aspects that we can have consistency across our products.
Changes made:
Removed the border that represented a status of the step and placed status icons
Removed the description of the steps and created a side panel that opens when a user clicks on a step
Adopted a status bar that can filter what steps a user wants to view
Replace decision icons and made a decision card
Hand off to Development
We had a team of ten developers working on the Flow editor. I held Friday morning UI scrums where developers had time with us to ask questions and get clarity. I kept notes of what we covered and what their needs were and how I can help from my side. Besides the weekly scrums, I was available on slack and would directly message any developer that needed help or responded to Slack in our Flow editor private channel.
UI Annotations
Breaking down the function around specialized components, states used, padding and color styles
Reflection
This feature was unfortunately cancelled from production due to the client finding a cheaper option. In the past 3 months I was able to lead and own a design feature while work closely with architects, product managers and developers. If I could change anything from this experience I would have loved to get more time to collect market research on what are our users currently doing and who are our competitors we are paying attention to. Additionally, getting more time to test the feature with users and also push harder on for certain design features that can help Jill get suggested solutions on how to troubleshoot failures and more information about the roadmap and timeline.
Story and Prototype
