Guide pour les constructeurs non techniques
Décidez de ce que votre première application doit prouver.
Transformez une idée générale en un brief court et testable avant de demander des écrans et des fonctionnalités.
01 — Décrire une personne et une tâche
Supposons que vous aidiez un groupe communautaire à organiser des quarts de travail bénévoles. Une première question utile pourrait être de savoir si un bénévole peut trouver un poste qui lui convient et comprendre comment exprimer son intérêt. C'est plus petit et plus facile à consulter qu'un système de planification complet avec rappels, autorisations et paie.
- Décrivez ce que la personne fait aujourd'hui et ce qui est difficile.
- Choisissez l'action que vous souhaitez rendre plus claire ou plus facile.
- Notez ce que vous observeriez si la première version fonctionnait.
02 — Parcourez le voyage sur papier
Pour l'exemple du bénévole, esquissez une liste d'équipes, les détails de l'équipe et un formulaire d'intérêt. Donnez à chaque écran une tâche. Utilisez quelques exemples de quarts de travail réalistes, y compris un quart de travail complet ou une liste vide, afin que l'examen couvre plus qu'un chemin heureux et raffiné.
- Nommez l'écran de démarrage et l'action suivante.
- Répertoriez les champs nécessaires à ce test.
- Inclut un état vide et un état d'action échouée.
- Conservez les informations personnelles réelles hors des invites et des exemples exploratoires.
03 — Séparer une démo d'un service d'exploitation
Décidez si cette version démontre uniquement le voyage ou doit enregistrer une demande réelle. Une démo peut montrer un exemple de confirmation clairement étiqueté. Un service opérationnel a besoin d'une destination, d'un accès approprié et d'un moyen de récupérer la demande. Confirmez ces exigences avant d’inviter de vrais participants.
- Marquez chaque action échantillonnée uniquement dans le brief.
- Répertoriez séparément les connexions, les autorisations et les besoins de publication.
- Laissez les comptes, paiements et rappels pour plus tard à moins que le premier test n'en dépende.
- Demandez une aide qualifiée lorsque la tâche implique des informations sensibles ou un accès complexe.
04 — Examinez le résultat par rapport au brief
Utilisez la feuille de calcul ci-dessous, puis suivez le guide d'invite du produit pour la transformer en demande de build. Après génération, parcourez le même voyage et notez ce qui s’est passé. Pour l’exemple du bénévolat, une démo réussie peut signifier qu’un nouveau visiteur peut trouver le bon changement et comprendre la prochaine étape sans aucune explication de votre part.
- Demandez à quelqu'un qui ne connaît pas l'idée d'essayer la tâche.
- Enregistrez les étapes déroutantes avant de demander plus de fonctionnalités.
- Effectuez un changement ciblé et répétez la même vérification.
- Élargissez la portée uniquement lorsque le premier voyage répond à votre question initiale.
Un point de départ
Rendez le brief précis.
Adaptez cet exemple à votre entreprise. Séparez les exemples de données des informations réelles sur les clients.
Feuille de travail sur la portée de la première version Personne qui l'utilise : ___ Problème auquel elle est confrontée aujourd'hui : ___ Une tâche à accomplir : ___ Pages nécessaires pour cette tâche : ___ Informations affichées ou saisies : ___ Que se passe-t-il après l'action principale : ___ Ce qui reste uniquement un échantillon : ___ Fonctionnalités laissées pour plus tard : ___ La première version est réussie lorsque je peux observer : ___
Quand vous avez besoin de la prochaine étape
Suivez la documentation du produit.
Avant de commencer.
Dois-je d'abord choisir un langage de programmation ?
Commencez par l'utilisateur, la tâche, les informations et le résultat observable. Si un système existant ou une contrainte technique détermine le langage ou la plateforme, incluez-le dans le brief et confirmez-le auprès de la personne responsable de ce système.
Combien de fonctionnalités une première version doit-elle inclure ?
Utilisez le plus petit ensemble qui vous permet d'inspecter un voyage complet. Il n’existe pas de nombre de fonctionnalités universelles. Une fonctionnalité appartient à la première version lorsque la tâche ne peut pas être testée de manière significative sans elle.
Trouvez votre prochaine étape.
Commencez par une tâche utile