Deliveroo for Android
We started working on our Android app in August last year, so it is fantastic that we have launched. When you work for so long on a project and kind of squirrel your work away, it means a lot to ship something and show people you’ve not just been doodling The Village iPeople for 6 months.
Our team has changed shape quite a bit in the last 6 months. It’s been a bit hectic trying to hire, build and push for as early a release as possible at the same time, but I feel the team we have in place now are the right people to get sh*t done.
And they put up with me, so that’s a plus. 👍
First things first: we have an iOS app, so we’re just going to go ahead and copy that, right? Right? No. You’re wrong, get out.
The good thing about Deliveroo is fortunately we have never had to have that conversation. We started with every intention of designing an Android app that both respected our brand and the material design guidelines.
Having a design team, product manager and business that understands that is a battle won in my book.
I’m also primarily an Android user myself which is helpful when thinking about expected patterns, best practices and working with the development team.
Appy go lucky
So what’s our MVP? We all felt we over delivered on the first version of the iPhone app — we could have realistically launched a month or so earlier — but as I’m writing this Eminem is telling me …
“You only get one shot, this opportunity only comes once in lifetime”
… and you wouldn’t think it but he’s a wise old soul. So, soothsayer Shady, what do you mean?
I’m under no illusion that, with an app, ‘you only get one shot’ is poppycock. But you do only get one chance to launch, and all the hype that goes with that can be damaging if not handled correctly.
So we took learnings from our more established iOS product, and analysed the data to find areas we thought we could trim from. The conversations that go along with this are not pretty, including and not limited to “Can we really cut that?” or “If you cut that I’ll cut you!”. This enabled us to streamline our efforts and get to market quicker.
During development I did a lot of usability testing using prototypes built quickly in Marvel and Principle. This consisted heavily of guerrilla testing in our offices, and also including my girlfriend and my parents who are all Android users (of varying ability). Essentially if they could use it then that was a pretty reasonable validation.
We actually made the decision to redesign the entire checkout screen mid-build due to scalability issues with the first version of the design. Testing interactions with the above methods really helped us validate quickly, under pressure.
We launched a private beta internally for the weeks leading up to our launch. This gave us a lot of valuable feedback from the whole product team and wider company.
You can definitely have moments of panic when everyone has the same problem or requests the same feature. But before investigating bug fixes or new features, it’s important to understand why it’s an issue, in order to prioritise problems against other things you have to deliver.
We are now looking to continually iterate and improve whilst working to our roadmap. We have research sessions in place and are collecting amazing data thanks to our data science team, we run A/B and multivariate tests on our platforms and use this to better inform our decisions.
A massive thank you to the whole team who helped get this project live, but especially to the Android development team of Plato, Ana and Evelina, QA in the form of Ozge and Vanessa, and product management brought to you by Rob and Laura.
I’d apologise for all the Android and “Roo” puns but I regret nothing and you’ve read the article so who’s winning really. 😀