Un visiteur passe quatre-vingt-dix secondes sur votre site public. Une réceptionniste passe huit heures par jour dans votre back-office, cinq jours par semaine, pendant des années.
Comparez maintenant la façon dont le budget a été réparti.
Presque chaque projet que je reprends l'a réparti exactement à l'envers : des mois entiers sur le site de présentation, et une interface d'administration qui est ce que le framework a généré, jamais ouverte par la personne qui l'a commandée. Les employés la contournent. Ils tiennent un tableur en parallèle, parce que le tableur est plus rapide. Et ensuite les données du système sont fausses, et tout le monde accuse le système.
Ce que veut dire concrètement « l'admin, c'est le produit »
L'écran correspond à la décision, pas à la table
Un admin par défaut vous donne un formulaire par table de base de données, c'est-à-dire une image de votre schéma, pas du travail de qui que ce soit. La réceptionniste n'édite pas une ligne Appointment - elle essaie de caser un patient le jeudi en regardant qui d'autre est là ce jour-là. Cela demande des écrans différents, même si les deux touchent la même table.
Tout ce que le propriétaire pourrait changer est une ligne, pas un déploiement
Les prix, les horaires d'ouverture, le texte des e-mails, le texte de consentement, le pied de page légal, les champs obligatoires. Si changer l'un d'eux demande un développeur, alors vous n'avez pas livré un système, vous avez livré une dépendance à votre égard. Mon test, c'est la question « est-ce que quelqu'un voudrait plausiblement changer cela sans moi ? », et la réponse est oui bien plus souvent qu'il n'y paraît.
Les actions dangereuses ont l'air dangereuses
Supprimer, rembourser, envoyer à tous les clients, forcer un verrou. Cela demande une friction proportionnelle aux conséquences et - plus important encore - une trace de qui l'a fait. Pas pour prendre quelqu'un en faute, mais pour que « que s'est-il passé ici ? » soit une question avec une réponse.
Cela fonctionne sur la machine qui servira vraiment
Souvent un vieux portable avec une mauvaise connexion à un comptoir d'accueil, ou un téléphone dans un entrepôt. Un admin agréable sur l'écran d'un développeur et inutilisable sur le matériel auquel il est destiné n'est pas terminé.
Le test que j'utilise
Avant la passation, je m'assois à côté de la personne qui va l'utiliser le plus et je la regarde faire une journée normale. Pas une démo - son vrai travail, sans que je dise un mot.
Chaque fois qu'elle hésite, c'est un défaut de conception. Chaque fois qu'elle ouvre un tableur à la place, c'est une fonctionnalité qui manque. Chaque fois qu'elle demande « est-ce que je peux annuler cela ? », quelque chose a besoin d'une confirmation ou d'un historique.
Cela prend une heure et c'est l'heure la plus précieuse de tous les projets que j'ai faits. Pas une seule fois elle n'en est sortie sans modifications.
Pourquoi c'est un argument commercial, pas esthétique
Le rôle du site public est de déclencher une prise de contact. Le rôle du back-office est de faire tourner l'entreprise. Un mauvais marketing vous coûte des leads dont vous n'avez jamais eu connaissance ; un mauvais back-office vous coûte une heure par jour, chaque jour, par employé, plus la qualité des données dont dépendent chaque rapport et chaque décision en aval.
Dépensez en conséquence.
Cela dit, la version la moins chère consiste à ne pas construire le back-office du tout, si quelqu'un en vend déjà un qui convient. C'est l'objet de la note sur quand ne pas construire.