Expliquer le produit avant la connexion
Avant de demander un portefeuille, montrez ce que fait le produit, les besoins de la prochaine action et la possibilité de consulter sans compte. Une fenêtre de connexion inexpliquée impose une décision avant la compréhension du service. Proposez une première action précise : voir un produit, consulter une position ou commencer une demande. Adaptez la préparation à cette action. Si compte classique et portefeuille coexistent, expliquez leurs fonctions respectives plutôt que deux méthodes de connexion apparemment équivalentes dont le comportement diffère. L’utilisateur doit comprendre pourquoi ce choix est demandé maintenant.
Donner un sens distinct à chaque autorisation
Connecter un portefeuille, signer un message, autoriser l’utilisation de tokens et envoyer une transaction demandent des explications différentes. Décrivez la requête réelle avant d’ouvrir le portefeuille : actif, réseau, montant, destinataire et plafond éventuel. Évitez un bouton « Continuer » générique pour des étapes matériellement différentes. Permettez une nouvelle vérification au retour. Si plusieurs demandes sont nécessaires, présentez leur ordre et l’étape actuelle. Une signature refusée doit laisser une voie claire pour arrêter ou réessayer volontairement, sans relancer automatiquement une série de demandes.
Réagir aux changements de compte et de réseau
EIP-1193 définit des événements de changement de compte et de chaîne pour les fournisseurs Ethereum. Écoutez-les et réévaluez le parcours au lieu de conserver un ancien compte affiché. Une requête non signée peut devoir être reconstruite ; une transaction déjà envoyée appartient toujours à son contexte initial. Invalidez les devis et hypothèses de permission devenus caducs. Expliquez ce qui a changé et ce qui doit être revérifié. N’envoyez jamais silencieusement une transaction de remplacement parce qu’un réseau a changé ou qu’une demande antérieure n’est plus valable.
Concevoir le passage entre applications mobiles
Un portefeuille mobile peut ouvrir une autre application et revenir après un délai ; le navigateur peut aussi se recharger. Conservez le brouillon et la référence de transaction sans interpréter le retour comme une approbation. Proposez une page d’état reprenable indiquant compte et réseau. Testez les passages interrompus, portefeuilles incompatibles, refus et pertes de connexion. Évitez une boucle de demandes de connexion. Une solution de reprise utile explique comment retrouver l’opération en attente et ses preuves lorsque le portefeuille l’a déjà transmise. Elle doit rester compréhensible après une longue interruption.
Expliquer précisément attente et échec
Distinguez refus volontaire, fournisseur déconnecté, réseau incompatible, transaction transmise en attente de vérification et échec confirmé. Proposez la prochaine étape adaptée à chaque état. Une animation d’attente ne doit pas cacher la référence de transaction ou suggérer un délai garanti. Conservez les opérations après actualisation pour éviter un second paiement pendant l’attente. Fournissez une référence de support sans secret. Ni l’interface ni les instructions d’assistance ne doivent demander une phrase de récupération ou du matériel de signature privé. Vérifiez que le message permet une décision sans supposition technique.
Inclure l’accessibilité dans la réception
Testez le parcours au clavier, avec focus visible, texte agrandi et libellés traduits. En arabe, gardez adresses, montants et identifiants de réseau lisibles dans une page de droite à gauche ; la copie doit préserver exactement la valeur. Ne distinguez pas attente et réussite uniquement par la couleur. Demandez à une personne découvrant le produit d’expliquer chaque permission avant de l’approuver. Notez les explications incomprises. Un bon onboarding enchaîne des décisions compréhensibles et propose une reprise claire, en s’appuyant sur un état technique exact plutôt que sur des suppositions visuelles.