View
More

Scheduler

Year
2023
Timeframe
2 months
Client
Meta
Role
UX Designer

Background

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.

LEARN MORE

Problem

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?

Users

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

Requirements

Below are the requirements I have outlined based on my initial conversations with our users.

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.

After speaking with the engineering team, I've established some design constraints.

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 to complete whatever work they're doing.

Other Considerations

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.

  • How should we handle access control?
  • How do we prevent non-owners of the reservation from interfering with 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 do non-owners of the reservation see when they view the robot?

Getting these questions answered by my team helped me understand how the scheduler should be structured.

Design Process

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.

User Feedback

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

Key Takeaways

  • Changes are incrementally made, and the MVP version doesn't have to be perfect.
  • Challenge your assumptions by testing with users. This will validate what's needed and not needed within a project.
  • When creating a new feature within an existing tool, examine how the current information architecture is affected.

Conclusion

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.