1 - Desk research

‍

Competitor research

At the beginning of the project I conducted an industry analysis into how apps and websites did their cart. While looking at different aspects I was also quanitfying what I saw with tables. Throughout the project I was getting asked ‘why is this like this?’ and I could back up the decision with internal data (when available) and by quantifying what the rest of the industry does.

In the below example I proved that apps that handle two types of experiences (ie. on ebay one can buy things but also sell things) have their cart within the buyer journey rather than on the bottom navigation. In our case customers can buy giftboxes and book their experience.

‍

As-is & data analysis

I can’t share exact data on the company. However, using Google Analytics and ContentSquare I was able to make a case for:Removing the page with just the type of payment user wants - Drop rates were highMake express payments more prominent - Based on the app native payments we know 1/5 of people were using this to check out, similar numbers were found on the web. Personalize payment methods depending on market - Some countries have a higher usage of express payments and use of vouchersMoving certain content blocks up or down depending on the use vs. revenue generatedA customer survey highlighted that customers want to be reassured on certain things (ie. secure payment, payment methods, delivery times, etc)

Tangentially I was creating the user flow to highlight what could be optimized, removed or kept based on the data and best practices.

By doing competitor and internal research I was able to have solid improvement takeaways backed up by data. So when designing I could check my designs against what I had found out.

1 - The ideal flow

The aim of the project is to align the checkout experiences as they will be using the same technology to create orders. So, based on the research done I was able to map out the ideal user flow from the product page to the order confirmation. This allowed both teams to see what new pages would be needed and to start scoping before the designs were final. The tech team also use the user flows to map out the different technologies that will be used throughout the experience.

‍

2 - Designing for web

When designing the web experience I had to use the Magento 2 out of the box as a base since the delivery times were short. My aim for the designs was to:

• Streamline the process
• Encourage checkout by highlighting payment CTA’s and payment methods available
• Encourage personalisation and the sale of add on’s
• Update UI and content to match user expectations and have a more modern experience
• Reassure the user throughout their experience that they can trust us

Throughout the design process feedback from customers, tech and stakeholders was key. I started by designing for mobile, testing it then designing desktop. As the wireframes were more advanced and refined I designed both mobile and desktop and then tested both.

‍

3 - Testing feedback loops

The designs were in constant unmoderated testing loops. For this example I will show the iterations for desktop cart:

• V1 - The payment method can’t be on the cart page because of Magento 2 structure
• V2 - Testers didn’t understand what gift personalisation was when collapsed. They tended to add it to their basket more when they could see it straight away. The payment methods weren’t visible at the end of the screen.
• V3 - Having the sticky order summary and payment CTA’s at the right, always visible was welcomed. Testers were more likely to personalise their box when it was expanded. The cards for personalisation changed from vertical to horizontal which allowed people to see more of the cart at one glance.
• Final designs - Testers enjoyed the visual and written feedback on their actions. All labels were clear labels on what is happening. Easy to check out with express payment.

4 - Implementation & UAT

The designs were handed over a call with a Figma file with notes and expected behaviour. As I’m writing this, the feature is still being coded, however, I have been in constant communication with the devs and PO to:

• Analyse and design any new edge case scenarios
• Make prioritisation decisions
• Amend designs based on new findings
• Conduct UAT to highlight any design and expected behaviour improvements

‍

1 - The app cart

Although I designed the app before the web, it has not gone live and therefore cannot share exact screens. However, the process was the same as I designed I was getting feedback from testers. At the end of the design process, I presented my work to stakeholders.

Below is an example of how I present the final design test results: a summary of the people testing, the task and overall results with quotes. Any feedback is also highlighted and actioned ie. In the final test, 2/9 pointed out the message when something was added to their cart was too short so I increased the time for the ‘Added!’ message from 1.4 seconds to 3 seconds.

2 - Sprinkling some flare

Customers expect great UX and UI experiences since everything revolves around technology. So I like to bring new behaviors to our platforms in every project. Historically we don’t use toggles, we tend to use radio buttons for many things. However, I wanted to make option to choose between a physical or email product a toggle. When presented to stakeholders they were not keen on this as it’s not ‘the usual’. However, I built up my case by testing the toggle against radio buttons and different UI for the toggle. Ultimately the toggle performed better and offered a cleaner UI.

Besides improving and pushing our UI patterns, I also created a lottie animation of the cart filling up to delight our customers. When someone adds something to their cart the stars show and the number updates.

‍