Part of the project brief is to look at various company workflows and do a field study to collect payment user flows from different applications to analyze what works well – and if so, would we be able to implement these in our products… It is essential to review and conduct an app dissection to check what is the common convention and design patterns that could potentially solve the problem.

After creating the prototype and presented to the whole team to get a “tech check” we can then start doing the prototype we can all agreed to work with to bring to the usability testing. Having a “tech check” in the first couple of meetings gives you an understanding on what can/can’t be built within the constraint of the platform. That will give the whole team a level of confidence too, to make sure we can deliver or descope the features if needed.

After a couple series of usability testing, there is already a good amount of hi-fidelity design to be presented and get reviewed by week 4. As part of agile team, the devs can now look at the shared prototype so we are building and finalising the workflow and checking out the nitty-gritty details of the product.

The product improvement was released 1 week delayed as there are more technical issues needed to be polished before releasing the new feature. The release was well-received by people adding more engagement to the Vodafone app.Prior to the feature release, payment engagement in the app is just 36% of the monthly users. After the release of the feature, the payment engagement spike up to 55% with users storing their cards to the app and making payments through the Direct debit/Variable Credit Card function.