01: Research
Hot Seat Tech Permissions
User Flow
01.a: Initial PO Debrief
In order to gain a clear understanding of what the scope of this project was, I first met with the Product Owners to go over what they had already been discussing with stakeholders. The request itself was fairly straight forward. Users wanted a way to have one our our technicians sit in on their calls to help with anyone that may be experiencing any difficulties.
Key points:
This will affect both users and internal company personnel.
Managing the needs of both parties will be paramount
Simplicity on the user-side / thorough on the internal components.
01.b: Research Strategy
With everything provided to me in the PO debrief, I was able to being conducting my own research. I wanted to focus on several areas: would this be an addition or a rework of existing flows, what are the full permissions provided to the hot seat tech, and how does this affect both the admin and client side of meeting management within our platform?
My research plan was as follows:
Investigate any other tech support lines from other video conferencing platforms in order to discover any documentation specific to in meeting technicians.
Interview internal support team to determine internal scope.
Review any user data or requests surrounding this topic.
Meet with lead developer to go over their epic to discover any limitations on their end as well as to discuss the findings of my research.
01: Research Findings
Users Come First
The results from my research couldn't be more clear, focus on the user first! Our internal support team assured me that they could handle the potential flow of new request for technicians. A direct quote from one of our technicians was "we can handle who needs to be where on our own". So taking that quote as a base for my approach to this design, I focused on the external users needs primarily. This actually meant far less work for me in the long run but significantly more thought process would need to be put into the layout of any additions I made to existing flows. I took this chance to explore where I could best find an integration before I started my design work. I found that there was actually a very large cross over and even a dependency that would affect the hot seat technician baked into another scheduling flow. This radically simplified the work yet again and helped me narrow down the scope of this project.
The takeaways from research:
Work within existing flows given an existing dependency.
Explore opportunities to integrate with external facing teams
CX (customer support)
Court Reporting
TX (technical support)
2 approaches to take when addressing this issue
separate step in the flow
integrate into existing page
Challenges discovered:
Company wide layoffs resulted in the loss of the primary developer on this project. Time had to be allotted in order to bring other developers up to speed.
Managing visual clutter: discovering the tie in to the existing scheduling flow was great but it also meant an additional layer of wire-framing/researching into possible new layouts to accommodate the additional feature.
Navigating company goals vs user goals: discovering the tie in to the existing scheduling flow was great but it also meant opening up the conversation surrounding potential marketing/sales opportunities within the platform. I wanted to refrain from introducing any unnecessary sales material into this process, especially with our companies very loose pricing structure, as I felt that it would only introduce confusion and potentially create a stopping point for some users.
02 : Design
02.a: Base Design
The base of this design was actually very simple. A nice selection allowed for easy navigation and in a familiar look and feel to the other pathways in the platform.
Points of consideration:
Scope alignment had been an issue when communicating with stakeholders, so I wanted to provide simple UI that could be easily modified given how often the scope would be adjusted.
I wanted this to mimic our in-platform experience as much as possible given that we were still very much in the "first impressions" stages as a company.
Although the goal was to reuse as many existing assets as possible, the dev team did want to explore what all Fluent UI had to offer and so we utilized their break point structure in the short-term with plans on incorporating more in later iterations.
02.b: Edge Cases
This was where the bulk of the work was in this project. While the base design was simple, there were far too many "what if?"s that needed to be answered. The largest percentage of those edge cases would be centered around its' connection to a users ability to schedule a court reporter. The tie in to the court reporting flow meant that we now had to make sure we didn't introduce any issues within their workflows as well. Additionally, the head of court reporting saw this as an opportunity to tie our hot seat tech role into our "white glove" service that we offered when a user requests a court reporter from us.
Edge Cases Continued
Court Reporter Dependency
Not only were there limitations based on availability of personnel, but our court reporting team felt it necessary to fully lock the hot seat technician scheduling process for arbitration completely unless a court reporter had also been scheduled first. These variables were introduced during the design phase of this project, so being able to spin out these designs quickly became prudent to the success of this project.
Post meeting creation addition
Since this feature came out post launch, users would need to have a way to back fill previously scheduled meetings with hot seat technicians. Providing an option to add one quickly, without the need to go back through the meeting creation form, allowed for a freedom to schedule at any point (within the given time restrictions and meeting type limitations).
Party Based Support
Now that may be a bit misleading but what may seem to be a relatively simple question at first turned out to be a painfully long back and forth discussion over the placement of the hot seat technician. Our marketing and court reporting teams felt that placing the technician within the paying party would incentivize non-paying users to join and have access to the perceived "exclusive" content. However, I argued that it was more appropriately placed within the unaffiliated category since the support team provided help to every participant in the meeting regardless of payment or not. unfortunately, stakeholders felt that the marketing opportunity was to great and we proceeded with the party based location for the hot seat technician.
01 Simple designs ≠ Simple solutions
With such straight forward designs, it was easy for me to begin to feel like I wasn't fully accomplishing the primary goal of this project. It took navigating the edge cases that arose and regular check-ins with stakeholders to assure myself that the lack of initial UI didn't mean that we were forgetting about any aspects of the user flow. It helped me to take a step back sometimes and look at the project as whole.
02 Documentation is key to navigating transitions
Having thorough design notes and a fully flushed out record in Jira helped make the transition between developers much easier than in previous projects. It's never fun losing a developer, especially one you have built a good relationship with while you worked together. That is why having a solid backlog of information was helpful when bringing on the new developer to the project.
Info Dump
Testimonial
"Jacob joined the company well before me and was responsible for all aspects of design. He’s got a good eye, works fast, and has a keen sense of what users do and do not want. Every interaction I had with Jacob was positive and left me feeling like we were moving in the right direction. Given the quantity and variety of tasks set before him, all of which he excelled at, I believe Jacob gained a multiple of the experience he would have gotten in the same period at any other organization."
