There are 58 robots currently operating at various Meta-owned sites. These robots work autonomously and perform a range of functions, including collecting environmental data and taking rack images. As we increase the number of deployed units, we need to find a way for our users to use our robots efficiently.
Users need to manually start a workflow and monitor its progress.
To reframe the problem, how might we enable users to run workflows efficiently and clearly see who is using a robot and when?
This tool primarily targets these Meta employees.
Site Logistics Analysts
Robotics Engineers
Both users can work onsite at the data center to troubleshoot issues or remotely manage these autonomous robots to gather data and assist with onsite problems. In either case, their goal is to manage these robots efficiently and effectively collect data.
The most significant pain point for these users is manually assigning workflows to robots. To do so, they need to be sure that no other users are currently using the robot to prevent any disruptions to other people's work
Below are the requirements I have outlined based on my initial conversations with our users.
.svg)
The scheduler needs to:
After speaking with the engineering team, I've established some design constraints.
Constraints
To better understand how we should integrate a scheduling system within the robotics tool, I communicated the following questions to the rest of the team.
.svg)
Getting these questions answered by my team helped me understand how the scheduler should be structured.
After thoroughly understanding the design parameters, I started reviewing existing products similar to what we plan to create. One notable tool I took inspiration from is Meta's internal calendar tool, which all Meta employees are familiar with and use daily. Given the frequency with which this tool is used, I felt it would be good to mimic its visual language and behaviors while adhering to our internal design system framework.
One notable feature of the Calendar tool is the ability to create a recurring series of events. Some users hinted at wanting this during my initial conversations with them. However, after speaking to the engineering team, I realized this feature was not feasible for MVP (minimum viable product).
An alternative to that feature? A solution that the engineering team and I agreed upon is to allow the user to select the start/end date and time and repeat the workflow during that entire timeframe. The drawback to this solution is that the robot would continuously run, except when charging. In addition, this would reduce the robot's availability, making it more difficult for other users to use, especially if the robot is reserved for many months.
After releasing the scheduler's initial MVP version, I interviewed five users to gather feedback and first impressions.
One of the most frequently received feedback was how time-consuming creating a reservation is.
Creating multiple reservations for the month may take over an hour for some users. This was the biggest pain point and often discouraged people from wanting to use this feature.
Hearing this feedback validated my initial assumption when creating the scheduler: users want to be able to make a recurring series for a reservation. The feedback we gathered encouraged the engineering team to prioritize the original implementation of the recurring feature.
With the "Create a recurring event" button in the reservation form, users can now specify how often and when a robot should be reserved. This feature would greatly reduce the amount of time users spend creating reservations for the month and create more flexibility for users when it comes to planning multiple workflows/reservations ahead of time.
Before
After
One surprising thing I've discovered from our users is the need to view the calendar in different time zones. 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.
Updated design
As the lead designer for this project, I had the opportunity to go through each design phase in-depth, from research to concept ideation to testing, etc. I've also learned how to optimize our team's design process and be a better advocate for our users by engaging them earlier in the process. This means documenting our users' current process of operating a robot and pinpointing places of friction.