Take any type of commuting method; this could be a train, bicycle, bus, car (possibly self-driving), or even walking, and evaluate, analyze, and improve that experience.
The main objective is to thoroughly unpack the experience you choose into smaller interactions and analyze every touchpoint to define the pain points and opportunities. The secondary objective is to come up with creative and insightful solutions.
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.
User 1
User 2
Based on my conversations with
The scheduler needs to:
After speaking with the engineering team, I've established some design constraints.
Constraints
Demographic
Assumptions About Users
User Tasks
Challenges
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 for feedback and first impressions. One of the most frequently received pieces of feedback was how time-consuming the process of 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 implementing the recurring feature as intended initially
Before
After
With the "Create a recurring event" button in the reservation form, users are now able to specify how often and when a robot should be reserved.
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.