a lesson in communication
Project Orchestra, otherwise known as ORCA, was initiated to reduce the complexity of an aging and inefficient oracle application (Atlas) that was used to provision services such as VOIP phones, internet, and more to over a thousand university staff. Key goals included expediting standard service request time, identifying and automating tasks prone to human error, providing visualization of business processes, and reducing training time for new hires by providing more user-friendly interfaces.
I was onboarded on the team after high-level business requirement gathering was already completed. As the project was agile, we focused on releasing product in modulated pieces through bi-weekly sprints. My role on the team was to conduct user research, wireframing, and design iterations on the VoIP phone provisioning process.
Atlast 2015. Not the prettiest interface out there.
To begin, I studied the work domain and attempted to digest the complexities of VoIP phone provisioning through reading broader business documentation and requirements. After becoming familiar with the process, I and a UX GRA (Graduate Research Assistant) shadowed the service provisioning team (SPT) through recorded video work observation. We collected and synthesized work activity notes into additional requirements by tagging source IDs and maintaining work domain perspective.
I was tasked to present our findings to the broader team which included developers and functional team members. Mid-presentation, confusion emerged over my use of the definition of a “port.” In response, I repeated what was told to me by the SPT team- but I could not manage to explain it. Turns out, multiple definitions of “port” were being used throughout our internal team and the SPT team. Some understood the “port” as a plug in a wall, while others understood it as part of the closet in the provisioning process. Regardless of the definition, I was unable to deconstruct and explain a part of the flow in simple terms during an important meeting. To address this, I created a shared google doc of terms and definitions for all relevant stakeholders to use moving forwards. In the future, I made it a priority to understand concepts through cross-functional dialogue instead of just individual research.
Before beginning any wireframes, I identified critical incidents and iterated back and forth between the SPT team and our internal team on any confusing patterns of behavior. I then mapped out flow models of the interractions and steps needed. To aid in visualization, the UX Lead tasked us to make crazy eights to develop design implementation ideas. From our collective ideas, we were able to build a rough low fidelity storyboard prototype of the port assignment process.
Upon further iterations with the users and developers, we started building mid-fidelity prototypes as well within UXPin (credit to my GTA partner, Zoey). Using UXPin as an interraction base, we were able to conduct usability tests before moving on to a higher fidelity prototype. During one of our demoes in this stage, a key stakeholder identified missing information in our available ports table which both the internal team and SPT team were unable to comment on. As a result of our visualized prototypes, a problem that could have taxed the project heavily was easily addressed in another round of iteration. Upon finalized review from all team leads, we were ready to build our high-fidelity prototype.
Using bootstrap, I started creating a high fidelity prototype for our users to experience. To show all possible routes within the port provisioning process, I created three possible conditionals: one to illustrate a denied request, one for a successful request, and another for an automatic assignment.
Mid-Fidelity UXPin Prototype
High-Fidelity Bootstrap Prototype
It took a while to understand how Atlas worked. It took even longer to understand how VoIP phone provisioning took place. In fact the author of The UX Book, Dr. Hartson, takes a small jab at the UX nightmare it created for our university. As a UX designer with a business background, acquainting myself with unfamiliar client domains is supposed to be my strength- but at the time, the scope of the task seemed to be too much.
Hartson discusses these wicked problems as a natural part of domain complex systems which are characterized as having a high degree of intricity and technical content in the corresponding field of work. In order to bridge between analysis to synthesis, Hartson stresses the value in walking the WAAD to extract needs and requirements. This process is about immersion with a team which is precisely what I neglected to do after collecting raw activity notes during my shadowing process. Rather than organizing these notes and taking a top-down approach with a team, I attempted to make sense out of hour long video recorded sessions on my own.
Working on ORCA was a lesson in communication. Challenging problems are better solved when more brains are involved. I have reaffirmed the value of gathering as many perspectives as possible in person-to-person dialogue before attempting to come up with meaningful solutions. Reflecting on this, I feel more prepared to tackle domain complex systems and am eager to properly engage a cross-functional team in a WAAD building session!
Dr. Hartson knows the struggle
(pg 790, The UX Book)