1 week
Design Challenge
UX Designer

Design Challenge

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.

User Feedback

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

  • Frustrated with traffic and street parking.
  • Gains about 30 minutes or more when commuting during rush hour.
  • Estimated difference between driving from home to school during regular hours and rush hour: 28 minutes vs 1 hour
  • Often checks Google Maps and other navigation apps to understand traffic patterns.
  • Feels that there is a learning curve for non-locals when traveling to a new city.
  • Learns traffic pattern through trial and error.

User 2

  • Generalizes rush hour based on typical work schedules (8 AM - 5 PM)
  • Likes to focus on the road without any other distractions, such as a phone.
  • Stresses about arriving on time when there is a scheduled appointment.
  • Estimated difference between traveling from home to LA during regular hours and rush hour: 1 hour vs 1 hour 40 minutes
  • Plans ahead when driving by going over directions.
  • Memorizes directions to familiarize himself with street names and exits.
  • Doesn't use any map navigation apps when driving.

Pain Points

Based on my conversations with

The scheduler needs to:

  • There are too many parameters that the user needs to set before seeing traffic pattern results.
  • Accidents can contribute to traffic and cannot be foreseen.
  • Traffic may vary between weekdays, weekends, and holidays.
  • Traffic can also be affected by unexpected weather and road conditions.

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


  • Schedule button
  • 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.
  • Reservations can't overlap each other.

Information Mapping


  • Drives a car
  • Likes to plan ahead
  • Wants to avoid traffc
  • Frequently commutes to new and/or different places

Assumptions About Users

  • Organized
  • Easily stressed and/or frustrated
  • Learns traffic patterns through trial and error
  • Dislikes driving during rush hur

User Tasks

  • Inputs current location
  • Inputs destination
  • Adjusts time to see traffic patterns based on the day of the week
  • Analyzes traffic patterns


  • How might we allow users to easily view traffic visualizations?
  • How might we integrate other information, such as accidents or road conditions, into traffic visualization?

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 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



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.


  • 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.

Final Thoughts

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.