OVERVIEW
PROJECT TYPE
UX research & design
Visual design
Process innovation
TEAM
Claire Niemeier
Elissa Carpio
Priyanka Gupta
Hilda Hao
Dharini Chandrashekar
DATE
Sept 2023 - May 2024
THE PROBLEM
The current scheduling and delivery process requires four separate softwares and a lot of time-consuming, manual work for the Department of Environmental Protection (DEP) team. Additionally, information about request updates is not readily available to residents, and even if they call the 311 center, the operators often don’t have up-to-date information.
THE SOLUTION & ITS IMPACT
Our team designed a streamlined, semi-automated tool for scheduling and case management, with an integration for optimized route planning for drivers.
40% decrease in the number of steps needed to clean data and schedule requests
Data flow between systems via API, dramatically reducing the need for application switching
Real-time information about request status, eliminating what was previously a 24-48 hr delay
Let's rewind
Or want to skip straight to the good stuff?
Jump to the solution.
This project was split into five sprints, each four to five weeks long. This structure provided regular check-ins with our client to get feedback and ensure that our direction stayed aligned with their goals.
Understanding the team’s existing process and challenges
Sprint 2Researching potential solutions and understanding technical feasibility
Sprint 3Setting a design direction
Sprint 4Low to mid-fidelity designs and user testing
Sprint 5High-fidelity designs, user testing (round two), and developer hand-off
Sprint 1
Sprint 1 was all about getting an in-depth understanding of the team’s existing workflow, pain points, and goals.
Kick off meeting with primary stakeholders
Full walkthrough of scheduling process with Lina (the DEP office manager)
On-site visit and ride-along with James (lead driver) to understand delivery process
We took everything we learned from these meetings and mapped out a detailed workflow diagram showing the entire process of scheduling stops, delivering/picking up bins, and closing out requests.
We identified the pain points and areas of friction. These came from client input as well as our own insights when mapping out the process.Link to full workflow diagram (FigJam)
Manual and repetitive data cleaning
Before she even begins scheduling, the office manager has to individually download multiple reports from the 311 portal, clean the data in Excel, and carefully review the data for errors.
Drivers also do an additional data cleaning step when they receive the excel sheets for their assigned areas in order to get the data into a format they can bring into google maps.
Time-consuming scheduling process
To get the information needed for scheduling, the office manager generates three pivot tables in Excel and combines them to get total requests per area. She then assigns the thirteen areas across five drivers, factoring in proximity as well as the ideal number of stops per driver, per day.
New pivot tables and excel formulas must be set up each time she schedules.
Manual route planning
Drivers receive an excel sheet with anywhere from 55 - 150 stops, and then have to manually plan out the order in which to make the stops across multiple days.
Seasoned drivers know the area very well and can map out an efficient route, but this is challenging for new drivers as it takes a long time to gain that level of expertise.
24-48 hour delay in information
Drivers make notes and mark off each stop on paper. They typically make two days worth of deliveries before scanning and sending the paper to the office.
Residents are not automatically notified about request updates, and if they call wanting to know if they missed the delivery or pickup, the office team often does not have up-to-date information to answer their questions.
Sprint 2
As we started thinking about potential solutions, we wrote out a detailed list of features and capabilities that an ideal solution would have. Key features included:
Ability to connect to 311 portal through an API
Log-in based permissions to support different roles (office vs driver)
Mobile responsiveness for drivers using tablets on the road
Data table functionalities including advanced filtering and pivot tables
We took our requirements list and conducted a competitive analysis of over 25 software tools like Tadabase, Airtable, Rout4Me, and Onfleet, looking at both functionality and cost.
At this point we were leaning towards using an external software solution, but we were struggling to get any answers about budget considerations from the DEP team manager. Meanwhile, we had two very valuable meetings with the MontCo developer and IT specialists. Our discussions with them opened up two new possibilities for project directions. We presented three potential project directions to our client, and asked them to review the options over winter break.
Integrate an external software
Pros: Lots of advanced functionality including optimized route planning, and customer service support
Cons: Needs to go through budget approval process, and needs security approval from IT
Update existing case management system
Pros: Already approved by IT and has API connection to 311 portal, wouldn’t require new spending, and provides more control over design and user experience
Cons: Doesn’t provide optimized route planning capabilities
Integrate an external software
Pros: Already approved by IT, wouldn’t require new spending, and potential for ArcGIS to be used for optimized route planning
Cons: Would require stringing together multiple tools to meet functionality needs
Sprint 3
Three week delay
The plan was to hit the ground running in Sprint 3 with a decision about the project direction, but in January the MontCo DEP manager left the team suddenly, leaving our project without a key decision maker for over three weeks.
New manager
A new manager came on board, and we quickly brought him up to speed. He was excited about the project and provided some much needed information about the budget approval process.
New information
Due to the strict approval process for government budgets, new software purchases would not be implemented until at least 2026. Given this, we gave a strong recommendation for Option 2, and our client gave the green light.
Pivot Point
To set ourselves up for our design work in Sprint 4, we mapped out the information architecture and created updated user flows for the new system.
Sprint 4
In translating our sketches to mid-fidelity prototypes, our main focus was functionality and flow.
Personal Learnings: Figma Variables
I expanded my technical figma skills by learning how to use variables to dynamically calculate the total counts per driver based on the dropdown selections.
One of our big goals for user testing was understanding the office manager’s thought process when scheduling, and to do that we wanted our prototype to be truly interactive and respond to her actions.
One of the big advantages of this project was being able to work directly with the team that would actually be using our system. We conducted two rounds of user testing, the first with mid-fidelity prototypes, and the second with high-fidelity. We set up scenarios for each user role (office manager and driver) with corresponding tasks, as well as some AB tests. We tested with 2 office managers (via zoom) and 5 drivers (on-site with tablets).
Feedback: Users were confused about where to find key pieces of information and where to enter notes. The fields also appeared to be input fields, despite the fact that most of the information is not editable.
Updated Design: We restructured the information categories so that drivers can easily focus on “Request Info” when making a delivery, and “Resident Info” if they need to contact the resident. An “Activity” section helps the office staff track updates.
Feedback: Residents must enter multiple requests separately in the 311 system (e.g. cart repair and bin delivery), but drivers will handle both requests in one stop. Our initial prototype only allowed drivers to view details for one request at a time.
Updated Design: We labeled requests by address rather than SR number, and added collapsible accordions so that drivers can view the information for both requests on the same screen, while still managing request status separately.
Sprint 5
As the design lead, I was responsible for setting up a design system that could easily be used by all five team members to ensure consistency across all of our screens.
Personal Learnings: Semantic Color Tokens
One thing I found really valuable was implementing a semantic color tokening system.
I established color primitives and then created tokens with semantic naming based on those primitives. This makes it easy for others on the team to know exactly what color to use for things like borders or various button states.
Final Solution
Previous pain points:
The office manager has to individually download multiple spreadsheets from the 311 portal.
Data must be cleaned in Excel and reviewed carefully for errors.
Previous pain points:
As she assigns geographic areas to drivers, the office manager has to balance multiple factors: proximity, ideal number of stops per day, and even distribution of workload.
New pivot tables and Excel formulas must be set up each time she schedules.
Previous pain points:
Drivers have to manually plan out routes for making 100+ stops across multiple days.
Newly constructed homes sometimes don’t show up in Google Maps.
Previous pain points:
Drivers mark off each stop on paper, typically making two days worth of deliveries before scanning and sending the paper to the office staff.
Residents are not automatically notified about request updates, and even if they call, the office often does not have up-to-date information due to the 24 - 48 hour delay in information.
Facilitating team alignment
Bringing together five people with very different backgrounds and experience is a rewarding challenge. It requires balancing efficient time management with a willingness to hear out different ideas and opinions.
Defining terms and explaining ideas with quick sketches is key to ensuring that everyone is actually on the same page.
Designing for flexibility
Visual consistency requires a design system that is both well-structured and flexible. As the design lead for the second half of the project, I implemented semantic naming and nested component architecture so that styles and components could be easily understood and quickly changed if needed.
Staying nimble and pivoting quickly
Hold your ideas and designs loosely, and be willing to pivot in response to client feedback or new information. Making a major directional switch as well as lots of smaller changes and iterations meant that our project stayed closely aligned with our client’s needs.
CLAIRE NIEMEIER
