Partir d’un parcours réel
Imaginez une entreprise de réparation à Budapest. Un nouveau client veut comprendre la prestation, envoyer des photos et demander un rendez-vous. Le technicien doit consulter ses interventions, noter le travail effectué et continuer quand la connexion devient mauvaise. Ce sont deux parcours différents. Pour chacun, listez les étapes, les informations nécessaires et les situations d’échec. Deux personnes liées à la même entreprise n’ont pas forcément besoin de la même interface. Vérifiez vos hypothèses avec celles qui réalisent réellement ces tâches.
Envisager le web pour le premier contact
Un site ou une application web mérite d’être envisagé lorsque les clients arrivent par une recherche ou un lien partagé et accomplissent une tâche occasionnelle. MDN présente l’accès par adresse web et la possibilité d’applications web progressives installables. Pour notre entreprise de réparation, commencez par des pages de services claires et une demande courte. Rendez ce parcours utile sur téléphone avant d’ajouter un compte, un tableau de bord ou un programme de fidélité dont la nécessité reste à démontrer.
Vérifier la raison de créer une application mobile
Une application mobile devient pertinente lorsqu’elle répond à un besoin précis et récurrent sur téléphone. Demandez au technicien de raconter sa journée : quelles informations doivent rester accessibles, quand ajoute-t-il des photos et que se passe-t-il après une interruption ? Testez le comportement le plus dépendant de l’appareil sur les téléphones réellement utilisés par votre public. Installation, autorisations, connexion au compte et reprise d’un travail commencé font partie du produit. Ce ne sont pas des détails à régler après le lancement.
Associer les deux quand les usages le justifient
Un site public et une application mobile peuvent servir des personnes différentes tout en partageant les mêmes règles métier. Dans notre exemple, le client envoie sa demande sur le web et le technicien gère l’intervention acceptée sur mobile. Définissez ce que signifient demande, rendez-vous et travail terminé avant de relier les interfaces. Le guide d’architecture Android recommande de séparer les responsabilités. Appliquez cette rigueur à votre produit : attribuez clairement la gestion des données, des erreurs et des changements pour éviter que les expériences divergent.
Prévoir les langues et le suivi
Pour une entreprise hongroise qui sert une clientèle européenne, commencez par les langues que vous pouvez entretenir correctement. Vérifiez le parcours entier dans chacune, y compris les confirmations, les écrans sans résultat et les coordonnées. Prévoyez de la place pour des libellés plus longs. Désignez les responsables du support, des contenus et des prochaines versions. Le choix d’une plateforme implique aussi du travail dans la durée : notez les appareils, navigateurs et tâches clients qui doivent rester fonctionnels après chaque changement important.
Rédiger un brief que l’on peut vérifier
Avant de demander une estimation, présentez à l’équipe un public principal, un parcours complet et une courte liste de contraintes réelles. Distinguez le fonctionnement indispensable des options séduisantes. Convenez des critères qui permettront de déclarer la première version prête et de ce que vous souhaitez apprendre de son utilisation. Une plateforme supplémentaire doit répondre à un besoin client encore insatisfait. La présence d’une application chez un concurrent ne suffit pas, à elle seule, à justifier un nouveau produit.
- Nommer la tâche et la personne qui l’accomplit.
- Identifier les appareils, langues et conditions de connexion importants.
- Décrire simplement la réussite, l’interruption et l’échec.
- Choisir une petite première version, un responsable et un point de bilan.