Order overview

Project attached to the PrestaShop Checkout, a payment solution built with PayPal. One of the module’s main problems was the merchant’s lack of visibility into order and payment status at any given point of transactions.

Project attached to the PrestaShop Checkout, a payment solution built with PayPal. One of the module’s main problems was the merchant’s lack of visibility into order and payment status at any given point of transactions.

Context: PrestaShop merchants lacked visibility into order and payment status throughout the transaction lifecycle.
Problem: Merchants couldn’t identify failed, delayed, or abandoned payments, leading to confusion and slower issue resolution.
Goal: Redesign the experience that makes payment issues visible, understandable, and actionable.
Outcome: user tests revealed 73% positive comments on the new screens and the focus on data regarding failed orders and basket abandonment.

Date:

2023

Client:

PrestaShop

Services:

UX/UI

The problem

Due to previous delays and technical refactoring, this feature had never been implemented for the first version of the module. Following extensive user research, this project came out as one of the most requested features for the module, as this data would indicate to the merchants and other users crucial information regarding delayed or failed payment, payment drop-off rates, and used payment methods.

My role

  • Introduced and adapted the F.O.C.U.S.E.D. framework for this project

  • Facilitated workshops across Product, Marketing, CRM, Sales, and UX Writing

  • Led the end-to-end design direction and prototyping

  • Synthesized research results into hypotheses and user flows

  • Partnered with engineering on feasibility and scope decisions

Approach

F.O.C.U.S.E.D. is a seven-step framework that offers a more structured approach to exploring problems, research, and testing, choosing the optimal solutions for users, and easier delivery/hand-off to the developers.

Due to the simplified structure of the methodology and meetings at each key moment, external teams that are affected by the project (Marketing, CRM, Sales,…) can easily follow along the progress and participate without having to slow down work and catch them up.

Since it was the first time the team would be working with this framework, not only did I have the task of teaching each step and team roles during the project, but as the Lead designer, I had the role of organising and facilitating workshops with relevant team members, and presenting the progress made at each step to the other teams.

F.O.C.U.S.E.D. is a seven-step framework that offers a more structured approach to exploring problems, research, and testing, choosing the optimal solutions for users, and easier delivery/hand-off to the developers.

Due to the simplified structure of the methodology and meetings at each key moment, external teams that are affected by the project (Marketing, CRM, Sales,…) can easily follow along the progress and participate without having to slow down work and catch them up.

Since it was the first time the team would be working with this framework, not only did I have the task of teaching each step and team roles during the project, but as the Lead designer, I had the role of organising and facilitating workshops with relevant team members, and presenting the progress made at each step to the other teams.

Frame

Defining the project objectives with success criteria, damage control, and a time box. With the help of an opportunity tree and previously measurable KPIs for each branch, the damage control was easily defined by the PM.

Defining the project objectives with success criteria, damage control, and a time box. With the help of an opportunity tree and previously measurable KPIs for each branch, the damage control was easily defined by the PM.

Observe

Our user research is based on a continuous discovery methodology, meaning throughout the year we have regular interviews, surveys, and behavioural data that we can use to build our Empathy Map needed for this project.

Our user research is based on a continuous discovery methodology, meaning throughout the year we have regular interviews, surveys, and behavioural data that we can use to build our Empathy Map needed for this project.

Once the empathy map is complete, our main deliverable is a First Use Case that will help us assess the feasibility and utility of the idea.

Once the empathy map is complete, our main deliverable is a First Use Case that will help us assess the feasibility and utility of the idea.

First use case

I'm a merchant using PrestaShop Checkout as my main payment module, and when I have clients using the module to pay for their items, I'm not always notified or aware if there is an anomaly.
What matters is having a centralized page with detailed information on all types of transactions made. But it turns out that at the moment I can't see any transactions, disputes, payments on hold, abandoned carts… only successful orders. So I must track down all relevant information and manually match the all orders to payment errors from multipl external platforms.

Claim

I organized and facilitated the workshop with my PM, UX writers, and some members of the Marketing team in order to come up with a fake launch tweet that would answer the question “How can I explain the value of this feature in two lines?”

I organized and facilitated the workshop with my PM, UX writers, and some members of the Marketing team in order to come up with a fake launch tweet that would answer the question “How can I explain the value of this feature in two lines?”


The next module version will simplify our merchants' daily tasks even more by giving them centralised access to all transactions, regardless of their status.
Monitor your activity more closely and steer your business to the next level.


The next module version will simplify our merchants' daily tasks even more by giving them centralised access to all transactions, regardless of their status.
Monitor your activity more closely and steer your business to the next level.

Unfold

This step provided us with valuable insights into how our merchants will potentially interact with the new feature.

This step provided us with valuable insights into how our merchants will potentially interact with the new feature.

Steal

With my PM, we’ve conducted a visual benchmark of our competitors and other products from which we could be inspired and retrieve ux patterns from other platforms our users used.

Our ultimate goal is the implement a new feature that our users can easily adopt and use from day one of launch.

With my PM, we’ve conducted a visual benchmark of our competitors and other products from which we could be inspired and retrieve ux patterns from other platforms our users used.

Our ultimate goal is the implement a new feature that our users can easily adopt and use from day one of launch.

Execute

I started this step by defining 3 hypotheses that will guide the experience and subsequent tests, which will, in the end, confirm or disprove whether our solution truly answers the core user problem.

I started this step by defining 3 hypotheses that will guide the experience and subsequent tests, which will, in the end, confirm or disprove whether our solution truly answers the core user problem.

Hypothesis 1

Merchants can successfully see all types of payment status and have more detailed information on each transaction.

Hypothesis 2

Merchants can see at a glance how their business is doing and what payment methods work best for different markets.

Hypothesis 3

Users will be able to filter through different types of statuses, which will help identify and track specific errors and transactions.

We had considered keeping the same visual at PayPal's existing platform, but from user feedback, we knew this wasn’t the appropriate way to show it, and it was also missing a link between the payment status and the specific order and client, if the merchant needed to contact them.

The solution asked for a table that needed:

  • Prioritized failed and incomplete payment statuses over order details.
    We knew our merchants would come to this page mainly to investigate issues, not browse routine transactions.

  • Separated payment status from order status.
    The new payment status had to be clearly different from the existing order status, or it could increase ambiguity in failure scenarios.

  • Created a dedicated entry point to payment logs.
    Merchants needed traceability to investigate disputes and failed transactions more efficiently.

We had considered keeping the same visual at PayPal's existing platform, but from user feedback, we knew this wasn’t the appropriate way to show it, and it was also missing a link between the payment status and the specific order and client, if the merchant needed to contact them.

The solution asked for a table that needed:

  • Prioritized failed and incomplete payment statuses over order details.
    We knew our merchants would come to this page mainly to investigate issues, not browse routine transactions.

  • Separated payment status from order status.
    The new payment status had to be clearly different from the existing order status, or it could increase ambiguity in failure scenarios.

  • Created a dedicated entry point to payment logs.
    Merchants needed traceability to investigate disputes and failed transactions more efficiently.

The solution needed to fit within the existing product architecture and technical constraints, so we decided to replicate the back office’s order table that the users were already used to. We combined the order information and payment information without overwhelming them, and most importantly, we needed to help the users to quickly detect issues, understand what had happened, and know what to do next.

The solution needed to fit within the existing product architecture and technical constraints, so we decided to replicate the back office’s order table that the users were already used to. We combined the order information and payment information without overwhelming them, and most importantly, we needed to help the users to quickly detect issues, understand what had happened, and know what to do next.

Decision

As the last step before handoff, the team reviewed the progress made up to that point, ensuring that all steps met the initial objectives, that the final design validated all hypotheses, and that the solution fit the user’s problem and met expectations.

As the last step before handoff, the team reviewed the progress made up to that point, ensuring that all steps met the initial objectives, that the final design validated all hypotheses, and that the solution fit the user’s problem and met expectations.

Results

Since our timeline allowed it, the PM and I relaunched a testing phase with our users.

Test protocol:

  • Figma prototype tested with 8 Checkout merchants

  • Core tasks included locating payment history, identifying a failed payment, and understanding order status.

  • Most participants successfully understood the new data hierarchy, but 3 expressed confusion regarding notifications and how conflict resolution was managed; information that was noted down for a potential second version

Throughout the project, I led several key trade-off decisions with the team. We prioritized failed and incomplete payment states over generic order details, separated payment status from order status to reduce misinterpretation, and introduced a clear entry point to payment logs so merchants could investigate disputes more effectively.

Since our timeline allowed it, the PM and I relaunched a testing phase with our users.

Test protocol:

  • Figma prototype tested with 8 Checkout merchants

  • Core tasks included locating payment history, identifying a failed payment, and understanding order status.

  • Most participants successfully understood the new data hierarchy, but 3 expressed confusion regarding notifications and how conflict resolution was managed; information that was noted down for a potential second version

Throughout the project, I led several key trade-off decisions with the team. We prioritized failed and incomplete payment states over generic order details, separated payment status from order status to reduce misinterpretation, and introduced a clear entry point to payment logs so merchants could investigate disputes more effectively.

Key takeaway

Although the feature wasn’t shipped due to technical constraints discovered too late in the process, the project brought up important lessons for future deliveries:

  1. The need to involve engineering earlier and note down “technical unknowns” as a definite risk in the feasibility assessment phase

  2. Improve testing protocol regarding content comprehension

  3. Reduce or narrow the solution scope to higher-value use cases in the event of unexpected technical dependencies that risk delivery.

Although the feature wasn’t shipped due to technical constraints discovered too late in the process, the project brought up important lessons for future deliveries:

  1. The need to involve engineering earlier and note down “technical unknowns” as a definite risk in the feasibility assessment phase

  2. Improve testing protocol regarding content comprehension

  3. Reduce or narrow the solution scope to higher-value use cases in the event of unexpected technical dependencies that risk delivery.

© Ana Costa

Paris

© Ana Costa

Paris