A New Ricardo App - About a data-driven decision and pragmatic approach to an MVP that serves the purpose

Ricardo offers  three physical ways to access the marketplace: A website, an iPhone app and an Android app. A lot of work has been put into the website over the past couple of years. However, the resources put into the apps have been primarily for bug fixing. Observing the overall performance of the three platforms, the Ricardo team realized that while the apps were growing in terms of users and traffic, they should be growing a lot more. So by looking at the data, the team came to the conclusion that the app was the best place to invest.


Phase 1 - Defining the project and receiving the “green light” from the leadership team

Improve the existing app or build a new one from scratch?

That was the first question that came up. Should there be more than one app? Should  features be unbundled into separate apps? Together with the leadership team, Omar, Senior Product Manager, started building  a case around each of these possibilities, weighing up their pros and cons.


What are the costs of a new app?

Omar decided to make a case to the leadership team for a completely redesigned and rebuilt app. Interestingly, the highest cost of this option was the opportunity cost of not maintaining  the existing app while building the new one. There’s a rather small team handling the two apps of Ricardo, but the apps are responsible for about half of Ricardo’s traffic. The team had done a fair job of streamlining the existing apps, automating the flow, and addressing the bugs up until that point. However, If it took up to 6 months to build a new app, the team would not be able to work on improving the existing app during this period.And no one could prove, at this point, that the new app would actually perform better than the old one. So yes, starting from scratch posed a big risk, and the costs of this option were difficult to defend. 


But there was a major argument to do so anyway: The existing apps had been built on technology from three or even four years ago. Ricardo was having difficulties hiring  engineers to work on this outdated technology. What do you do if you are struggling to hire developers for the underlying piece of software for your app? Do you stick to the technology, or do you rewrite the whole thing? 


And so it was decided: Yes,rewrite the apps using the very  best current native technologies (for the nerds amongst us: Swift on iOS and Kotlin on Android).That meant not only redefining the way the app looks and feels, but also redefining it on the software side to put Ricardo in a better position to hire new engineers. 


“It’s been a very fun case to make,'' says Omar.


How to assemble the app team?

The hiring process for app engineers started immediately after the decisionto rebuild the app and change the underlying technology was confirmed. An agency supported Ricardo so that the hiring process wouldn’t take longer than a month. Omar also understood that they would need a lot of support from design and UX research teams within Tamedia,because now the talk was not just about incrementally changing one screen or one button, but actually rethinking the Ricardo product’s entire user journey. 


What side of the marketplace to focus on?

As a two-sided marketplace, Ricardo’s   development processes must account for both buyers and sellers. For Omar, it was clear that focusing on the buying experience should be the first priority. As he put it, Ricardo is a responsive website, so improvements on the buyer side would also positively impact the sellers. Focusing right from the beginning on both sides would have taken up too many resources. 

The selling/ listing experience will be the next step. Here, Omar sees a lot of potential for the listings uploaded via mobile phone... but now we’re getting ahead of ourselves. 


Phase 2 - The execution

The PUX Team came into play from the very beginning:

In parallel to kicking off the hiring process of the new engineers, Omar started to work with the PUX Team. In first ideation sessions, they looked at the numbers of the existing app. Then they defined in a proposal which KPIs to set up for the project. In the end, they settled on a KPI that was the ratio of manual transactions (bids on auctions) and “buy nows” (if the user buys something for a fixed price) of active users (users coming on the app). Every metric or KPI has pros and cons, but there was a fundamental reason why this number was considered the best measure of whether the new experience actually performed better than the old experience: They were only changing the user experience on how users were interacting with the product on a mobile phone, and not changing the fundamental ways the Ricardo marketplace works. The goal to bring existing users who are used to the old apps along was essential. And, of course, some users don’t like change. So here’s another challenge. 


How were the design principles defined?

One-third of users use two hands to hold their phone and type with two thumbs. One-third hold the phone in one hand and use the thumb of the hand that is holding the phone to type. The other third holds the phone in one hand and types with the free hand. The hardest version is holding the phone and typing with the same hand. This became the team’s guiding design principle: It must be easy to use the app with just one thumb, a “one thumb experience” so to speak. A “bid now” or “buy now” button shouldn’t be hard to reach on a mobile phone. The search bar, which is used a lot, should be on the home screen in the centre, very well visible. And no, these didn’t feel like no-brainers back then. In the end, they were simple principles, but different approaches had to be tested first to find out what works best for the user.


How to approach the implementation?

“We found a way in the team to have this pragmatic approach where the design team  was working on the concepts and validating them, and the engineering side was taking these outcomes and implementing them, knowing that maybe a given version was not the last version,'' says Omar. For example, they implemented three versions of the PDP. Yes, implementing non-final versions is never ideal, but on the other hand, you never know which one is the final version.  “There is never the final best version, only the best version so far,'' emphasises Omar.


The newly assembled team decided to work natively in the new technology on the core buying flow: From the home screen- to search results - to PDP - to checkout. To save time and resources, some mobile websites were wrapped into the app. For example, theHa search listings are integrated from the website and haven’t been built natively.  This decision mirrors the tradeoff between the time you need to publish an app and the functionality of the MVP very well.


What did Omar learn from this?

For Omar, it was the last project at Ricardo and accompanied him in his last one and a half years. It involved ideation sessions, preparation, workshops and resilience. But he pushed it to the end and learned a lot about prioritizing, decision making based on data, user research, and defending ideas on their merit. 

 

The Outcome

The app is performing well. The KPIs defined in the beginning show an improvement since mid-November in comparison to the old app. That means in numbers: Since five weeks on the new App version are about 15% of the active users. On average 17.6% of them buy or bid daily. For comparison: On the old version it is only 12.45%. This is a performance improvement of 40.62%!

What would you like to read about in our next "Project of the Month" coverage?