Une étude de concept Webtrix d'une application de livraison de repas de quartier, pensée pour le paiement à la livraison, en français et en arabe.
Type
Étude de concept (produit fictif)
Durée
5 semaines
Outils
Figma, Useberry
Équipe
Studio de design Webtrix

Contexte
MunchRun est une application fictive de livraison de repas, imaginée pour une ville marocaine, qui met en relation les clients et les restaurants locaux. Le brief est propre au marché : beaucoup de clients paient encore en espèces à la porte, utilisent indifféremment le français et l'arabe, et veulent savoir en termes simples où en est leur commande.
L'étude couvre tout le parcours de commande, de la recherche d'un restaurant à l'évaluation de la livraison, en privilégiant la rapidité, la clarté et la confiance.
2
Langues : français et arabe (RTL)
3
Modes de paiement : espèces, carte, portefeuille
22
Écrans clés conçus
Le parcours de commande aujourd'hui
Les applications de livraison perdent leurs clients au même endroit : au moment de personnaliser un article et de payer. Des schémas confus, aucun retour en direct et un paiement qui suppose la carte bancaire poussent les gens vers le téléphone ou WhatsApp. Ce sont les problèmes que nous avons posés comme point de départ et contre lesquels nous avons conçu.
- La personnalisation d'un article est répartie sur plusieurs écrans
- Passer une commande prend de nombreuses minutes car rien n'est mémorisé
- Le suivi de commande affiche une estimation figée au lieu de ce qui se passe réellement
- Les clients réguliers n'ont aucun chemin rapide pour recommander
- Le paiement à la livraison est traité comme un détail plutôt que comme un mode de paiement à part entière
Découverte
Une phase de découverte documentaire : nous avons parcouru six applications de livraison, cartographié les trois parcours qui comptent et noté où chacune demande au client de réfléchir plus qu'il ne le devrait.
6
Applications de livraison parcourues
3
Parcours cartographiés
2
Langues prises en compte
Ce qui ressortait
- Les écrans de personnalisation demandent trop de décisions à la fois
- Le suivi en direct est attendu, mais la plupart des applications donnent une estimation figée
- Recommander est la tâche la plus fréquente et la moins travaillée
- La découverte des restaurants manque de filtres adaptés aux habitudes locales (ouvert maintenant, accepte les espèces, livre dans mon quartier)


Pistes explorées
Un sprint de design de deux jours, avec des questions « comment pourrions-nous… », une cartographie par affinités et des storyboards, a fait émerger deux pistes solides.
Nous avons retenu « QuickFlow » : un concept bâti pour réduire la fatigue de décision grâce à des valeurs par défaut intelligentes, des préférences enregistrées et un bouton « Recommander » en un geste à chaque point de contact.

Trois parcours
Nous avons cartographié trois parcours : un nouveau client qui découvre un restaurant, un client régulier qui recommande, et le suivi de commande en direct. L'objectif de conception est une commande passée en moins de trois minutes.
- De la découverte au panier - fil personnalisé avec filtres intelligents et fiches restaurant affichant les temps d'attente en direct
- De la personnalisation au paiement - constructeur d'article sur un seul écran, avec ventes additionnelles intégrées et préférences enregistrées
- Suivi après commande - carte en direct avec notifications push et compte à rebours de l'heure d'arrivée estimée

Wireframes
Objectif de conception : une commande passée en moins de trois minutes, en espèces ou par carte.
Des wireframes pour 22 écrans clés, des croquis aux maquettes de moyenne fidélité en trois itérations, chaque écran étant dessiné en français (de gauche à droite) et en arabe (de droite à gauche).
Objectif de conception : une commande passée en moins de trois minutes, en espèces ou par carte.
Style et ambiance
La direction visuelle doit être énergique et appétissante tout en restant rapide et fonctionnelle : un système chaud et très contrasté, avec une palette safran et charbon et des composants arrondis qui gardent un ton amical.


Comment nous le testerions
Le prototype haute fidélité est réalisé dans Figma. Il n'a pas été testé avec de vrais clients ; voici le plan que nous suivrions avant de développer, avec Useberry pour des sessions à distance.
6 Participants prévus par session 3 Sessions de test prévues 90% Objectif : taux de réussite des tâches
Le test d'un parcours de commande de repas est simple : une personne affamée peut-elle commander sans réfléchir ?
Itérations de conception
Itération 1 : Un parcours de personnalisation en quatre étapes condensé en un seul panneau coulissant. Objectif de conception : moins d'écrans entre le choix d'un plat et son ajout.
Itération 2 : Ajout d'un raccourci « Recommander » permanent sur l'écran d'accueil pour les clients réguliers. Objectif de conception : faire de la tâche la plus fréquente la plus rapide.

AvantAprèsLe design proposé
La proposition, « QuickFlow », est une expérience de commande rapide dotée d'une identité visuelle forte. Ses principales fonctionnalités :
- Recommander en un geste, avec préférences et dernière adresse de livraison enregistrées
- Découverte intelligente des restaurants avec indicateurs de temps d'attente en temps réel
- Personnalisation d'article sur un seul écran avec options additionnelles intégrées
- Suivi de commande en direct avec carte animée et mises à jour de livraison
- Fil d'accueil personnalisé selon l'historique de commandes et l'heure de la journée
- Espèces à la livraison, carte et portefeuille comme modes de paiement à égalité, avec gestion claire de la monnaie et du reçu
- Français et arabe avec mises en page complètes de droite à gauche
- Contraste WCAG AA et taille des zones tactiles comme objectifs de conception





Objectifs de conception
< 3 min
Objectif : temps pour passer une commande
1 geste
Recommander pour les clients réguliers (conception)
-30%
Objectif : abandons de panier
Ce sont des objectifs de conception pour une étude de concept, et non des résultats mesurés : l'application n'a été ni développée ni testée avec de vrais clients.
Dans une application de repas, la rapidité et la confiance comptent plus que la richesse visuelle.
Ce que l'étude nous a appris
- Dans les applications de repas, la rapidité et la confiance comptent plus que la richesse visuelle
- Les parcours « Recommander » sont sous-investis dans la plupart des applications de livraison, alors que c'est l'usage le plus fréquent
- Les animations et micro-interactions améliorent nettement la performance perçue
- Concevoir avec de vrais menus de restaurants (et non du faux contenu) révèle tôt les cas limites
- Traiter le paiement à la livraison comme un parcours à part entière change le paiement, le reçu et le parcours du livreur
Si ce projet était réalisé
- Valider le parcours avec le plan de test ci-dessus avant toute réalisation
- Ajouter la commande groupée pour les bureaux et les familles
- Transformer le design system en bibliothèque de composants partagée avec l'ingénierie
- Ajouter des suggestions de repas seulement une fois qu'un vrai historique de commandes existe
















