The Problem
After analyzing the app, I noticed it lacked some features that could make the use of it much more fulfilling for users. I made a list of the ones I considered most relevant:
- As a user who orders for several people, I want to be able to split the payment
- As a regular ordering user, I want to be able to save favorite restaurants
- As a user, I want to be able to see restaurants that are closed and will open later
I conducted guerrilla interviews to find out which of the features the user valued most. Being able to split the payment was, unanimously, the most desired functionality. So I decided to develop this one.
The Solution
On a privacy level, dividing the payment among several people generated some reticence among users, since none wanted to enter their bank details into someone else's phone. I determined that the best way to solve this was to integrate Bizum. This way, the user who places the order can request a Bizum from the rest of the users when finishing the order, without the need for anyone to provide their bank details.
User flow
When it came to splitting the payment, there were two possible scenarios: splitting the payment equally or having each user pay for things separately.Taking into account these two options, I worked out the user flow:
View user flow
Wireframes
With the user flow defined, I proceeded to design the wireframes, so that they would be integrated with the current Deliveroo architecture:
High Fidelity Prototype
Basic Styleguide
Once the wireframes were defined, I made a basic styleguide with the elements I needed to develop the feature, following to the Deliveroo look and feel:
Mockups
Time to color the wireframes. I created the mockups following the basic styleguide and, once completed, I built the hi-fi prototype to test it with real users.
Prototype
Next Steps
During the tests, the users understood perfectly the workflow of the divided payment, except for the final step. When it came time to request payment through Bizum to the rest of the users, the testers didn't understand what they had to do. To solve this, perhaps it would be appropriate to create an intermediate screen just before the final payment, so that the user understands that they must perform one more action before paying.
