I'm a senior product designer with over 12 years of work experience. I use data and intuition fuelled by experience to make great products, solve user problems and identify new business opportunities.
I’ve spent most of my career working in e-commerce with a short stint in the gaming industry where I've switched from improving conversion to increasing engagement. But I've always had an affinity for e-commerce so I've returned to optimising users' experience while purchasing holiday trips online.
I've specialised in Product Design, Interaction Design, A/B testing, Usability Testing, Data-informed Design, MobileApp Design, Mobile Web Design, and E-Commerce Conversion Optimisation.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
For a long time, the company relied on its apps to offer the users a good post-purchase experience, it was one of the ways it advertised the usage of the apps. For customers who weren’t willing to install it however, questions about the upcoming visit might arise and then users would contact the customer service. In an effort to reduce the number of contacts, it was time to improve the post-booking experience. My role was to redesign the flow once the checkout has been completed successfully, and ensure users can find the right information at the right time, and not be left with questions that would eventually be addressed to the customer service.
This is an overview I made at the beginning of the project to help scope out the changes needed on web and phase them into multiple releases:
And this is how users can go from the booking confirmation page to see their booking’s summary, whether logged in or not, and be able to cancel their tickets:
Below is a better view of the page where users go to see their upcoming bookings, once logged in.
The redesign is currently in development and will be released on the Tiqets website in an A/B test soon.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
While conducting user research amongst the venue customers of Tiqets, we've identified a need for increasing not the number of orders or visitors, but increasing the order value. Museums aren't looking to bring in more visitors, but to increase the amount of money their current visitors spend. On-site, many visitors are willing to buy more than just their entrance tickets, such as audio or video guides, guided tours, souvenirs, food and drink options. But this option of upgrading a museum visit wasn’t available online.
With a business opportunity clearly identified, we've structured the add-ons and introduced a new section in the sales flow. The challenge here is to balance the business needs of Tiqets and their venue customers with the user needs of visitors and still facilitate a smooth process of booking tickets.
This is how the users choose add-ons to their visit in the sales flow of the iOS app:
A better view of the add-on section in the sales flow:
These are some of the deliverables for the project, that give a glimpse into the complexity of the add-ons:
The feature has been released on both the website and the iOs and Android apps at the same time. In the checkout on the web, add-ons were introduced by another team, while my role was to include them in the Tiqets apps. Post checkout designs for all interaction and communication however, both on the web and in the apps, fell under my responsibility, including ensuring that the post-booking experience was consistent across web and apps.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
Until mid 2019, all suppliers were added manually in the Tiqets internal systems, along with all their product information and photos. But the company is growing quickly and having more and more suppliers, big and small, meant that this solution wasn’t scalable anymore. And so a signup tool was needed, so that venues, tour operators, and other suppliers could register themselves directly to work with Tiqets, add their venue information, product information, photos, ticket types, pricing, then go through a review step, and then go live and start selling on the Tiqets website and apps.
I was the sole designer on this big project, working from beginning to end:
Here's the first part of the flow for suppliers to sign up to work with Tiqets:
Not shown here is another part of the flow, where users configure the products they create and which go through an approval process, for which I've also been responsible. That's where suppliers can decide whether to use timeslots, set visitor limits, ticket cut off times, and other settings important for selling their products online. This allows them to manage their sales and their visitor flow bettter - something that has been especially important during the 2020 pandemic.
This tool is now being used for all new suppliers who register to work with Tiqets, and is constantly being improved by another team. The second part of the flow, the product configuration, is being retrofitted at the moment to work with existing suppliers, as well.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
Tiqets suppliers have access to a portal that Tiqets maintains where they can manage some of their information, and where they are able to find reports on sales, visitors, and customer demographic data. But many change requests, especially relating to pricing or availability, were still done manually, via phone calls or emails. The company needed their suppliers to have control over some aspects of their inventory, and so looking together at the most common type of requests, an opportunity was identified: allow suppliers to stop selling for certain dates or timeslots, with the option to also cancel the tickets that were already sold for that time and refund the customers.
I was the sole designer on this project, working from beginning to end, from identifying the business needs, to producing wireframes and getting early feedback from stakeholders, then creating high fidelity designs, conducting user testing with existing clients on a working prototype, through to release, analysing user feedback and identifying improvements.
Here's the flow for suppliers to stop sales on a certain date and cancel already sold tickets:
The ability to stop sales quickly has been an important feature for suppliers, especially during the 2020 pandemic, where in many countries strict rules were in place for maximum visitors within a given time. Tiqets competitors still don't offer this feature to their suppliers, to date.
The biggest challenge in this project has been getting some of the Tiqets employees who used to make these manual changes for suppliers onboard with the project, as a few believed suppliers would still prefer to not do this themselves and keep relying on Tiqets employees to stop their sales. Within a few months however, more than half of the times when the sales are stopped for a certain date, are made by the suppliers themselves. Usage and adoption rate proved the success of this tool. Furthermore, some of the biggest suppliers use it, like Disney Paris.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
TravelBird was busy developing new technology that allowed dynamic packaging of their trips, so that each holiday was made up of multiple products: hotel rooms, flights, cars, excursions, or all of the above – and some of these could be easily swapped out and replaced by another, should they become unavailable. Additionally, it was the perfect opportunity to improve the user experience, and the focus was on price transparency and allowing users the flexibility to customise their trips.
The solution is a modular checkout process, with dedicated steps for each type of product within the trip: information and upgrade of hotel rooms, information and upgrade of flights, adding excursions, etc. with a price overview throughout the entire sales flow.
Here's how users select dates and see prices in the first step of the sales flow:
Here's how users can swap out hotels and upgrade rooms:
Here's how users can choose different flights that suit them better:
The initial release was A/B tested against the old sales flow and was successful at an 8% conversion increase. Multiple optimisations followed, which were also A/B tested to bring smaller, incremental improvements to the user experience, each raking in more conversion uplifts as well as revenue increases.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
More and more, people value access over ownership nowadays. GameHouse believes in this model and they're redesigning their business model to reflect that. For a small monthly fee, users gain access to thousands of games, without having to purchase them individually. Discovering the best game for you is another pain point, so the service relies on a strong recommendation engine based on players' behaviour.
The user needn't worry about downloading, installing, finding their games, or uninstalling once they're done with them. The website will instead allow them to run, but also manage all their games with a few simple clicks. Below are sneak peaks at the main pages of the reinvented service – the home page and game page.
The new website, currently available only in the US, was launched in only 4 months and has reached the same level of engagement as existing, loyal users show, within 2 months.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
My main role as a mobile web designer, part of the Tablet Team within the Frontend Team at Booking, was to improve the experience of tablet users, in small iterative steps. Every change was set up as an AB test and measured primarily with conversion rate, though some other metrics, such as cancellation rates or feature usage, were considered as well.
Below is a screenshot of the search results page on the tablet website. The additions I proposed are: including a tappable map as header and redesigning the search box. In its initial state, the search box is collapsed and presenting the search query the user had done. On tap however, it would expand and allow the user to change any of their search details to perform a new search for accommodation.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
Part of my role as mobile web designer within the Tablet Team was addressing users in different parts of their user journey. The upper funnel users include both visitors who search for a specific destination and have clear dates in mind, but also people who need to be inspired and don't know yet where they'd like to spend their holidays.
Though the work was done in small steps, an overall vision was required. Below is my redesign of the landing page which visitors searching for a certain city would see. It includes a more compact search box, relocated from the centre to the side, giving space to a beautiful photo as the main focus.
Should that city not be the best for the user, other similar destinations were suggested on the bottom. The goal was to inspire users, and so drive conversion up.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
In the past few years, Booking.com has expanded into the small properties market. And while the managers in large hotels knew how to use Booking's Extranet (think something along the lines of Excel) for adjusting rates, discounts, updating photos, descriptions, amenities, viewing and managing reservations, and many other tasks, the average small property owner felt overwhelmed by the many options. And they, in turn, would overwhelm the account managers with question over the most basic tasks. And so, together with a front-end developer, we designed, prototyped, and done usability testing on a simpler, lighter tool that would cater for small properties. Our 2-man team grew after a few months to almost 10 designers, frontend developers and copywriter, as the need for more building manpower became obvious.
The tool had to be responsive and cater to non-tech savvy users, unfamiliar with the industry jargon. Any unclarities, confusion, and most importantly, telephone calls to the account managers, needed to be minimised, if not altogether eliminated.
Below are 2 of the most important pages of the tool, where the user could manage their rooms' availability and their incoming reservations from the main website.
Best viewed on higher resolutions, but if you insist, go ahead and read about this a bit, no screenshots though.
A few years ago, Booking.com decided to create an online registration tool for all accommodation types, from large hotels and resorts, to tiny B'n'Bs, apartments, or spots in camp sites. This tool needed to be responsive and easy to use for both travel industry professionals and non-tech savvy users who are unfamiliar with the industry jargon.
Within a a few months, myself and a front-end developer had designed, prototyped, and done usability testing of the tool. Our 2-man team grew after a few months to almost 10 designers, frontend developers and copywriter, as the need for more building manpower became obvious.
Below are only a few screenshots of this tool, including the most complex step of all: creating rooms.
The screenshot below shows the complexity of creating a room within the tool. Depending on what the user had inputted in the previous step, the tool could offer the correct version of room (is it a hotel room? an apartment with several bedrooms? or a campsite?) and make it as clear and easy to use as possible. The pricing section, including possible discounts, would change dynamically to make sure the user understood exactly what rates they were setting. Most interactions were reiterated upon based on feedback received during usability testing performed on real-life users.
Once the user had added all the info about their property, they would be able to preview it in a format as close as possible as the one the guests would see their place while searching for rooms to reserve on the main website, booking.com. Everything was of course editable, should the user notice they'd made a mistake.