Role

Gogo Delivery for business was a result of the continuous discovery that our PM and I conducted. I led user interviews, conducted surveys, and worked closely with our data analysts to learn more about our users on a regular basis. Based on our learnings, our PM and I defined product strategies that align with our business goals. From there, we defined hypotheses and metrics. I worked closely with engineers and the cross-functional team throughout the ideation and prototyping phase, sought feedback from designers via weekly critiques, and tested prototypes with merchants. For the final deliverables, I worked with designers who work on our Client mobile app and web app to align the UI and interaction, update the Design System if needed, and verify the translations. I discussed the design with engineers and QA during grooming, and design QA’ed before launch. Post-launch, we reviewed the metrics and retrospected.

Research

After launching Gogo Delivery on mobile, we found that a small percentage of our users created a large percentage of orders. Through data and user interviews, we learned that these users were merchants selling food and beverages, beauty products, electronics, and pet products. We segmented these merchants into two groups based on their behavior.

Ad hoc

• Places deliveries when needed
• Requires urgent delivery (like food and medicine)
• On the go, prefers to use mobile

Batch

• Consolidates orders and places orders the day before or in the morning
• Doesn’t require urgent delivery (like wine and electronics)
• Usually sits behind a computer to manage orders on e-commerce platforms

Pain points

Pain points prioritized by severity (in bold) and frequency (highlighted in orange and yellow)

Product strategy

Based on our continuous discovery learnings, we defined what our product should achieve for ad hoc and batch merchants to support our business objectives

• Create a web app that is seamless with the mobile experience
• Simplify the flow for repeat orders
• Enhance the experience for batch deliveries
• Help merchants manage multiple orders easier
• Allow merchants to add team members under one account and view monthly reports to save time on expensing

Web app

For the initial scope, we created a web app with the same functionalities as our mobile app so that merchants who work on a desktop can place and manage orders easier (such as copy and pasting delivery information from their e-commerce platform). The desktop real estate enabled us to create a single form for placing an order without going back and forth between screens, and a table view for managing orders easier.

Simplified repeat orders

We observed merchants placing orders and found that they tend to deliver items to frequent customers with similar package information. Some of the merchants even used the native mobile keyboard shortcuts to fill in the order form easier.

To help merchants place orders, we enabled autofill for the sender, recipient, and package information so that they can fill in most of the form in a few clicks without inputting each field individually.

We also launched “reuse order” under order details so merchants can request an order with the same details easily.

Bulk order

We learned that merchants who consolidate orders and batch delivery orders manage their orders internally using spreadsheets. Some of them sold products on several different platforms, like Shopify, Shopline, and Price. They export spreadsheets from these platforms and combine the orders into one spreadsheet for management. They were also familiar with using bulk spreadsheet import on other logistic platforms. During user interviews, we learned more about their likes and dislikes on the bulk importing experience.

One of the challenges when designing this feature was balancing the error handling experience with technical effort. Our engineers and I narrowed down to three options, from the lowest to highest effort and worst to best experience:

• Returning a list of errors
• Generate a CSV with errors on a new column
• Display errors in an editable table

When I showed these prototypes to merchants, their main concern was the validation handling for the addresses (a limitation with using Google Places) and drop-off times (due to cut-off time rules). We decided to launch a version that simply returns a list of errors to a closed beta group first, while simultaneously working on the editable table.

To reduce errors before import, we added data validation on the spreadsheet template. We also added examples at the top to help first-time users understand what to enter.

During our store visits and taking orders as couriers, we found that many merchants wrote the recipient district and pick-up verification code on labels or directly on the packages. To aid this process, we introduced shipping labels that merchants can choose to print after placing their orders. Interestingly, when we tested this with merchants, some said they still preferred to hand-write to save the environment and printing costs.

Outcome

• Package information autofill reduced time spent on the order form by 23%
• Reuse order contributed to 93% increase in orders placed
• 65% merchants print shipping labels