How did we make drivers' work lives easier?
With this project, drivers can now skip the time-consuming task of searching for orders and instead automatically pick orders, making their work much more efficient and convenient.
With this project, drivers can now skip the time-consuming task of searching for orders and instead automatically pick orders, making their work much more efficient and convenient.
GOGOX transformed the logistics industry in Hong Kong by empowering drivers to manage their own jobs and income. The anti-traditional model has revolutionised the industry by allowing drivers to independently select orders, giving them the freedom to choose.
Yet it has also created challenges due to intense competition among drivers. The project focuses on designing an alternative order picking flow that prioritises drivers ease while maintaining desired flexibility.
Product manager x 1
Product Designer x 1 (Me)
Data Scientist x 1
Frontend engineer x 2
Backend engineer x 1
Conducted researches
Held design sprint with cross-functional teams to align solutions
Utilising design techniques e.g. flow design, prototyping, mockups, for idea validation
Designed alternative order picking flow and experience
Initiated Design System usage in the team
If you've ever attempted to purchase a concert ticket in Hong Kong or other countries, you've likely experienced the frustration of a perpetually loading page that may result in an unsuccessful attempt to secure one. Similarly, drivers endure this prolonged and draining waiting period on a daily basis as part of their job.
Through driver shadowing and interviews, we observed and consolidated their key pains
Every day, drivers spend approximately 3 hours waiting on average
Considering that drivers need to pick at least 6 orders per day to earn a substantial income, when the picking process median time is 20-30 minutes, they end up enduring this waiting period for a total of at least 3 hours every day
Imagine the exhaustion of continuously tapping on a phone for half an hour, all for the sake of securing just one order
The highly competitive process places immense stress on drivers and often results in complaints. Such concerns pose a risk to the supply of drivers on the GOGOX platform if trust is continuously eroded. It is crucial to address these challenges to maintain a healthy and reliable driver base.
Kickstarted the project with a design sprint session with our scrum team, discussing the latest pain points experienced by users and drawing inspiration from order assignment logic employed in other industries.
Our tactics implies to
Address driver frustration with wait times to prevent them from seeking alternatives to alleviate supply-demand tension
Attract drivers by offering a delight working experience through our app, encouraging them to rely on our platform or even grow the supply base by attracting new users from competitors
Increase the transparency of order competition and grant drivers more sense of control.
Each sprint, we accomplished the following tasks
Image of "Card" showing searched orders numbers
Based on insights from the workshop, the operations team stressed the importance of transparency, leading us to assume that drivers would appreciate knowing the actual number of orders we successfully searched and try matching for them.
Through testing, we discovered that the hypothesis was not entirely valid.
⚔️ Displaying search count can be a double-edged sword
Pros: Provides visibility on the app's matching process
⚔️ Displaying search count can be a double-edged sword
Cons: Users become frustrated when the count keeps increasing without getting a job match
👁 The notification blink effect produces a strong light that causes significant eye irritation
particularly when drivers have the app open in a vehicle. This goes against our objective of enabling drivers to have a restful experience.
❓ The meaning of the FAB design is not clear to users
It obstructs drivers from selecting orders below and leading to mis-click issues. Also, the position of FAB failed to imply the feature is exclusive for ASAP orders only
👥 During testing with our team members, we received internal feedback regarding:
Concerns about increased response time. The flashing screens appearing like a bug.
Similarity between the card design and normal order cards.
To alleviate the feeling of indefinite waiting, we display the estimated waiting time and number of drivers within same location in this iteration.
Additionally, we replaced the FAB with a toggle, implying the Law of proximity, repositioning it to the sub-header as it is exclusively available for ASAP orders, grouping related actions and solving the mis-click issues at the same time.
An overlay is introduced to spotlight the new feature to provide onboard experience.
We also improved the notification animation by replacing the blink effect with a gentle ripple effect.
Through testing the designs with drivers,
✅ We observed that drivers are more willing to wait when provided with an estimated time,
but some still continuously monitor the screen and occasionally toggle the feature on and off as a form of "rebooting" after waiting for some time. In the next iteration, we aimed to explore methods to encourage drivers to remain engaged by demonstrating our understanding of their situation and predicting their next steps.
🤔 But some still continuously monitor the screen and occasionally toggle the feature on and off as a form of "rebooting" after waiting for some time. In the next iteration, we aimed to explore methods to encourage drivers to remain engaged by demonstrating our understanding of their situation and predicting their next steps.
Our aim was to ensure a hassle-free experience for our drivers before an order is matched.
Anticipating that they might reboot, we added a feature that suggests adjusting their filter options just before the estimated time expires. This recommendation is intended to increase the order pool and enhance their chances of getting matched more quickly.
To expedite the launch of our MVP and gather early feedback, I recommended that the team prioritise the foreground experience and concentrate on testing the core flow with beta users. This approach allows us to gather valuable insights and iterate swiftly based on user feedback.
Recognising that many of our drivers may have limited technical expertise, we made a onboarding tooltip to clearly highlight the position and purpose of the new feature to ensure it is easily understood by our drivers.
We implemented the display of estimated waiting time, providing drivers with a clear expectation of the waiting duration instead of an indefinite period. We also enhanced transparency by providing more context and explicitly stating the current situation with relevant numbers and matching results
To ensure that the estimated waiting time does not result in a negative experience for our drivers, we provide prompt suggestions to guide drivers on their next steps. We suggest more suitable filter selections based on past data calculations conducted by our data team.
We employed a combination of sound and visual cues to reinforce the impact of notifications without becoming overly disruptive to drivers while they are in their vehicles. Additionally, we implemented limited background notifications to encourage users to keep our app in the foreground, thereby ensuring a more engaged user experience.
We allocated time for conducting research and designing the background notification experiences. This allows us to carefully refine and enhance the way notifications are delivered to users while they are using other apps or have our app running in the background.
Developers found out possible edge scenarios which may bring confusion to drivers, e.g. orders will not be assigned when drivers are not in service areas. These findings help us to optimise the whole auto-accept experiences.
We measured
Drivers' productivity increased by 160% (tracking the number of jobs completion)
In-app clicks while driving reduced by 80% (reflects less orders picking happened)
Following the beta launch, news about the program spread rapidly among drivers.
Our operation team was inundated with inquiries from non-beta users eager to join our beta group, even willing to pay for entry only to use the feature, which was initially invitation-only.
This leads the team and business go forward to capture the opportunity.
See how we convert this originally UX issue into business chance to generate company revenue.
UX design of the value-added FaaS to empower users by subscription
💰 Generate $300k pm. company revenue
Harnessing the Power of Beta Users for Valuable Feedback
Traditional approach (wireframing, prototyping, user tests) falls short for product and engineering teams.
Beta user groups established for real-world app testing could provide invaluable insights amissing use cases identified, particularly in
Unexpected significance of background notifications discovered.
Decision made to incorporate background notifications in initial launch.
Beta users' engagement proves game-changer for product fine-tuning.
Critical areas addressed before wider audience launch.
Beta users ensure healthier and more successful launch.
PM and team benefited from beta users' involvement.
Taking it One Phase at a Time
Through our journey, we've discovered the importance of breaking down our complex features into manageable phases. By prioritising and focusing on the core aspects, we have gained better control over the number of bugs that may surface. Through focusing on the top prioritises and keep the good-to-have, this approach also allows us the necessary time to identify any missing scenarios or edge cases that require our attention.
By tackling one phase at a time, we can ensure a more systematic and organised development process. It enables us to allocate resources effectively, address potential issues proactively, and deliver a higher-quality end product. This approach empowers our team to navigate the complexities of the project more efficiently, resulting in a smoother development cycle and ultimately a more successful outcome.
Gain support from the business side
Following discussions with the business and operations teams, we reached a consensus to maintain flexibility while addressing driver stress caused by competing for orders when designing the solution. These communication takes time and may be less related to design craftmanship, but it definitely helps pushing the product out og boundaries than simply about athenstics.
Share your ideas with stakeholders as early as possible
During the design sprint, we actively sought input from other stakeholders, allowing them to share their concerns and provide valuable suggestions at an early stage of the process. The purpose of looping them in is not only for more innovative ideas, it is also a bridge to learn their concerns and explore the opportunities on how to utilise their expertise to help crafting a more delight design solution than what a sole designer can achieve.
(screenshot of other team's feedback after design sprint)