ADVANCED AUTOMATION TOOLS
COX Communications
Quickly standing up multiple tools to accelerate the work of internal teams.
As my second client initiative while working at Cognizant Softvision, I joined the Cox Communications internal BB-D (Better By Design) team. This team's focus was to look at internal processes performed across the company domestic channels and figure out ways to simplify them and make them easier using custom applications. This spawned the BB-D Control Systems Portal, housing a collection of tools and apps that used automation and design to speed up in-house workflows and assist in making complex processes much easier for our teams.
The first project that I jumped on board to help spearhead, with the help of fellow designer Ryan Simmons on the Cox BB-D side, was to create a simple dashboard for our internal team to view the status of some of our most important server groups: DAC and CASMR. The old way of investigating server health for our teams was to login to an older system we had that had a lot of the information segmented into different screens, much of which also wasn't kept up-to-date. Our goal was to identify what information was necessary for our users and make it easily available, cleanly and concisely, in an all-encompassing dashboard.
After project discovery sessions and investigating our users, I went through a series of wireframes and hi-fi examples that divided the view into the two necessary server groups and provided the users with all the information they required to keep track of the health of the servers and take any further action that might be needed should any of them show up as failed.
Early wireframes showing the different ways to display the necessary server data.
Initial hi-fi concepts showing the early tab system as well as a single-screen direction that featured a server search.
Deep dive exploration into the tabs design styles and much discussion was had about the differences in UI patterns between buttons and tabs.
Through discovery sessions with our previous application, we identified other users who were using the company's older apps to help them identify their server health and assist them with the day-to-day monitoring. So, for my second application with the BB-D team, we again had to solve the problem of segmented server data that was never up-to-date and always very difficult to find in one place for our users.
This time, the ask was more complex, as we needed to show servers in a variety of different locations, as well as all the complex ways that a server could show an error. Through our learning sessions, we discovered that an individual server could throw an error in 3 different areas, on top of the fact that the server itself could become entirely inactive. With that challenge in mind, we came up with ways to distinguish smaller server errors from the larger, catastrophic server failures that would need to be top of the dashboard list to ensure further actions would be taken by our teams to resolve the issues.
Preliminary design layout sketches made to help get the right segments and content areas that would be needed to fulfill the project requirements.
Some of the wireframe explorations showing different methods of displaying the data, including one that features a sliding navigation area from off-screen that is triggered in the main header.
Exploring different ways of displaying server status and data for each of the server location selectors featured at the very top of the application.
In addition to the previous two applications, Ryan and I were also focused on putting together a design system so that we could quickly stand up these new applications with ease. As my first dive into this, I went through the variety of older applications already built by Ryan to identify frequently-used assets and turned them into re-usable design components that satisfied both dark and light mode layouts.
Since this was only my second project using Figma, Ryan was essential in assisting with various component concepts such as variants and properties. Using these, we were able to create a very complex amount of table, form, and layout components using a very minimal set of defined assets. The long-term idea was for us to manage and curate the Design System gradually while maintaining our own project workloads.
The color palette for BB-D was broken out into each design component, each having their own version for dark and light modes.
From project-to-project we would create design guides for the developers illustrating various aspects of the design system, here showing interactivity for hover and rollover state changes.
The next project up was the Account Move Tool. The background of this application was that there were backend accounts that were designated for various locations. Occassionally, it was needed that these accounts be tested, and so the only way to do this properly was to create a copy of the account and migrate it to a different location so that it could be tested without disrupting the original. This was all happening manually, so we stepped in to create an interface and an automation system so that it could be completed easily.
One of the biggest challenges of this project (as is the case for many) was that the ongoing requirements kept growing in scope, and thus it impacted the design multiple times, though I would say - gratefully - to it's overall improvement. The end result was a much simplified application that kept most of the main actions on a single screen and allowed the user freedom while also providing a guided experience where they needed it.
The user flow created by Ryan early in the process. This became useful for understanding the project early on and getting a foothold on where to start.
There was some research and comparisons made over other examples of guided and stepped experiences, since the Account Move Tool would have a similar feature for our users.
The final user experience was greatly simplified and combined different functionality into a single dashboard to allow for user freedom. When it came time for the user to implement a move, our guided experience was then featured.
Like many other projects on this list, this was a project that I joined much later than when it originally started on the BB-D team. The requirements and user flow charts grew to encompass a seriously large amount of functionality that ultimately had to be broken out into three separate applications, each one having a certain connection to the other one, but still able to be standalone experiences in our portal list.
One of the main products in this list was for a System Event Log, which tracked different events that were being created on our systems through a variety of ways. We also needed to display if the event information was valid or not, so we provided a way in the UI to identify faulty events and the users could then click into those events and fix the necessary information attached.
.jpg)
The P6 flow chart that the team created using input from key stakeholders, backend developers, and other internal team members.
I looked at a variety of ways to display the information, ultimately turning to modals to allow the user to dig deeper into each row and expand information regarding a specific event.
Since this project featured our first foray into using complex dropdown selectors, we wanted to ensure that the developers knew how the dropdown behavior was working for the different scenarios that they were being used in the app.
Just like P6, this project was originally started about six months before I even joined the team. Ever-changing requirements and hard-to-understand constraints caused this project to linger and ultimately it was decided that I would come into it with fresh eyes to determine if there was any way to simplify the experience.
The original ask was that we had an internal team responsible for checking on our upcoming national Pay-Per-View events featured on our TV guides. We had online tools available to them for manually logging in and viewing sample devices, set in each market location, which they could then assign a validation check for that specific program on a day leading up to the event. The problem was that this process was extremely tedious and time-consuming, so they needed a unified tool that gave them control to automate certain actions they might otherwise have to do manually.
The original experience had long calendar displays that tried to solve the complex constraints our users had for creating an event validation. While I think the ideas surrounding the UI made sense, the multiple colors and state changes still made a complex problem feel complex to solve and use.
The approach I had when I joined the project was to take the functionality that we needed for the user and filter those down into the components that we already had in our design system, without trying to build something brand new. This resulted in creating a more familiar experience for the application and ultimately made it simpler and easier to use.
Our designs featured a step-by-step process of how our calendar pickers worked so that the developers were fully equipped with what they needed when they went into the development process. Our design hand-offs also feature detailed notes and sometimes flow arrows to help give in-depth insights to each project when it's moved into the dev schedule.
One of the iterations I went through with the design was to feature large calendar picker modals and even examples of large screens embedded with the calendar to make it easier for the user to understand which days were available for an event validation. Ultimately we went with an simpler table-list view since we needed to allow for more complex information.
In the user process for adding an event validation to different markets, I looked at different ways to display the end results of scheduling a validation check to an event, showing the different markets that were scheduled successfully as well as any that may have had errors or scheduling conflicts.
The end flow to the Special Event Validator proved that this was the largest and most complex project to-date while working on the BB-D team. While it was probably the hardest application to design for so far, it was also quite rewarding to be able to create something simple with sound design that would greatly benefit the end-user and make their day-to-day tasks much easier.