Drop me a line.


I’m currently open to full-time product, ux, and ui roles in the the following regions:

• San Francisco Bay Area
• Milan, Rome, Florence
•Paris, Lyon, Marseille, Nice
•Berlin, Amsterdam, Rotterdam

Startup™ — Dispatch Experience

Product + UI

FoodDeliveryStartup™ is a conceptual… well, food delivery startup. It was a design challenge I undertook to exemplify my process, further explore the native desktop and mobile application space, and to diversify my visual design capabilities. My role was principle designer for this exercise, and the initial exploration & design timeline for a minimum viable product was limited to 12 hours.


Having no previous experience designing for a delivery service, I approached FoodDeliveryStartup’s dispatch experience from a very tactile perspective.

The first task that I identified was to create a comprehensive list of requirements based on user objectives. I focused on objectives tied to functional features which a dispatcher would rely most heavily on, and what emerged were the following:

  1. Log in
  2. View active deliveries
  3. View delivery details
  4. Assign courier to delivery

Initial hand written list of requirements

Initial hand written list of requirements

User Flow

The flow that emerged centers around the user assigning a courier to a new delivery request, presumably the primary task once the user logs-in to the tool.

Given the time constraints, I worked in low fidelity sketches at every stage in the process before moving on to creating higher fidelity artifacts.

Notebook sketching is a method that I rely on heavily in my process, as it maximizes productivity, easily conveys concepts to stakeholders, and is apt for rapid iteration.

Initial hand written list of requirements

Refined, high fidelity user flow artifact

Low fidelity UI concept sketches

Mid fidelity UI concept sketches


After ideating over the user flow, I began to draw rough sketches to flesh out the user interface concept.

Low fidelity sketches evolved through iteration into mid fidelity sketches, as concepts were further explored.

Interface Design

As I began exploring the interface design it became increasingly evident that the dispatcher’s map should be not just readily accessible, but completely ubiquitous throughout the various workflows. It became both a centerpiece feature in and of itself, as well as a background element and visually textural component.

In light of this central map concept, I chose to utilize this overtly familiar texture (both visually and tactically) as the background of the login page.

01 ‐ Login

A new user prompt was intentionally omitted, as this would be a restricted feature with access given only to higher level users (i.e., administrators, managers, etc.).

User avatars would automatically populate once a user has entered their login info, provided they had previously logged in on their current device.

02 ‐ Dashboard, Default

  1. Default dashboard features panels for:
    • Active Deliveries
    • Unassigned Deliveries
    • Couriers
    • Messages
  2. Map is prominently featured in the negative space created by the panels and showcases unfiltered courier activity & location.
  3. Individual panels expand to a ‘take over’ view when clicking the icon.

03 ‐ Dashboard, Message Detail

  1. Message details can be accessed by a single click.
  2. Automatic predictive message prompts were considered as a future-state feature, which would include custom user-created messages.

04 ‐ Dashboard, Courier Detail

  1. Courier details can be accessed by a single click.
  2. User can view the courier’s transit capabilities, status, and estimated time to completion, as well as a timeline snapshot of their current delivery.
  3. Courier detail panel offers the user the option of contacting a courier via the messaging panel, or through an in-app audio call.

05 ‐ Dashboard, Active Deliveries Filtered

  1. Active deliveries can be filtered by their status:
    • Deliveries being picked up
    • Deliveries being dropped off
    • Deliveries at risk of meeting their estimated delivery time
  2. From this state, at risk deliveries can be selected in order to alter routes, assign a new courier, or take other corrective actions.

06 ‐ Dashboard, Delivery Selected

  1. Selecting an active delivery populates its location details on the map, as well as the assigned courier’s location & details.
  2. Further actions would be available upon clicking the icon.

07 ‐ Assign Courier to New Delivery

  1. Engaging a new delivery’s icon from the Unassigned Deliveries Panel (on the Dashboard screen) isolates the delivery details and expands a list of active couriers.
  2. On the map adjacent to the Assign Courier panel you see the delivery’s pickup & dropoff locations, as well as the most direct route between the two points.
  3. Courier’s locations & trailing marquee can be seen on the map.
  4. Upon assigning a courier to the selected new delivery, the user would receive a success message & return to the dashboard screen.


Prototyping, testing, and further exploration would be the ideal steps following this exercise and before moving into the development phase.

A full food delivery service design exercise as a larger project would require building out user personas and creating flows for the various job functions or user types. This would include various workflows for deliery drivers within a native application, as well as workflows for customers creating new orders in both native and web applications.