Comment prototyper une application pendant un week-end avec Bolt (avant de dépenser de l'argent réel)
La plupart des idées d’applications meurent au tableau blanc ou coûtent une fortune à tester. Cette routine Bolt présente un prototype fonctionnel devant de vrais utilisateurs d'ici dimanche soir, pour le prix d'un week-end.
Une idée qui prend trois mois et un budget de développement à tester ne sera jamais testée, c'est pourquoi le cimetière des tableaux blancs est si plein. Bolt boucle la boucle : mes trois dernières idées de projets parallèles sont chacune devenues un prototype fonctionnel et partageable en un week-end, et l'une d'elles était assez bonne pour être conservée. La routine ci-dessous explique comment passer ces deux jours pour que le dimanche soir se termine par une URL, et non par une pile d'invites.
Le samedi matin, c'est la chirurgie du scope, et cela se produit avant d'ouvrir Bolt. Écrivez le travail en une phrase que fait l'application et les trois écrans qui le prouvent, pas plus. L’échec classique est de demander à Bolt une vision complète, et c’est dans cette vision complète que les prototypes meurent en complexité. Mon prototype de planification était un calendrier, un formulaire de réservation et une confirmation ; tout le reste, les comptes, les paramètres, les panneaux d'administration, attendaient la preuve que le noyau le méritait.
Créez dans l'ordre que les utilisateurs toucheront : du premier écran au dernier, en demandant un écran de travail à la fois et en testant chacun dans l'aperçu du navigateur avant de passer à autre chose. Lorsque quelque chose ne va pas, décrivez le symptôme avec précision plutôt que la solution que vous imaginez, le bouton chevauche l'en-tête sur mobile et ne refactorise pas la mise en page. La spécificité est toute la compétence ici, et les captures d'écran collées dans les paragraphes de description rapides battent à chaque fois.
Le samedi après-midi appartient aux données, car un prototype avec de fausses données est une démo et un prototype avec des données réelles est un test. Connectez les offres backend de Bolt, obtenez votre contenu réel ou un ensemble de données réaliste et cliquez vous-même sur chaque flux avec l'impatience d'un utilisateur réel. Les bugs que vous trouvez samedi soir sont les moins chers ; les confusions UX que vous trouvez sont les plus précieuses, et chacune devient une invite spécifique dimanche matin plutôt qu'une vague reconstruction.
Le dimanche, c'est peaufiner et déployer, dans cet ordre, et la discipline consiste à savoir quand s'arrêter. Corrigez les trois aspérités supérieures, écrivez un véritable premier écran pour que les étrangers comprennent l'application sans instructions, puis déployez et envoyez le lien à cinq personnes qui correspondent à votre utilisateur cible. Regardez ce qu'ils font, pas ce qu'ils disent. Si personne ne l'utilise deux fois, le week-end ne vous coûte que du temps, et s'il le fait, vous construisez maintenant la vraie version avec des preuves, ce qui est tout l'intérêt du prototypage.
