AirPortr is an on demand bag check-in and delivery service currently operating in London.
Before I start, I'd like to clarify what the service does... We collect and check in your bags onto your flight or deliver them to the airport... or take them from the airport and deliver to any address in London. I'd also like to explain why I call it system. The reason is that it's not only the booking form, but quite a few products that are really interconnected and they all work together to achieve the end goal which is happy customers and more bookings for us.
From the day I joined I started analysing how the product worked, understand the needs of the business and objectives as well as going through zendesk tickets to get a general feel of the complains that users have.
With that in mind I started analysing the current booking journey form as that was the main thing I started working on. I started mapping out which screens we need, which ones we can merge to make the flow quicker and easier as well as really transparent and easy to understand.
The journey had 3 main flows... ABC - Bag check in to British Airways, SDS Outbound - delivery to airport, SDS Inbound - delivery to your London address and two additional... CCD - carousel collection - later abandoned and finally ATA - Airport to airport - which we managed to incorporate to the each flow.
The flow quickly transformed from this to that. As we had to launch all of the above as well as new e-mails home page etc. I combined flow and wireframes in one. It’s not the best idea, but it helped me get on track quickly. That flow went through a lot of iterations even after we started working on the actual pages as we discovered many new things which could be improved. We came to these conclusions sometimes through user testing the prototypes, and some of them just by looking at them and discussing them with other team members.
The main thing at that point and pretty much at each point is getting these problems, insights or assumptions and translating them to a design that later you can test out. Then get what you’ve learned and translate to an updated design. I think that’s the most important part, because each project or job is different and needs a different approach. There’s never one solution and each one of them has to be tested.
The main challenge on that flow was keeping it as consistent as possible despite of the differences on each flow. In that sense we reused quite a big part of the screens and logic and some of the pages like log-in or flight search are the same. Reusing elements increases speed later on.
We also had to upsell Bag check in on SDS Outbound so that was taken into consideration. But maybe the hardest part was creating a flow for connecting flights and final destinations that was easy to understand for a first time user.
Small changes like showing how the price changes when you add an extra bag or showing clearly the product type while booking make a lot of difference on the client side. I can keep on going with all the small details, but it might take forever.
One of the main issues we had after we launched was the address step where the drop off rate was 47.5% which considering was early on in the flow had a really big impact on the overall conversion.
Once we had the new address step up and running, the conversion rate slowly started increasing and improved with nearly 3% which had a really good impact on the business.
Meanwhile I started working on both e-mails and “My account” which also had some complexities, as we wanted to store customer data (addresses, payment methods and names) for fast check out (for repeat users). That meant I had to go back to the booking flow and start investigating how that would change specific steps. Understanding e-mails meant I had to understand the whole customer flow process (how you get your bags picked up and delivered or checked in) as well as how the concierge app works.
I created 37 e-mail templates that had to have specific information for the customer (when to pickup bags, when they’re getting delivered. If there’s delay, what happens. How do they get notified, how does that connect with the concierge app and bag tracking system). You can look at them here.
After everything went through a lot of iterations and tests and reviews and design work, we started dev work. Here not everything is always done. Although most of the things were decided and thought through with dev teams, product owners etc, sometimes things come up, or because of timing some things need to be simplified or changed.
Shortly after that I started user testing the dev version of the booking form and My account and home page, as that gave us an insight into how to adjust certain interactions etc. Things that you can’t really test through a static prototype (or at least not that well). Was also involved in helping out with booking form testing, logging bugs and helping to manage the team and priorities for the release.
If you liked that, you'd' most probably enjoy these below... take a look.