City of Dearborn Response Center workflow redesign
Context
When? What? Who?
Helping Dearborn’s Response Center improve their workflow by using low-cost, immediately implementable solutions.
Year
2023 Fall
Role
Research, design strategy
Team
Self + 4 UX designers, developers
Context
Desktop software, SaaS
Background
So what's the problem?
The City of Dearborn Response Center, which provides a central resource to both other Dearborn departments and Dearborn residents, was struggling with an inefficient workflow that ultimately increased their workload and frustrated Response Center employees, residents, and other city departments. We conducted research into the root causes of this inefficiency, initially ideating on a bespoke solution but ultimately finding an immediately implementable solution that met the client’s needs and conserved their resources.
Background
Who?
The Response Center is staffed by three primary employees and one manager, fielding an average of 300 resident calls a day while collaborating with over seventeen departments. They manage these calls by recording data in multiple Google Forms, transferring calls, and occasionally drafting emails or taking additional measures/accessing additional software.
300 calls visualized.
Research
Round and round the workflow goes
The Response Center’s workflow is highly circular; after a resident calls in, the response center logs the call and redirects the call. Despite the call being logged, there’s no system for tracking whether a request is completed. As a result, residents must call back to check their request status, increasing call volume.
Research
Let's break down the issues
There are several key issues in the current workflow.
Collaboration
The Response Center has to transfer a large portion of calls without any guarantee that the calls are received and/or requests addressed
Repeat callers
Residents have to call back if a transfer fails and/or to get information on the status of the request
Wasted time
Switching between, filling out, and searching through multiple forms takes extra time and effort
Research
The Response Center's core requirements
Based on the issues encountered by the client, we identified several key requirements.
Centralize information
Speed up client work, reduce tools in use
Versatile ways to understand requests
Enable residents to find their own request's status
Enable staff to look up past logged requests/calls
Ideation
Those requirements look a little something like this
Ideation to meet our requirements included switching between multiple views (table versus map versus dashboard), request IDs and search functionality, flexible forms that modify the fields to be filled out based on the preceding answers, etcetera. We reviewed our sketches with our user group for feedback.
The pivot
Wait a second—this is all sounding a bit familiar
After ideation, we found that our requirements were easily filled by an extant product (Monday.com) already in use by the City of Dearborn, and to which the Response Center already had access; as a result, I suggested that perhaps we should revisit it as a potential solution.
We had previously discounted this tool as part of the department's problem based on an interview with the manager, but we backtracked in our design process to do a little more user research and investigate why this software wasn't being utilized.
The pivot
Why the Monday blues?
After further interviews, we learned that the rejection response to Monday.com was primarily an emotional one, a combined result of intimidation and workload. Monday.com posed a substantial learning curve in order to set up a workflow in the way the Response Center needed–one with responsive forms and robust automations. These were viewed as complicated and difficult, so much so that our client didn't know where to start and didn't want to try.
Complicated forms
Difficult automations
Overwhelming choices
The pivot
Coming up Monday
While Monday.com naturally had some drawbacks in complexity, we felt these drawbacks were no less in complexity than the drawbacks inherent to the systems we were proposing–features such as responsive forms and table views. We also identified several key benefits that Monday.com could have for a government entity.
Overall, proceeding with Monday.com conserves resources, provides an immediately implementable solution to an immediately pressing problem, and leans into a product that already has some buy-in within the client organization.
New design
Monday
The solution
Mondays are pretty nice, actually
We assisted our client in setting up a comprehensive, responsive Monday board with automations, in addition to the corresponding child boards (these boards are located within the official government account and contain the Personally Identifiable Information of residents, and thus cannot be shown). This master board included a form that linked out to multiple departments and sent automatic updates to relevant personnel; rather than requiring these individuals be contacted by phone, they are able to complete tasks and update information in Monday, which many of them were already doing for other work.
the solution
Monday.com as the solution
Not all departments are yet integrated into this solution, but this represents a material step toward two-way communication which will reduce repeat callers and increase transparency both internally and externally while also reducing the time taken to log caller information.
This also provides a forward-thinking solution that can flexibly adjust as departments onboard to Monday, in addition to giving the Response Center flexibility to add and subtract from the information to be logged in their tracking forms.
Centralize information
Speed up client work, reduce tools in use
Enable residents to find request status
Versatile ways to understand requests
Enable residents to find request status
Enable staff to look up past logged requests/calls
Reflection
Looking back
This project was really interesting and fairly unconventional compared to my previous UX work. It posed the unique challenge of not designing something new, and to be very honest, some teamwork challenges came with that.
Several of my teammates weren’t very enthused about my idea to research the client’s hesitancy with Monday and the potential utility of Monday. They wanted to design something new and pursue a portfolio piece; I strongly disagreed with that. The Response Center had a problem now, had access to this tool that could solve their problems, and there was no need to waste money and resources chasing a bespoke solution that could be years–and hundreds of thousands of dollars–away.
To be very honest, the overall team enthusiasm waned greatly after we pivoted into working on the Monday solution. I felt very responsible for that since I was the one who suggested and advocated for it; I did what I could to boost morale, and I was very intentional about thoughtfully bringing people into discussion. The team did come together in the end, and ultimately I strongly believe this was the better solution for the client.
Nonetheless, it was a learning experience to navigate between the competing interests of what was best for the client and what my fellow teammates preferred.
