Client: Meta • Role: Senior UX Designer • Project Duration: 4 months
The Problem
Illustration from Storyset
Currently, users cannot assign a workflow (task) to a robot in advance. Because there's no reservation system in place, it is difficult for users to share a robot without disrupting another person's work.
There are 58 robots, each at a different Meta-owned site. As we increase the number of units that are deployed, we need to find a way for our users to efficiently use our robots.
Who are we designing for?
This tool primarily targets these Meta employees:
01 Robotics engineers
02 Site logistics analysts
Illustration from Storyset
Requirements
What are our users' expectations and how can we fulfill them? How will the scheduler affect our users long-term experience and ultimately, is this solving the pain points our users are experiencing?
Below are the requirements I have outlined based on my initial conversations with our users.
Illustration from Storyset
The scheduler needs to:
- Give the user visibility into what has been scheduled / what reservation is currently pending
- Allow the user to assign a specific workflow for the robot to run during the reservation
- Have editable reservations (whether it's updating the reservation details or discarding the reservation)
- Convey the robot's availability to the users
Constraints:
- Reservations can't overlap each other.
- Only one workflow can be assigned to a robot at a time.
- There's no way of estimating the duration of each workflow due to multiple variables. Therefore, users must provide their best guess as to how long they need the reservation in order to complete whatever work they're doing.
Other considerations:
- How should we handle access control?
- What do non-owners of the reservation see when they view the robot?
- How do we prevent non-owners of the reservation from interfering an ongoing reservation?
- How are we planning to account for the time needed to charge a robot? Should charging be integrated into reservations automatically?
- How should we handle errors (e.g. if the timeframe the user has selected conflicts with another reservation, if the reservation is unable to be successfully created, etc.)?
- What would our users like to be notified of (e.g. runtime errors, workflow results, etc.)? How would they like to be notified?
- What are the pros and cons of having the scheduler as its own independent tool vs embedding this feature into our existing robotics tool?
Image from Storyset
Design Process
Illustration from Storyset
After thoroughly understanding what the design parameters are, I started reviewing existing products similar to what we plan to create. One notable tool that I took inspiration from is Meta's internal calendar tool, which is something that all Meta employees are familiar with and use on a daily basis. Given the frequency this tool is used, I felt it would be good to mimic the visual language and behaviors from it while adhering to our internal design system framework.
Initial concepts
After a series of design critiques and collecting feedback from our software team, there were a couple of items that needed to be changed based on technical constraints.
01 Allow the reservation form to have two states: read-only and edit mode. I originally planned to create separate components for when the user is viewing and editing the reservation, but later recognized that it would simplify implementation if it could all be distilled into one component. This avoids the need of creating and maintaining a whole new component.
02 Reservations cannot be bulk created, edited, or deleted due to technical feasibility. As a result, users need to manually create multiple reservations in order to achieve the act of creating a series of reservations. Another solution to mimic this bulk creation behavior is to allow the user to select the start/end date and time and repeat the workflow during that timeframe. The drawback to this solution is that the robot would continuously be running, with the exception of charging when it's at its low battery threshold, without giving other users the opportunity to use those robots on those days.
User Feedback
After releasing the initial MVP (minimum viable product) version of scheduler, I interviewed 5 users to get their thoughts and first impressions.
One of the most frequently received pieces of feedback was about the performance (speed). The amount of lag users were experiencing from our tool made them feel frustrated, which consequently affected how they perceived the scheduler. Also, given that we were unable to provide the ability to create recurring series due to technical feasibility, users had to manually create multiple reservations. For some users, creating multiple reservations for the month may take over an hour. This was the biggest pain point and often discouraged people from wanting to use this feature.
The feedback I've gathered was crucial in helping me discover software bugs and areas of improvement. After evaluating each piece of feedback, I was able to sync with the software team to prioritize the changes needed.
Illustration from Storyset
Updated design of Scheduler
One surprising thing I've discovered from our users is the need to view the calendar in different timezones. As of today, many of our users need to schedule workflows for different regions and therefore, need to manually convert their local timezone to another timezone. This likely contributed to the length it took for some users to create the reservations. As a result of this, I've decided to add a timezone selector in the header so that the selected timezone can be applied globally to the site.
To solve the issue of users having to manually create multiple reservations, I've added the option to create a recurring series in the reservation form. This feature would greatly reduce the amount of time users spend on creating reservations for the month. In addition, this would create more flexibility for users when it comes to planning multiple workflows/reservations ahead of time.
Final Thoughts
Illustration from Storyset
As the second designer on this team, I was able to help shape the design process for our team and to emphasize the need of good user experience for our software and hardware products. Moving forward, I'd love to reconnect with our users to see how this feature can be further improved.