I led the design of this set of features, managed the relationship with our Product Manager, Product Owner, and the development team, and onboarded new designers to the project. I also worked with our design researcher to organize and conduct research activities.
Product design
9 months
Caitlin Roach (Lead)
Missy Yarbrough
Stephanie Ji
Rebecca de Beer
Radius, RapidDeploy’s flagship product, was a platform for Emergency Call Takers to accurately locate callers. It allowed them to track any movement of the caller, communicate via SMS, and gather additional information.
It also let Call Takers see the location of emergencies that came in via methods other than a voice call, like Text to 911, vehicle crash sensors, and panic buttons.
Existing telephony products, which allow users to answer calls, transfer, call back, etc. rarely contained the ability to accurately map the calls to allow the user to find the correct location for field responders to respond to a call. Given Radius' industry leadership in mapping accuracy, and the fact that the mapping was tied to specific calls, there was an opportunity to bring call control features into Radius and create a more comprehensive call taking product.
Current systems have hundreds of buttons, with telecommunicators not knowing what most of them actually do. Our goal was to reduce the actions down to what telecommunicators actually needed when we knew they needed them. How could we design call-taking controls so the call taker can answer and handle the call as fast as possible in such a time-sensitive, emergent situation?
Telecommunicators are typically sitting in front of 4-8 monitors at a time, with their telephony services using an entire monitor.
To kick off our research, we started by looking into other existing products to understand what telecommunicators were used to. We noticed that these products tended to keep all controls up at all times, resulting in overly complicated interfaces, with very little hierarchy or focus on what a person taking these calls would need at a given point in time. Many of the controls were never used, sometimes because they didn't need them, and sometimes because they didn't know what the controls meant.
These systems were primarily based off of older telephone systems that has been mostly phased out today, resulting in software that feels stuck in the past.
After our assessment of existing products, we asked users to do a couple exercises to determine what controls were most important, and which could either be removed or given less priority. We asked them to rank all of the phone capabilities of usage from Rarely to Frequently and Not Urgent to Very Urgent and we asked users to pick their top 3-5 call controls.
This was initially done with internal SMEs, as we did not yet have access to users.
We also asked them to tell us about their experience taking phone calls in an emergency call center. We sorted that information into topics so that we could easily scan through the insights we gathered.
Based on this information, we began our first round of designs. Our goal was to take a pass at what it would look like if certain features were prioritized or grouped together. These designs would be put in from of users to get their feedback to inform the next round of designs.
After putting the first iteration screens in front of users, we learned that holds and transfers were handled in a different way than we previously understood. This led us to dig deeper into those systems and look at how we should approach it in Radius. We wanted to simplify these processes a bit from what they were in most existing products.
Holds existed in two forms. One type of hold is a system hold -- this puts the call back into the queue for another call taker to answer. This would be used if a user was overwhelmed or needed to pass them off for a non-emergent situation. The other type of hold is a local hold -- this would be used when a call taker needed to look for further information that would take more time than it would make sense to place the call on mute.
Transfers consisted of a cold transfer, a warm transfer, and conferencing, all of which had separate buttons in existing products. Because these all had the same steps, with the exception of deciding to stay on the line or hang up, we felt that they could be a single control.
This was our final design iteration for this project. We took the information that we learned from the research with users, primarily around holds and transfers, and applied it to our designs.
Unfortunately this project was canceled in December 2021 when leadership announced mass layoffs and the end of certain projects, including the telephony effort. This project was, however, one of the most exciting projects I worked on while at RapidDeploy. Our product manager and development team truly understood the time it takes to do good design and research, and made sure that we had ample time to complete that process before they needed to begin developing. It was the first project that we were able to get in front of customers before anything was built and shipped, and customers were excited and very receptive to the ideas that we showed them. Had this project gone forward, I think it had a high chance of success with customers.
