Native POLA
Overview
POLA = Private OnLine Advertising. Auto Trader’s platform allowing consumers to list their car for sale.
Our goal for this project was to bring the Auto Trader private selling process fully inside our iOS and Android apps and optimise the process for those platforms capabilities.
Problem statement
The current selling experience through our apps, was broken with users being taken out of the apps and into a mobile web experience, which utilised none of the extra capabilities of the app platforms.
Users and audience
Users wishing to sell their car through an Auto Trader app platform.
Roles and responsibilities
Lead product designer for this project working within a team consisting of another product designer, product managers for both the app platform and the selling process, tech leads for each platform, a team of developers, front end developer and QA. This project included close collaboration with the research function within Auto Trader.
Scope and constraints
Project would be delivered in iterative, smaller chunks, so the design of the process needed to take that into account.
Our process
Designs Sprints are a great way to get the right people in a room, free of distractions, to focus on a particular problem. Our POLA sprint began with a day focused on context. Product managers provided the business context for the why of including the selling process with the app platforms. Designers, with help from research, provided the context of current usage and the problems users are currently encountering when placing an advert through one of the apps. In the weeks prior to the sprint we had run a number of lab sessions with users to observe how the current execution is used.
A journey map allowed us to see a holistic view of the process and to see how we could tackle individually parts of the process and also gave us the flexibility to test and challenge the order of the process. This map proved invaluable post sprint, when we set about tackling the rest of the process.
Enlisting the help of customer services was huge help and provided the verbatim feedback that this team encounters every day on the phone. All these things allowed us to map the problems currently faced and pick the first part to tackle that offered the biggest impact.
Combining the data digging and the verbatim feedback we found that image capture / upload and payment were the 2 biggest problem areas for us, with images on android in particular a huge problem with a large drop off at that stage. With focus areas decided, the team split into 2 to tackle each area, with my team focused on the image problem. After a couple of days idea generation, looking at app and device specific capabilities, research, sketching, iterating and iterating some more, we got to a prototype we were happy to put in front of some users on day 5.
With script written it was time to put our hard work in the hands of some actual users for the first time. Whilst software such as InVision and Axure are great for prototyping there is nothing like sitting with a developer and building a fully working prototype in whatever language they are using, Xcode/Swift in this case. Testing went well with users enjoying the new process and lots of learnings taken such as, when starting the selling process users would already have taken their photos. This help dictate the order of options between ‘Photo library’ and ‘Camera’.
Following another successful round of lab studies with users we were confident enough to build and launch that part of the process along with a new entry screen. As these new parts successfully launched, we were iterating on the other parts of the process, testing these with users and adding into the build.
Through these series of experiments we learnt:
Users preferred to enter their car details first before adding photos - this meant the entry screen was iterated on
Users preferred the process to be on one page rather than stepped out as a process like the current execution
Users felt a little weirded out with some of the pre-population, so trust message were addd where that pre-population had occurred
Users were already very comfortable with the native payment options such as Apple Pay
Outcomes and lessons
Being one of the first times we had used the Design Sprint process at Auto Trader, you could see the benefit of having that time to work as a tight knit group, free of distractions and the importance of some of the subject matter experts who set the context nicely for us.
The launch of native POLA has had a positive impact on the app experience for Auto Trader, reducing the amount of complaints both to the customer service team and through App Store reviews and direct feedback in the apps.
As a result of native POLA;
Revenue per customer increased from £4.90 to £7.65
Conversion rate increased by 13%
Decreased the drop off rate from the images/photo section by over 10%
A full end to end app and device specific process
