ZEUS
TM
A seasonal scheduling application designed for warehouses during the peak holiday season.
PROBLEM
(Short on time. Click icon for quick summary)
You have 42 days to find a way for DSG Distribution Centers (DC) to efficiently and effectively schedule the expected increase of seasonal employees so the company doesn’t have to rely on
temp agencies and temp employees.
Hiring several hundred temp employees for the Christmas Holiday Season is very costly.
Managing schedules for seasonal employees proved time consuming and frustrating for managers during the busiest shopping season of the year.
Seasonal employees want to earn as much as they can during the short holiday season.
Role:
Responsible for the entire user-centered process from research to executing a solution based on research findings and user testing.
Team:
1 Designer, 3 Engineers
Timeline:
09.2019 - 11.2019
Disclaimer:
Due to the type of work domain, I’m limited in the amount of work I can display publicly.
{ Additional commentary in red }
SOLUTION
Deliver a scheduling application that allows managers to schedule and publish open shifts, view who’s working, and edit shifts; while also allowing seasonal workers to view and accept open shifts via mobile or desktop, and see future schedules all in real-time.
My task was to design an experience for both managers and employees that was easy to learn, able to be accessed quickly, and solve the main objectives in a matter of seconds.
PROCESS & APPROACH
How were we able to build our solution in such a short time?
The following is a high level breakdown of our approach:
Week 1: Research / Evaluation / Design Studio
Week 2: Design / Backend Infrastructure
Week 3: Design Feedback / Backend / Front-End / Iterate
Week 4: Demo / User Test / Feedback / Iterate / Front-End
Week 5: QA / Test / Fix
Week 6: Deploy
RESEARCH
Due to the limited amount of time we had to deliver a solution, our research process had to be quick, but effective.
Week 1: Research / Evaluation / Design Studio
We met the stakeholders and users onsite at the DC, and we needed to learn what they needed versus what was a nice to have.
We toured the facility to observe the workspace.
Our team spent time interviewing, asking questions, and observing to learn behaviors and gain insights from the stakeholders and users.
A design studio was conducted with our stakeholders and users to identify possible solutions and create more discussion around needs vs. wants
{Normally, I wouldn't design by committee or involve users in the design process, but with an extremely short timeline having their input of what they needed and expected was helpful}
After the onsite, our team discussed roadmaps, feasibility, design, and business value.
We realized we could:
-
Help the company reduce labor cost
-
Deliver a quick solution
-
Make it scaleable for future adoption
Web App vs. Native App
Because of the time constraints, our team decided creating a web app would give us a good solution that was functional and cost effective.
Web Apps:
-
Have a common codebase regardless of mobile platform.
-
Do not require app store approval (iOS & Android), so can be launched quickly.
{Having to create an app for both platforms would require more cost and time to build, and need approval}
-
Easier and quicker to build than mobile apps.
-
They don't need to be installed or downloaded. They function in-browser.
{Anyone could use with an internet connection}
-
Are less advanced in terms of features, and generally are slower than mobile apps.
{Users would not need advanced features}
-
Compared to mobile apps, web apps may not be discoverable because they're not listed in a specific app store.
{No need for discoverability; app would be given to everyone upon employment}
DESIGN
Laying the foundation for the solution.
Week 2: Design / Backend Infrastructure
While the engineers worked on the backend, I started crafting a solution based on the research.
Pen & Paper
We stayed in constant contact with our stakeholders and users through emails and video conferencing to get answers we needed, provide updates, and keep everyone aligned.
Receiving feedback and iterating.
Week 3: Design Feedback / Backend / Front-End / Iterate
I conducted a Design Critique session with other designers to get their feedback on heuristics and overall experience of both mobile and desktop solutions.
After implementing suggestions from the critique, I reached out to our users to ask follow up questions.
{Questions centered on scheduling details, types of shifts, and employee statuses}
Feedback was shared with our engineers, so they could complete the Front-End work.
Design Critique
TESTING
User Testing and iterating.
Week 4: Demo / User Testing / Feedback / Front-End / Iterate
We developed a prototype for our users to test. The testing was conducted remotely via webcam and teleconferencing so we could see them working with the prototype in real time.
Initial feedback from user testing was positive. I made slight adjustments to words used within the UI that users mentioned was unclear, and made a couple of elements more visually prominent.
Changes were implemented and we moved to Quality and Assurance.
Testing and Quality Assurance (QA)
Week 5: QA / Test / Fix
Product Teams at DSG do not deploy any products without going through a QA process. The process helps catch deficiencies or problems before products are released.
QA identified a few minor bugs our engineers were able to fix quickly.
Minor issues were addressed and we received the green light from QA to deploy.
DEPLOY
Outcome.
Week 6: Deploy
In 42 days we were able to build a seasonal scheduler application that removes scheduling frustration and allows employees to pick up open shifts on any device in real-time.
We delivered the solution before the holiday deadline with both desktop and mobile applications working successfully.
Previous:
Next: