Commencer par la personne qui utilise la dApp
Une dApp doit rendre sa tâche principale facile à comprendre avant qu'une action wallet ou contrat n'apparaisse. Nous commençons par cartographier ce qu'un membre vient faire, puis nous connectons chaque étape aux écrans et aux données dont l'application a besoin.
Cette première conversation peut être simple. Dites-nous à qui s'adresse le produit, ce que les gens doivent pouvoir faire et ce qui existe déjà. Une esquisse grossière ou quelques notes suffisent pour commencer. Nous les transformons en une image partagée de la première version, y compris les parties qui nécessitent des décisions techniques.
Par exemple, un projet NFT peut vouloir que les membres explorent une collection puis effectuent une action on-chain. Nous pouvons séparer les parties qui nécessitent un wallet connecté de celles qui doivent rester ouvertes à tous. Si le produit a également besoin de nouveaux contrats, nous pouvons coordonner le plan d'application avec le développement de smart contracts. Pour une vue technique plus large, le développement Web3 couvre le travail de produit connecté au-delà d'une seule dApp.
Cartographier le développement en trois passes claires
Un plan de dApp utile amène l'idée à travers les tâches utilisateur, les intégrations et une décision de première version. Ces trois passes maintiennent les choix importants visibles avant le début du développement.
- Décrire le parcours. Nous listons les actions qu'un membre doit effectuer, de l'ouverture de l'application à la fin de la tâche principale. Nous notons où l'interface doit expliquer un choix ou montrer une réponse.
- Rassembler les connexions. Nous examinons les contrats, wallets, réseaux et services existants avec lesquels le produit doit fonctionner. Nous notons également les informations que chaque écran doit afficher.
- Choisir la première version. Nous convenons des écrans et des intégrations qui appartiennent à la version initiale. D'autres idées peuvent rester sur une liste de suivi, plutôt que de se joindre silencieusement au travail en cours.
Imaginez que votre équipe a déjà une esquisse de produit et un contrat, mais que les vues de données sont encore incertaines. Nous pouvons marquer les parties confirmées, lister les questions ouvertes et convenir de ce qui doit être répondu avant l'implémentation. Si le produit a besoin d'un site public séparé, le développement de site Web3 et de landing page peut couvrir cette surface sans la mélanger au plan de l'application.
Où les wallets et les données on-chain doivent-ils se rencontrer ?
Le flux wallet et la vue des données doivent soutenir la même tâche utilisateur. Nous les planifions ensemble, afin qu'un membre puisse comprendre ce que l'application montre et pourquoi une connexion est nécessaire.
Étapes wallet
Nous cartographions les moments qui nécessitent une adresse wallet ou une action approuvée par l'utilisateur. L'interface doit tenir compte de 3 états de base : déconnecté, connecté et retour à l'application. Nous convenons également de la manière dont l'application explique l'étape suivante, plutôt que de laisser les gens interpréter une invite wallet sans contexte.
Données que les gens peuvent utiliser
L'indexation mérite d'être envisagée lorsque les membres ont besoin de trouver ou d'organiser des enregistrements on-chain. Nous commençons par les questions auxquelles l'écran doit répondre, puis nous identifions la source et la présentation de ces informations. Une simple vue de compte peut nécessiter un travail de données différent d'un historique d'activité consultable.
Disons qu'un collectionneur revient pour vérifier une action antérieure. Nous pouvons retracer les informations dont l'écran a besoin et décider si une source existante est suffisante. Apportez des exemples des enregistrements ou des vues que vous souhaitez montrer. Lorsque la fonctionnalité wallet est un produit plus large en soi, le développement de wallet crypto est une option séparée.
Intégrer les moments silencieux dans la conception
Imaginez un artiste NFT avec une petite communauté, juste au moment où la seule personne qui répond part en vacances. Un nouveau membre arrive avec une question sur la collection et une action dans la dApp. Nous rendrions l'étape suivante visible dans l'interface, afin que le produit ne dépende pas de quelqu'un en ligne pour l'expliquer.
Ce genre de moment appartient à l'examen du produit, pas seulement à un plan de support. Nous regardons ce qu'un nouveau membre voit, ce qui se passe lorsque des informations sont manquantes et comment l'application répond après une action. Ensuite, nous convenons des états qui doivent être conçus et testés.
Avant le travail de développement, nous vérifions :
- La tâche principale qu'un nouveau membre doit accomplir.
- Ce qui peut être exploré sans connecter un wallet.
- Quel message apparaît lorsque les données sont encore en cours de chargement ou indisponibles.
- Ce que le membre voit après qu'une action est soumise.
Cet examen maintient l'interface ancrée dans l'utilisation réelle. Il vous aide également à décider ce qui appartient à la première version et ce qui peut attendre que vous ayez plus de retours.
Garder le travail visible jusqu'à la remise
Une bonne remise montre ce qui a été construit, comment les flux utilisateur convenus ont été vérifiés et quelles dépendances subsistent. Nous utilisons deux points d'examen, un avant l'implémentation et un près de la remise. Avant l'implémentation, nous confirmons les fonctionnalités convenues. Près de la remise, nous parcourons le travail terminé avec vous.
Pendant le développement, nous vérifions les états frontend planifiés et les intégrations par rapport au parcours utilisateur. Nous gardons les questions ouvertes visibles et discutons des nouvelles demandes avant qu'elles ne modifient le travail convenu. Lors de la remise, nous parcourons l'application, partageons les notes d'implémentation et identifions les tâches de suivi que votre équipe souhaite considérer.
Les fournisseurs de wallet, les réseaux, les contrats et les services de données restent en dehors de notre contrôle. Leur disponibilité, leur gestion des transactions, leurs mises à jour et leur compatibilité peuvent changer, donc nous vérifions le comportement convenu de l'application sans promettre le fonctionnement de ces systèmes externes.
Pour commencer, envoyez-nous vos notes produit, l'ébauche d'interface, les détails de contrat disponibles et des exemples des données dont les membres ont besoin. Brand Community les examinera avec vous, clarifiera les questions ouvertes et façonnera un plan de première version sur lequel vous pourrez prendre une décision claire.
Comment ça marche
- Partager l'image du produitDites-nous à qui sert la dApp, ce que les membres doivent faire et ce que vous avez déjà.
- Tracer les connexionsNous examinons les wallets, contrats, réseaux et besoins en données qui soutiennent ces tâches.
- Convenir de la première versionNous décidons quelles fonctionnalités appartiennent au développement et ce que la remise doit couvrir.
- Développer et vérifier les fluxNous implémentons le travail convenu et l'examinons par rapport au parcours membre.
- Parcourir la remiseNous vous montrons le travail terminé, partageons les notes et identifions les dépendances restantes.
Questions fréquentes
Que dois-je apporter à notre première conversation sur la dApp ?
Apportez une courte description du produit, les principales tâches des membres et tout ce qui est déjà construit. Des esquisses d'interface, des détails de contrat et des exemples des données que vous souhaitez montrer sont également utiles. Même une simple liste de 3 actions utilisateur nous donne un point de départ pratique.
Construirez-vous l'interface de la dApp autour de nos contrats existants ?
Oui. Nous pouvons planifier le frontend et le flux wallet autour de contrats existants. Partagez les informations de contrat disponibles et expliquez ce que les membres doivent faire. Nous examinerons les points de connexion, noterons ce qui est encore flou et conviendrons des fonctionnalités qui appartiennent à la première version.
Comment décidez-vous si une dApp a besoin d'indexation ?
Nous commençons par les questions auxquelles vos membres ont besoin que l'application réponde. S'ils ont besoin de trouver, d'organiser ou de visualiser des enregistrements à travers l'activité, l'indexation peut être utile. Partagez quelques exemples des enregistrements ou des écrans que vous avez en tête, et nous cartographierons le besoin de données par rapport au produit.
L'application peut-elle montrer des informations utiles avant que quelqu'un ne se connecte ?
Oui, lorsque le flux du produit le permet. Nous identifions quelles informations peuvent être explorées sans wallet et quelles actions nécessitent une connexion. Par exemple, une vue de collection publique peut être planifiée séparément d'une action membre qui nécessite une approbation wallet.
Combien de temps prend généralement un développement de dApp ?
Nous fixons le calendrier après avoir examiné les fonctionnalités, les supports existants et les intégrations. Un flux frontend ciblé et une application avec plusieurs connexions de contrats ou de données nécessitent des plans différents. Nous convenons d'étapes par rapport au travail, afin que vous puissiez voir ce qui vient ensuite à chaque examen.
Pouvez-vous garantir que chaque connexion wallet et chaque donnée continueront de fonctionner ?
Non. Les fournisseurs de wallet, les réseaux, les contrats et les services de données peuvent changer leur disponibilité, leur gestion ou leur compatibilité. Nous pouvons construire et tester le comportement convenu de l'application pour des intégrations sélectionnées, puis documenter les dépendances. Par exemple, la remise peut montrer quelle connexion l'application attend et ce que votre équipe doit surveiller.
Parlez-nous de votre projet
Répondez à quatre questions et un responsable vous enverra un plan, un calendrier et une fourchette de prix sous une heure. Tout reste confidentiel.
Chargement du formulaire…