Store Pilot SaaS B2B

Mon rôle

Freelance Product Designer Collaboration directe avec Ilyes (Product Owner) et l'équipe tech d'Ad4Screen.

Responsabilités : Reprise complète UX/UI de la plateforme :
- Audit UX de l'existant
- Entretiens utilisateurs (ASO managers, marketing produit)
- Ateliers de co-conception avec le PO
- Refonte des parcours critiques
-Contribution au design system existant
-Itérations rapides produit-tech

Contexte & Enjeux Business

Chaque mise en ligne d'une application mobile sur les stores (Apple App Store, Google Play Store) nécessite la production de visuels marketing optimisés — les screenshots — dans plusieurs langues et plusieurs formats de dimensions (iPhone, iPad, Android de différentes tailles). Ce processus est aujourd'hui long, répétitif et source d'erreurs.
 
L'outil actuel a été développé pour automatiser et structurer ce processus, mais souffre de problèmes UX et techniques qui le rendent difficile à utiliser efficacement. Le projet consiste donc à retravailler entièrement l'expérience utilisateur, puis à réimplémenter la plateforme avec le design system shadcn/ui (ou son équivalent Vue).

—————————————————————-

Problèmes identifiés

Une plateforme SaaS qui permet aux équipes marketing de créer, gérer et publier des rubans de screenshots App Store iOS & Android — directement sur les stores via API, à grande échelle, en plusieurs langues. :

1️⃣ Nomenclature d'import opaque Les fichiers CSV et ZIP devaient suivre une nomenclature stricte que personne ne comprenait du premier coup. Conséquence directe : erreurs en cascade, retours en arrière, abandons.

2️⃣ Page Principale vs Custom Product Page : confusion totale La distinction entre PP (Page Principale) et CPP (Custom Product Page, iOS uniquement) n'était pas claire dans l'UI. Les utilisateurs publiaient au mauvais endroit, perdaient du temps, parfois de la donnée.

3️⃣ Attente de génération sans feedback La génération du ruban prenait plusieurs minutes, sans aucun retour visuel. Les utilisateurs rechargeaient la page, dupliquaient leurs envois, ou abandonnaient.

4️⃣ Outil pensé pour les experts, pas pour les équipes marketing Insight clé → Les responsables marketing veulent déléguer la création à leur équipe, pas devenir eux-mêmes le support technique de l'outil.

———————————————————————————————————————-

Approche : Double Diamond appliqué à un SaaS B2B

Discover

• Audit UX complet de la plateforme existante

• Entretiens avec utilisateurs représentatifs (ASO Managers, marketing produit)

• Ateliers de co-conception avec le Product Owner

• Mapping du journey "Mode Expert" (11 étapes documentées)

• Identification des frictions par étape

Use flow - Audit

Journey map

User testing avec le client :

Retour d'un user :
Stephanie : ASO Manager · Marketing hôtelier

-> Gère plusieurs apps iOS et Android, en plusieurs langues, pour plusieurs marques du groupe. Veut pouvoir déléguer la création de rubans à son équipe sans tout valider elle-même.

"J'ai besoin que mon équipe puisse créer un ruban sans m'appeler à chaque erreur. Aujourd'hui, je suis le SAV de l'outil."

J’ai identifié trois moments critiques :

-Import des fichiers (CSV + ZIP d'images)
- Choix du type de publication (PP / CPP)
- Attente de génération et confirmation

Benchmark

Define

Problématique centrale :

Comment transformer un outil ASO d'expert en SaaS self-service, sans sacrifier la puissance fonctionnelle ?

Axes de design définis :
▻ Simplification radicale de l'import
▻ Lisibilité de la logique multi-stores (iOS / Android, PP / CPP)
▻ Feedback continu pendant les temps d'attente
▻ Hiérarchisation des informations au dashboard
▻ kh v c. Réduction du parcours sans perte de contrôle

Du journey map au flow final

Mode Expert — Comment fonctionne le CSV ?

———————————————————————————————————

Solutions conçues

1 - Dashboard hiérarchisé

Objectif : passer du tableau brut à une vue qui oriente l'action.

Design decisions :
✧ Cards de stats en en-tête (rubans actifs, en attente, publiés)
✧ Filtres par onglets selon le statut
✧ Tableau enrichi avec distinction visuelle des statuts (brouillon / publié / en attente)
✧ Accès rapide aux actions principales sans modale

———————————————————————————————————

2-Module Import & Validation

Problème : nomenclature stricte, erreurs en cascade, abandons fréquents.

Solutions :
✧ ZIP socle pré-structuré : un dossier modèle téléchargeable que l'utilisateur remplit, plutôt que de tout structurer lui-même
✧ Bloc d'aide CSV contextuel intégré au parcours
✧ Page de validation à deux états (erreurs détectées / fichier corrigé)
✧ Aperçu du CSV importé avant validation finale

Objectif : 👉 Transformer un point de friction majeur en étape qui pardonne les erreurs.

——————————————————————————————————

3- Module Publication multi-stores

Problème : logique iOS / Android, PP / CPP enterrée dans des modales.

Refonte :
-Page de publication dédiée (fin des modales empilées)
-Hero toggle PP / CPP visible d'emblée
-Combinaisons impossibles désactivées dans l'UI (iOS via API, Android via ZIP pour la personnalisée)
-Logique métier respectée sans charge cognitive imposée à l'utilisateur

Focus → Rendre la complexité métier lisible sans la masquer.

————————————————————————

Results & Impact

Le projet est en cours de mise en production. L'impact mesurable sur les livrables design est déjà clair :
✧ Parcours simplifié : 11 étapes réduites à 7 sur le mode Expert
✧ +6 nouveaux composants documentés et contribués au design system
✧ 4 flows critiques redessinés bout en bout
✧ Wireframes HTML interactifs livrés pour accélérer la validation et le passage au dev
✧ Logique multi-stores enfin lisible pour les utilisateurs non-experts

Impact produit 👉La plateforme est passée d'un outil agence à un SaaS self-service.

————————————————————————

Lessons Learned

Un SaaS B2B ne se vend pas par la richesse fonctionnelle, mais par la lisibilité du parcours. Store Pilot avait toutes les fonctionnalités nécessaires. Ce qui manquait, c'était l'ordre dans lequel les présenter à l'utilisateur.

Concevoir avec les contraintes API, pas contre elles. iOS et Android ne publient pas de la même façon. Plutôt que d'unifier artificiellement le parcours, j'ai conçu une UI qui rend ces contraintes lisibles — sans masquer la complexité ni l'imposer brutalement.

La co-conception founder + tech accélère les décisions structurantes. Travailler en boucle courte avecPO sur chaque module a permis de cadrer la faisabilité dès le wireframe, sans aller-retour stérile entre design et dev.