Celestial was a brand new design initiative and still required a lot of discovery and alignment. I took some time to review the stakeholders’ vision and understand the practical implications. “Guided workflows” aka “Paths” were terms that appeared a lot. The goal being to reduce training time for new employees and encouraging them to lean on the program to take them through the a step-by-step process of whatever task they’re completing. Device Manager was the first project for Celestial Paths.

I spent a day shadowing Retail Agents at my local Xfinity store to observe their current workflow. This gave me a lot of useful context into the pain points agents deal with. I found that they were swiveling between 4 different programs throughout the day to complete their tasks. I also found that many agents were leaning on the outdated billing system to complete Device Management actions rather than the more user-friendly program because of limited functionality and control.

About a week later, I joined a Network Technician for a day to go on a few jobs with them to see how their work flow differed/overlapped with Retail Agents. While they too need to complete the same Device Management actions, the use cases are different.

I was brought onto this project to lead the discovery effort. I realized that using the OOUX framework would be perfect for this project. Celestial was still very early on and OOUX would be very effective in identifying and organizing all of the concepts in the Frontline “world.”

We began with noun foraging by evaluating existing research readouts, current-state designs and requirements documentation. We highlighted all relevant nouns by color- blue indicating Objects, yellow indicating Core Content, green indicating Actions and pink indicating Metadata.

At this point I began grabbing the other Attributes (Core Content and Metadata) and putting them under above their relevant Object. While we were doing all of this, me and my colleague added all of our outstanding questions and confusions that we would later clarify in validation sessions with our SMEs.

Once we organized all of our existing information, we wanted to collect feedback from our users on what attributes were the most important for them. We expected this would differ between Frontline teams and wanted to ensure we served up the most important information to each user-type to make their job easier. We worked with our UX Researcher to set up a card-sort along with a questionnaire.

It quickly became clear that there were a lot of terms we didn’t fully understand and some that were being used differently between different Frontline teams. Technicians and Retail agents work very differently so this wasn’t a complete shock, but to achieve the broader goal in aligning all Frontline employees, this presented an opportunity to have a large impact. I advocated that we took some time to create an OOUX Glossary that contained all of the terms we were using and roles we were accounting for. We created a working list that we reviewed with our SMEs to get alignment.

We were able to come out of this exercise with an exhaustive list of definitions that would allow anyone to jump into this work and fully understand all of the concepts we were working with. This was used by our Content Strategy team to start a Content Guide. It also proved to be a valuable onboarding document that I later shared out with the broader Frontline design team.

We took all of our objects and cross-examined them with each other to understand if a relationship existed between the two and what the nature of that relationship was. This would be valuable later on in the wire framing phase to see what relevant information we needed to show in the same areas of our screens.

Initially I pushed for Service Blueprints as these are a great way to show a lot of information in the same visual but quickly realized these weren’t exactly what we needed. I decided to “frankenstein” a flowchart format that contained all of the information I wanted to show: the actor, the action, the relevant objects, and the current system used to complete that step.

We identified all actions that could be taken on our core objects (Service, Device and Accessory) and organized these based on role. This was extremely useful in sifting through the different needs of each user and would inform the user controls later on.

Every week the broader Xfinity Design team meets to discuss work in-progress. I used this opportunity not only to show what we had accomplished with our OOUX work, but also explain how this work was applicable to all teams at Xfinity and how they could use some of the documentation we created like the Glossary List and the OOUX map.

As we wrapped our discovery work, the first thing we started was creating user flows for the distinct Device Management actions: Add a Device, Swap a Device and Remove a Device.