I decided to make a sitemap after getting frustrated with navigating the mobile app. Above was a summarised version I used in the presentation. The one I did for the research phase was much more detailed.
Tiffany O'Keeffe
UX Designer
Thérapie Clinic Booking App
Enhancing the experience to reduce cart abandonment
COMPANY
Thérapie Clinic
PROJECT DATE
March 2021
MY ROLE
Product Designer applicant. Competitive analysis, sitemap, journey mapping, wireframing, interaction design, visual design
PROJECT SUMMARY
This was the design challenge when I applied for the Product Designer position at Thérapie Clinic. The task was prepare a prototype to test a new potential user flow, which will result in reduced cart abandonment and increase in conversion.
This was the design challenge when I applied for the Product Designer position at Thérapie Clinic. While my application was unsuccessful, I put this up here as a case study to show a glimpse of my process, how I think, and how I could approach a problem with limited resources and time. The brief was sent to me end of day on a Friday and I needed to present the following Tuesday early afternoon.
The Challenge
Thérapie Clinic has identified an opportunity to capture substantial revenue lost through cart abandonment in their web and app booking flows. One of the central elements of their strategy in 2021 is growth so they are targeting a 100% increase in conversion this year.
The challenge was to select what appeared to me to be the most immediate opportunity for improvement and to prepare a prototype to test a new potential user flow. They asked to see at least one opportunity or problem to solve and at least one prototype to tackle it.
The brief also stated that they fully understand that in a normal working environment there would be more research and validation before jumping into a design solution. The objective was for them to see an output that reflected my thinking, my abilities, and how I work.
Disclaimer
As the challenge was concerned with conversion, I made the assumption that the booking flow referred to revenue-generating bookings. My prototype did not include the online shop for skin care products or free consultation flow. But I did go through them while I was testing the app and took note of opportunities for improvement in those areas in a separate document – not required, but also submitted to Thérapie Clinic.
Research
Mapping the journey
I started with mapping the booking flow on both their web and mobile apps as a new customer then as an existing customer. I listed all the things that I saw as opportunities for improvement as I went through the flows.
I identified different types of products that can be added to the shopping cart – free consultations, treatments that require booking appointments upon purchase, treatments that do not require booking appointments (pay per session and courses), and skin care products. I was only able to complete the checkout process on free consultations as I was not willing to give my credit card information without the assurance that I can easily cancel and get my money back. Interestingly enough, my research unearthed that cancelling an appointment as a new customer cannot be done online and one had to ring them to do it.
After getting a bit frustrated with navigating the mobile app (particularly with menu labels not corresponding to the page titles and bottom accordions expanding off screen without auto-scrolling), I decided to make a sitemap – more for myself than as part of the challenge submission – to get a better understanding of the app. This meant going through the online shop flow (which uncovered a pain point relating to booking treatments, which I will get into later) and all other flows. The sitemap helped me see where I can possibly reduce the number of pages and streamline the booking when I got to the wireframing stage.
I synthesised my findings at the end of my research and divided my list of opportunities of improvement into five categories. Items that I saw as immediate and/or easy to implement were included in my prototype.
I then went to the Google Play Store, Apple App Store, and Facebook for the closest thing I can get to anything about the user – actual user feedback. It was interesting to see that some of them were similar to the pain points I experienced, like the booking process being too long and issues in rescheduling.
I performed competitive analysis of other booking systems in the same industry, including Urbana, Sensius, The Buff Day Spa, Browhaus, MindBodyOnline, among others. Some of the aspects I compared were number of steps, number of screens, and service offering.
The analysis showed that booking a treatment with Thérapie Clinic takes twice as many steps than Urbana. The latter also required only a €1.50 booking fee while Thérapie Clinic required that the full amount be paid upfront. During the presentation, I raised that this could be one of the reasons for cart abandonment but I did clarify that this was merely a theory and needed to be validated.
I synthesised my findings at the end of my research and divided my list of opportunities of improvement into the following categories – Experience, User Interface, Content, Accessibility, and Check in Questionnaire. Items that I saw as immediate and/or easy to implement were included in my prototype.
In an ideal working environment, these would be some of the things that I would look for as part of my research :
Where does cart abandonment come from – new or existing users?
Which type of product is more likely to be abandoned?
Where in the booking process do they drop off?
Which device is more likely to have cart abandonment?
Prototype
Customers can access Thérapie Clinic's booking system via web app and native app. I designed my prototype mobile first to ensure responsiveness on any device.
I sketched my wireframes on paper as a first step. I found it to be an efficient way to figure out interactions of components in and between screens as I can easily erase and draw them again in a shorter amount of time than if I were doing them from my laptop.
Once I had the basic areas of my screens laid out, I made the medium fidelity wireframes with Sketch app. I mocked up details like buttons, text fields, and copy, and used Sketch's Prototype function to test the flow on-screen.
For the visual design, I opted to use an open source design system for the following reasons:
Consistent look and feel
UI kit available in Sketch
Time-saving. I didn't need to reinvent the wheel and redesign components. Ultimately, they will also be cost efficient to the company.
Grid structure /layout available
Accessible
Detailed documentation available
With regard to colour, I used Thérapie's brand colour as base and used shades of it for active states and accordions. I also adjusted the colour a bit to increase the contrast and make it more accessible.
What I could have done better: In hindsight, I should have used the same colour for the bottom navigation bar.
The treatment listings and the summary page (right after selecting a treatment) displayed nearly identical information. I consolidated these two screens to shorten the booking flow.
Breaking it down
The solutions I proposed to increase conversion included streamlining the booking process, allowing the customer to book multiple treatments in one checkout, allowing the customer to edit items in their cart, and improving how the listings were displayed.
Streamlining the booking process
I started with working on reducing the number of screens from the booking flow as this struck me as the most common pain point based on my own experience going through the flows, Google reviews, and the competitive analysis. I believe helping the customers achieve what they set out to do i.e. book an appointment, in a shorter amount of time will reduce cart abandonment. The longer it takes to book, the more time they have to change their minds.
Consolidating pages
After selecting from the list of treatments, the app displayed a summary window with nearly the same information as the listing, save for the loyalty credits earned and the text "Terms and conditions apply" (which was not hyperlinked to the Terms and Conditions page). I consolidated these two and included the loyalty earned in the listing. I also changed the button label from Buy to Book Now, because that was the next step in the process.
What I could have done better: Add a short description to each listing to entice customers and let them know which treatment is right for them.
I consolidated three booking screens into one. The intention was to scroll to the next stop once the previous one was finished. This way, the user can make changes without having to go to the previous screen.
Side note: the app's progress bar did not correspond to the number of steps.
The booking process starts with the clinic selection screen, followed by date selection then time selection. I consolidated these three screens into one, with the steps stacked one on top of the other. My prototype also allowed the customer to change their preferred clinic and therapist anytime. In the app, once the customer landed on the date/time selection screen, they needed to go back to the previous page if they wanted to change this information.
I changed the copy to be more descriptive and less redundant from the page title. I also added step counters on the progress bar to let customers know where they are in the process.
Clinic selection
In the app, the list of clinics was not displayed by default and the "Find your closest clinic" function did not work. Either way, the customer had to select the "Show all clinics" button.
My prototype listed all clinics within the dropdown. I mocked up a warning message to show the preferred clinic did not provide the selected treatment and that the customer needed to choose another clinic. The rationale behind this was my research showed that the list of clinics change depending on the treatment selected. It would be easier to see if Thérapie had only a handful of clinics and it was easy to compare. However, in hindsight, it could be another pain point if the customer selects a clinic only to find out they cannot provide that service. Hence...
What I could have done better:
The warning could have listed the clinics that did not provide the selected treatment. This way, all items within the dropdown can be selected with no issues.
I also could have included the Find your closest clinic function. Just because it was buggy and did not work in real life did not mean it was not a good feature.
Date/Time selection
In the app, the customer needed to select Load More to view subsequent months. If they wanted to schedule something in five months, they needed to load and scroll until they get there. In my prototype, navigating by previous and next months can be done via the left and right arrows. I also folded the Morning, Afternoon, and Evening into tabs, resulting in more vertical real estate and less scrolling.
Treatments that Require Booking an Appointment
The app required customers to complete the checkout process for a treatment i.e. go through payment, before being able to book another one. It can be incredibly frustrating to have to do this over and over and is probably one of the main reasons for cart abandonment. Treatments that require booking were added to a different shopping cart in a separate booking flow. I imagine this can be confusing for customers who have previously added other items to their cart and see them gone.
I designed my prototype so treatments that required booking were added to the same shopping cart as everything else. It also allowed customers to go back and edit or remove them completely.
What I could have done better: Instead of Pay €270.00, the button should have been Proceed to Checkout because the customer needed to provide their billing and card details. I also could have added a Continue Shopping button below it.
One of the app reviews mentioned that "booking multiple different treatments for the same day is basically impossible to organise". I did not include this in my prototype as I had no user data to know whether this was a pattern or an anomaly.
Editing Items in the Cart
In the app, treatments that do not require booking can be immediately added to the cart. However, customers cannot specify the quantity.
I understand it makes more practical sense to buy a course of three instead of three individual Pay Per Sessions. But that did not seem to be the rationale behind the lack of Quantity field as one can add more of the same item in their cart if they hit the Add to Cart button multiple times. This interaction was the same in skincare products as well. One had to hit the Add to Cart button 20 times if they want 20 bottles of moisturiser.
The customer also cannot edit the quantity of items in their cart. If they made a mistake or changed their mind, they would have to remove that item altogether and start again.
Left: Thérapie Clinic's app folded in their listings in multi-level accordions.
Right: I replaced the "Buy Now" accordion with the sub-category name, saving significant vertical real estate.
The following are UI enhancements that I believe can indirectly have a positive impact on conversion through an improved shopping experience.
Wayfinding
Good wayfinding is essential to a pleasant retail experience, both offline and online. In the Thérapie app, getting to the list of treatments (e.g. Laser Hair Removal for Women) was fairly straightforward. However, when it came to the range (e.g. Lip, Chin, etc.), I believe it can be organised better.
A Treatment page contained a category header, at least one set header, which contained at least one table of treatment ranges. For pages with one set header (except for Laser Hair Removal for Men), their set header labels were the same as their category headers i.e. page title. For pages with more than one set header, the set headers were displayed as collapsed accordions. When expanded, it displayed the list of treatment ranges, also in collapsed accordions.
In my prototype, I removed the lone set headers as they served no real purpose because the treatment name was already in the category header. For the treatment range, I moved the range name to the accordion, saving significant vertical real estate and time spent scrolling.
There was also a question of grouping. At the time I tested the app, all laser hair removal treatments were on sale, yet there was a set header for Flash Offer. What was the difference between a flash offer and a normal sale? What exactly does "Any Bikini and Underarm" mean and how is it different from just "Bikini and Underarm"? Since the accordions were collapsed by default, how would the customer know that Bikini was actually under Customer Favourites and not under For the Body?
To resolve this, I designed my prototype so each range had a list for Popular services (aka Customer Favourites). As I mentioned, everything seemed to be on sale, which was why I did not make separate badges for Sale and Flash Offer.
Services vs. Pricing vs. Treatments. Navigating the mobile app was frustrating as there were three different names referring to the same thing.
Navigation
One of the first things I noticed while I was going through the flows was how some items were named differently in different pages. This prompted me to do the sitemap in the first place.
In addition to making the labels consistent in my prototype, I changed the menu side drawer to a fixed bottom navigation for the following reasons:
Easily accessible. In the app, the menu icon was only visible in the home and profile pages. If a customer was viewing a skin care product, they would have to hit the Back button repeatedly until they reach the home page. They could also hit the Thérapie logo in the main header, but it was not evident to be linked to the home page.
The links in the home page were nearly the same as side menu items. If the user can access the different parts of the app from the home page links and if the side menu can only be accessed from the home page, the only unique purpose the side menu served was to access the Profile and to log out.
There were only five items in the side menu, one of them was log out, which I thought was something a user was unlikely to do often enough to warrant prime real estate.
Somehow I missed the "Book New Treatment" call-to-action when I moved from paper sketches to digital wireframe.
What I could have done better:
I could have included the ability for the customer to add their own favourites.
With regard to labels, I could have pointed out in the presentation that it would fail WCAG 2.1 3.2.4: "If identical functions have different labels (or, more generally, a different accessible name) on different Web pages, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations. Therefore, consistent labeling will help."
I should have added a call to action to book a new treatment in the home page. It was actually in the sketches but somehow I missed it when I moved to digital wireframes.
I could also have been more dynamic with the typography and not relied too much on the out-of-the-box components from the design system. For example, in the Upcoming Appointments, I could have highlighted the treatment name more. I also could have added illustration or iconography on each card. In hindsight, it looked more like a child page than a parent page.
Conclusion
In the span of a weekend while raising a toddler (new parents will understand), I managed to map journeys, create a sitemap, conduct high level competitive analysis, synthesise my ideas, design wireframes in low, medium, and high fidelity, produce an exhaustive list of bugs and opportunities for improvement for the entire app (not just the booking aspect), prepare an InVision prototype, and put together a slide deck.
Unfortunately, my application was not successful. Perhaps I took the word improvement quite literally and focused too much on improving what was already there. I could have drawn more from my experience in designing machine learning-related products and incorporated recommendations in my designs like a call-to-action in the home page to book a follow up treatment based on a previously completed treatment e.g. Recommend moisturiser or moisturising treatment following a peel. Or a reminder "it's almost time for your next hair removal session. For best results, sessions should be made every six weeks."
Regardless, I am proud of the work I put in and what I delivered considering the amount of time I was given.