— Context The main source of revenue for Welcome Pickups was ride bookings made through its website, typically for rides from the local airport to a hotel somewhere in the city. One of the main business goals was increasing that revenue. The primary way the product team could achieve this was by increasing the conversion rate from landing on the site to a paid booking.

There were serious restrictions: the site was a critical part of the business, the code was very complex, and the team had limited resources. This meant we had to be very careful, prioritize changes well, and introduce them incrementally.

— Research To identify problems that could prevent users from completing their booking, I began analyzing the data we already had: form statistics, click maps, and session recordings. This revealed several issues: high drop-off rates on certain fields, attempts to submit incomplete data, clicks on unclickable elements, and the lack of attention toward blocks that were considered important.

Next, I conducted a short series of tests with people similar to our typical bookers. They uncovered usability issues on mobile devices, a lack of adaptation for non-EU users (currency, time), problems with selecting pickup times and editing information from previous steps, along with a bunch of other issues and observations.

Initially, this provided enough information to start cooking up fixes. As this was a long-term initiative, I later used additional research methods to uncover more issues and cross-check the existing ones. These included competitor research, surveys, a fake support chat, analyzing customer reviews and support tickets, and interviewing our support agents.

— Solutions All identified problems and potential solutions were compiled into a table, which I shared with the product team to gather feedback and generate more ideas. Together with the main stakeholders, we brainstormed and prioritized the items based on potential impact, confidence, and complexity. This table became the key resource guiding our roadmap for this initiative.

There were 3 main lines of work: improving basic usability, reducing friction, and informing the booker.

I started with basic usability, as it was the simplest and highest-confidence area. I ensured the interactive elements were large enough to tap, the correct mobile keyboards were triggered for each field, the dropdown elements were displayed within the viewport, the Back button was handled predictably, etc.

Reducing friction involved two approaches. First, I set smart defaults for fields where I had high confidence about what the booker would choose. From analyzing the stats I knew that most bookings were for two adults with two large pieces of luggage, from the local airport, and so forth. The second approach was adding tools to help bookers with the fields where they were struggling. I added a flight finder, a pickup time assistant, a better calendar, mobile payment methods, and a number of smaller tools.

The final line of work was informing the booker. I showed more important selling points, provided richer information about the ride, car, and driver, and explained what to expect after booking and upon arrival.

I quickly validated most of the changes with users via high-fidelity prototypes before handing them off to developers. Once implemented, we launched them through A/B tests and used the results to determine the next steps.

— Results A good percentage of the experiments were successful, leading to a double-digit increase in the overall conversion rate and revenue, while support costs dropped by a similar percentage. Besides the tactical improvements, I also refreshed and simplified the UI as a whole.

See the old version. The final version is below.

— Context Driving travelers around is an operationally difficult business. People cancel their trips, change booking details, get lost in unfamiliar places, flights get delayed, drivers get sick, etc.

At Welcome Pickups, the situation was especially bad due to broken communication between the company and riders. Rides were booked through a website, and riders received a series of emails with their booking and driver information. If they needed to make changes to the booking or had any other issues, they had to find the right email, contact support, and communicate with an agent via email. It was a bootstrapped solution from the early days of the company that generated a ton of expenses and friction.

To optimize costs, it was decided to enable travelers to self-service instead of going through customer support. Additionally, we thought we could improve the customer experience and get more people to book with us again.

— Research There were 3 personas involved in the book-to-ride chain: traveler, support agent, driver. To understand the problem space, I needed to see it from all 3 sides. I talked to our customer support agents and cross-checked what they said with ticket history and internal statistics. I already had some insights from the drivers because I had worked on our driver app previously. On the traveler side, we had first-hand experience since I, other team members, and their friends were Welcome riders, plus I analyzed support tickets.

This information helped identify most frequent and expensive issues, as well as their place in the ride lifecycle. Most of them revolved around not getting the emails with ride and driver details, not being able to change or cancel bookings, not having an internet connection in the destination country, and not having an easy way to find and communicate with the driver before the ride. The majority of the issues seemed solvable by riders themselves if they had an easy way to access up-to-date booking information, manage their bookings, and communicate directly with their driver. This suggested that we should build a traveler app.

The app had to be available on the web, Android, and iOS, but we had very limited resources to develop it. So we needed a cross-platform solution, and we needed to confirm if it would improve the numbers in a lean, cheap way.

— Solutions We brainstormed the top problems with the product team, came up with various solutions, assessed their viability and technical complexity, and selected a few core features that would go into the MVP. I made several interactive prototypes at different levels of fidelity, got stakeholder buy-in, quickly tested them with potential users, and eventually arrived at the final design. It was implemented, launched, and quickly gained noticeable traction.

After confirming the potential, I started adding more features to the app, which were launched one by one. The workflow at this stage was more lightweight – I already had the roadmap with all the required data and only needed to discuss the technical limitations with developers and get the UI right, which I did by stealing learning from best-in-class products. Besides automating the ride lifecycle, I worked on improving and simplifying users' travel experience overall, as well as upselling extra services.

The biggest difference was having all booking information in one easy-to-find place, keeping it up to date and reflecting any changes that happened after the booking (including when there’s no internet), allowing the rider to edit and cancel bookings, providing a map to help find the driver, and giving an easy way to call and chat with the driver.

— Results Along with the changes in the booking process, the app reduced the number of support tickets by 3X, improved customer satisfaction, and significantly increased the number of returning bookers.

— Context Managing ads is a labor-intensive process that involves a lot of trial and error. That's why big companies hire specialists to do it. They handle hundreds of campaigns, with thousands of ads, each having about a hundred different assets and settings. This requires a way to view large amounts of information simultaneously, along with specialized tools to filter specific subsets of ads, view their contents and statistics, and perform mass actions.

Direct Commander was a tool made for these people. However, it had been designed years earlier, when advertising volumes and complexity were much lower. The team had been making iterative improvements to the app, but they didn't work well and didn't fix the fundamental flaws of its design. Users complained a lot, and at a certain point, it became clear that a full redesign was necessary.

— Research When I joined, the product owner had already conducted a lot of research. He had identified the biggest pain points from the years of user feedback, interviewed users, analyzed internal statistics to uncover usage patterns, and conducted competitor research. Together, we reviewed the list of problems, discussed potential solutions, gathered technical requirements from developers, and I began working on mockups.

— Solutions I started with the main working area. Iterated on it with the team, moving from lower to higher fidelity assets. Eventually, I created a prototype that we tested with users and adjusted based on the issues that were found. Once the main area was done, I repeated the process with the numerous secondary tools and windows, and finally, with the combined prototype of the entire app. The product was very complex and expensive to develop, so we wanted to derisk our solution as much as possible before any code was written.

The overall focus was adapting the UI to the actual user workflows. Key changes included more compact tool panels, which freed up space for ad panes, a more customizable working area, easier context switching, an inspector panel that allowed quick access to all parameters of selected items, and one-click synchronization with the server. I also made the UI more predictable and aligned the behavior closer to Excel, which was a favorite tool among our users.

Once the final tests and adjustments were done, the app went into development, and my role was to ensure the quality of the implementation from a design perspective.

— Results After completing the alpha stage, we released a public beta, which received great reviews from users. The developers were pleased as well, since they had a fresh codebase and an interface that was easy to build on.

See the old version. The final version is below.