Networking Tool
NOTE:
In compliance with NDA standards, much information, names, and documents have been redacted.
This is a networking tool that contains foundational network services that could be used to create different application. I worked closely with Bruce McDougall (Principal Sales Architect) on this project. I held interviews with potential users of this tool to build use cases, and ultimately designed mockups for the interface.
BACKGROUND.
For this application, the challenge was to design an interface that was suitable for two types of vastly different users– software developers and third-party business investors. I quickly learned that in order to create a successful UI, I would have to integrate features that would be intuitive to use for users in both the business and software developer fields, while also maintaining the high-level of technicality that both users have to offer.
THE CHALLENGE.
USE CASES.
Software Developer
Cody– SWE @ Cisco
-
Designing an application and wants to use this tool to retrieve already-existing network services.
-
Can browse through his purchased services to select his desired code-snippets.
-
Can create and push his own network services onto the tool for others to use
-
Wants: access to network services
Third-Party Investor
Thomas– Networking Director @Verizon
-
Has thousands of customers who are paying for his services
-
Browses and purchases networking services through this tool
-
With a fee, his customers will be able to use the purchased services.
-
Wants: to keep his customers satisfied and to make a profit
NEXT STEPS.
Research
Interview
DITL
Design
RESEARCH/
INTERVIEWS.
During my research and interviews, I talked to a software engineer who is currently developing an application, and a potential third-party investor. I learned what each of their needs with this tool were, and what they hoped to come out of this application. One aspect I found in common for the both of them is that they were interested in seeing the analytics and application health of the network services. Both interviewees found this to be an important feature, although their reasons were for vastly different purposes. However, my interviews led me to believe that the investor's UI should be focused on earning profit, while the software engineer's would be more technical and informative about the services itself.
DAY IN THE LIFE.
(DITL)
Software Developer
Cody– SWE @ Cisco
8 AM:
Cody wakes up and goes to work.
10:00 AM:
Cody is in a meeting with his coworkers. They discuss new ways to take the next steps on building their application. Cody takes notes of specific network services that he may use for his app.
1:30 PM:
Cody reviews his notes back at his desk and starts browsing network services he had previously written down. He also reviews his notes from his meeting with his boss and looks for services that can help him build these new features his boss wants.
9:30 AM:
Cody enters his office and opens up this tool. He checks the analytics of the application he is working on.
12:00 PM:
Cody is in a meeting with his boss. They brainstorm new features he can add to his application.
3:30 PM:
Cody adds the network services that will help him to his cart. He checks out and purchases these services. They are now added to his account and he can start using them.
FEATURES:
- Home dashboard with main points + "high-priority" elements
- Analytics section that lets developer see the service breakdown (include memory usage, warnings/errors, etc).
- Should be specific to the app he is currently working on
- Discussion board with other developers on same project. (Allow for discussion on code, features to implement, maybe a reddit-style forum)
- Browsing option for network services. (Filter by service category)
- Typical E-commerce checkout
Third-Party Investor
Thomas– Networking Director @Verizon
8:30 AM:
Thomas wakes up and checks his emails before going to work.
12:00 PM
Thomas goes into a meeting with his team. They report to him the analytics of their customers. Some customers are eager to have access to network services that include graph data. Thomas takes note of this.
1:30 PM:
Thomas browses through the services that this tool offers and adds desired services to his list.
10:00 AM
Thomas enters his office and opens this tool to check on how his sales are doing. He sees the estimated revenue he made since last night, among the service health.
1:00 PM:
Back at his office, Thomas reviews his notes and checks his customer feedback. He notices some customers are unhappy with the unavailability of certain services.
3:30 PM:
He purchases them and sends out a notification to his customers about the availability of a new service at hand. He also tells his secretary to include the list of new services in the weekly newsletter that gets sent out.
FEATURES:
- Home dashboard with main points + "high-priority" elements (business-relevant analytics)
- Analytics section that lets investor see each service breakdown (include average revenue, warnings/errors, etc).
- Browsing option for network services. (Filter by service category)
- Typical E-commerce checkout
- Option to interact with customers (Maybe a "notify user" button when a service has been added)
