Currently, we do not have the exact number of users who have shared their location access with us. This project aims to support customers in picking up their purchases in events where location permission is disabled.
- Led and oversaw the design from project inception to development
- Designed the entire flow & interfaces
- Keep customer-centric in mind by validating flow and getting feedback via UT
- Work closely with PM & engineers by initiating recurring design reviews and briefings
For new users, location permission dialogs are shown upon app launch. As there is no explanation on why we need their location, some users may intentionally or unintentionally skip it.
Also, there is no proper location handling in the app, so if users do not allow location permission, we assign them a fake location and refer them to a default store; otherwise, they would not be able to see what is available in the menu. That is when the problem happens, as their orders might end up at the wrong store, leading to post-order cancellation via the help desk.
As a result, users might face these problems:
- Seeing fake and inaccurate distances on the app
- Missing out on choosing the relevant/nearest store to them
- Orders going to the wrong store
- Having to cancel their orders via the help desk
And it also causes a lost of sales for the business.
- Reduce customer help desk requests
- Reduce order cancellations due to the wrong store selected
- Reduce the number of order refunds due to the wrong store selected
- Reduce the number of instances where users miss out on choosing the relevant store
- Getting users to allow location permission
- Improving the user experience for app users
At the initial phase of the project, I started by looking at how other apps (Foodpanda, GoJek, Panera) design their location sharing features. A common pattern that I discovered was these apps provide very clear instructions to the users, to get them to allow location access, otherwise they will not be able to proceed with the task. Clear UX copy helps to communicate and inform users why location access is necessary.
In order to get clarity on when to get users to share their location, I've mapped out the flow to visualise how first-time users and returning users will go through the ordering process.
First-time users will have to follow through with the onboarding flow where they have to allow notification and location permissions.
1. If users allow location permission, they'll go to the menu page where they get to browse and order.
2. If users don't allow location permission, they'll have to manually select a store or allow their location.
Through reviewing what others have done and thinking radically, I took on a fresh look at the issues and explored various possibilities on how we can help users with selecting a store and enhance the user experience. During the design reviews with the PM and engineers, we discussed and also got an alignment on the key goals to focus on. Certain features, like allowing users to select their country will have a lot of downstream impacts, as different countries have different points systems and payment processing considerations.
From lo-fi sketches to hi-fi build, I explored having a map view to allow users to zoom in manually on a particular area and select the relevant store. This will be helpful for users to understand the store information visually, at the same time they can see the different landmarks near Flash Coffee.
To facilitate discussion and visualisation of how the map view could work, I've done up the user journey and prototype. We also had many discussions with the team to discuss the feasibility of releasing this feature within the targeted timeline. However, after much consideration, the team agreed that the map feature would be decoupled from the project and KIV for future enhancements. It would be out of scope and wouldn't fit into the timeline.
Currently, users are immediately bombarded with permission requests or location and notifications upon app launch. This makes it easy for them to dismiss to “get it out of the way.” Thus, part of the design proposal includes staggering the permission request.
The solution is to introduce a new onboarding screen that explains to users why they should allow location permission before they see the pop-up.
Instead of a full-page overlay, we designed a half-bottom sheet that communicates and directs users to make one out of two decisions. This intention is so that users will still get a snippet of the menu and campaign banners at the back. I partnered with legal to shorten the copy and had a couple of users look at it to see if they understood the messaging.
On the menu page, there is a sticky snack bar that reminds users to share their location. We want to introduce friction and get users to allow location sharing so that we will be able to serve them more accurately and provide a better ordering experience.
After internal usability testing and iteration, we arrived at the final design. Upon app launch, if location permission is not enabled, existing users will see a bottom sheet where they can either, allow location access or manually select a store before ordering their drinks.
Tapping on allow location access will direct the user to the settings page. Once location permission is given, the menu will be updated to show what is available in the store nearest to the user. If the user manually selects a store, the store list will be shown to them, and they can quickly get to the store they want via the A-Z scrubber.
Link to Figma prototype
I have learned so much through this project. As a product designer, I think it is important to acknowledge the constraints and, at the same time, challenge the boundaries to strive for greater results. Always take the initiatives to uncover the unknown and gain clarity on the subject matter. Be open and gather feedback during every phase of the project, as this can help to improve the work.