Progressive disclosure, dynamic interfaces
We have spent the last couple of years optimizing funnels. We had to. When your competition has 4X your cash balance, you have to learn to optimize and get more out of everything: your user, your funnels, and from each transaction that happens on your marketplace. How do you think about funnel optimization? You look at each segment and their journey on your product. New users will always have lower conversion than a mature product. So they need to be treated differently than a mature user. The interface has to adapt to each segment.
A lot of people talk about dynamic interfaces on Twitter. You can take the idea to the extreme: one-time disposable interfaces, on-the-fly generated UI created by AI. But familiarity is important. No user should have to think where the call-to-action button is every time they come to your app. Too much cognitive load for the user. As with most things, the answer is somewhere in the middle. Take all user segments. For all, destination search would be key on the homepage of a ride-hailing app. But the size of the search can change. For a new user, you can use some animation to bring focus on the destination search button. You can hide everything that distracts the new user. Yes, if the user has come from a Facebook ad for rental and then lands on your home, you might want to highlight rental service on the Home Screen, but otherwise you need to make it less prominent vs search. Assume they have come to use your base service.
What matters to the new user? Call-to-action is of course search. They have not even taken a new ride. So they don’t need to have a saved addresses section. There is no one-tap booking because you can’t predict their destination, pickup, service, price, and add-ons. You need to show that they are getting a good deal. So new user vouchers need to be auto-applied. You need to give gratification to the user. Maybe some social proof that they are making the right choice (without disclosing sensitive data, not everyone can be like Zomato telling how many orders they are doing daily).
Once they have taken their first ride and are familiar with your flow, you can start progressively adding more elements on home. An adjacent point: The same component can adapt to do different things too. A card on home can let you do one-tap/quick booking. It can be continue where you left once you drop off and come back to the homepage. It can be return trip booking for daily office commuters. The component adapts based on the use case. Over time your mature users would want you to predict their behavior. Want you to cut the number of steps. Then you focus on power user needs. As I said: One-tap booking, one-tap return booking, etc. can cut the time to book the journey to 1/3 of the time normally needed to book a ride. Now if you have a user segment service that can return the segment to the client, then you can make the whole journey dynamic. Based on action taken on home, your price estimate and service selection screen can change. You can change what you show on finding driver screen. In order summary screen, you can show different components. If it was the user’s first ride, you can ask them to save their destination once the ride is complete. Show gratification around money saved through the voucher. Even cross-sell other services if you are a super app.
The interface does not need to change based on just the user need. It can be business-driven too. Our service selection screen (that I will call estimate screen going forward) is based on a slot system, basically think of everything on the estimate screen as fitting into slots. You can dynamically change the number of slots. And also information on each slot. And each slot can handle different data types.
The image for the service type can be a gif. Instead of showing details about the service, you can have info around how many people that service type can handle. Everything is fluid. Service ordering can be based on surge, time of the day, previously service taken by the user, popular service in that area, new service you want to promote, trip distance, price, ETA, or any business metric you want to optimize. And you can change anything you want from a config service. No back-end service deployment. No client release.
Now, we are the only ride-hailing company in the world that provides multi-modal trips: by multi-modal I mean you can select services for different legs of the journey and book one single order. Services can be in-house or external. You can take base ride service for first leg of the journey to metro, middle mile metro ride (we have partnerships with public transportation services), and then final leg on ride economy. So our service selection screen needs to handle multi-modal too. We should also be able to upsell all 3 legs. Imagine the complexity. I can go on and on, but hope this gives you an idea around how to think about different funnels and how your interfaces can adapt to their needs (as well as your business).