Tous les projets
Purse · 2025 — 2 semaines

Fast Checkout

Un widget de paiement en un clic que les marchands peuvent intégrer sur une fiche produit ou un panier, avec assez de personnalisation pour qu’il leur ressemble.

Purse — parcours de paiement express
Rôle
Seul Product Designer, en binôme avec le PM : entretiens, parcours, UI du widget, design system
Équipe
1 PM, développeurs SDK frontend
Utilisateurs
Acheteurs B2C ; intégré par les équipes marketing et e-commerce
Périmètre
Widget, SDK, tokens de personnalisation, page de paiement
En bref

Nos clients voulaient un achat express sur la fiche produit, mais l’intégrer obligeait à toucher au tunnel de paiement. Quatre entretiens clients ont fait ressortir le même blocage. Avec le PM, nous avons cadré une première version livrable en deux semaines, design et code compris : un widget prêt à poser sur une fiche produit.

  • +3 %de taux de conversion au paiement, mesuré sur 4 marchands
  • 2 semainespour livrer, design et développement compris
  • 4 sur 4clients interrogés bloqués par le même problème
Contexte

Le parcours rapide était le plus difficile à installer

Les marchands voulaient un bouton d’achat rapide directement sur la fiche produit ou le panier. En pratique, l’intégrer à une boutique existante obligeait à toucher au tunnel de paiement, la seule partie d’un site e-commerce que personne ne veut reconstruire.

Le problème

Intégrer un achat rapide depuis une fiche produit ou un panier était trop compliqué pour en valoir la peine pour la plupart des marchands.

  • Chaque boutique exposait son panier différemment, donc chaque intégration était du sur-mesure.
  • Les équipes marketing ne pouvaient pas le mettre en ligne sans un sprint de développement.
  • Un widget générique détonnait sur la page, alors les marchands le refusaient.
Ma démarche

Un blocage commun, deux semaines pour livrer

  1. Entretiens clients

    Quatre clients interrogés, quatre fois le même blocage : l’achat express exigeait de toucher au tunnel de paiement, donc un projet de développement.

  2. Analyse du tunnel

    Le parcours existant décomposé étape par étape, pour retirer ce qui pouvait l’être sans perdre la confiance de l’acheteur.

  3. Widget et SDK

    Un seul composant qui se comporte de la même façon sur une fiche produit, un panier et en mobile.

  4. Personnalisation par tokens

    Un ensemble limité de tokens exposés pour que le widget reprenne l’identité du marchand en toute sécurité.

Arbitrages

Les choix qui ont façonné le produit

Quel périmètre pour la première version ?

Livrer en deux semaines, puis mesurer

Avec le PM, nous avons limité la V1 à l’essentiel : le widget, le paiement express et la personnalisation par tokens. De quoi prouver la valeur sur de vrais marchands avant d’aller plus loin.

Ce qui a tranché : la stratégie de l’entreprise, simplifier l’expérience d’achat, et un blocage identique chez les quatre clients interrogés.

Écarté : Un projet de plusieurs mois couvrant tous les cas d’intégration, avant d’avoir la moindre mesure.

Quelle liberté donner au marchand ?

Des tokens, pas du CSS libre

Les marchands modifient les couleurs, les arrondis et l’échelle typographique. La mise en page, les espacements et les états de paiement restent les nôtres.

Ce qui a tranché : la mise en page et les états de paiement portent la confiance et la conformité ; les couleurs, elles, portent la marque.

Écarté : Une liberté CSS totale. Elle aurait gagné les démos et cassé l’étape de paiement en production.

Un composant par emplacement, ou un seul ?

Un seul widget pour tous les emplacements

Le même composant s’adapte à la fiche produit, au panier et au mobile.

Ce qui a tranché : en deux semaines, un composant bien testé valait mieux que trois variantes, et le marchand n’a qu’une décision d’intégration à prendre.

Écarté : Des widgets par emplacement : plus simples à concevoir, mais trois fois plus de décisions d’intégration pour le marchand.

Impact

+3 % de conversion, livré en deux semaines

Le widget a transformé un projet de développement en simple étape de configuration. Sur les quatre premiers marchands en ligne, le taux de conversion au paiement a progressé de 3 %. Les équipes marketing le placent elles-mêmes et en changent l’apparence sans rouvrir de ticket.

Hausse de conversion mesurée sur les 4 premiers marchands en ligne ; chiffre arrondi et anonymisé.

  • Taux de conversion au paiement+3 %
  • Design et développement2 semaines
  • Emplacements couverts par un seul composant3
Ce que j’en retiens

Pour un SDK, le vrai utilisateur est la personne qui l’intègre. L’expérience de l’acheteur n’existe que si l’intégration a été assez simple pour être mise en ligne.

Ce que je ferais différemment : publier la documentation de personnalisation avec la première version plutôt qu’après.