Partez d’une tâche client commune
Imaginons un loueur de matériel à Budapest préparant un site et une application pour les organisateurs d’événements. Le client compose une liste et demande un devis. Sur ordinateur, un tableau peut faciliter la comparaison ; sur téléphone, une liste compacte peut être plus pratique. Les deux doivent décrire les mêmes équipements et exigences.
Avant d’examiner des écrans soignés, précisez brièvement le fonctionnement : accessoires obligatoires, signification des quantités et passage du brouillon à la demande envoyée. Si l’application qualifie un brouillon de « confirmé », un logo identique ne dissipera pas le malentendu. Ces règles proposées concernent un service hypothétique, pas un client existant.
Partagez les significations avant de copier les composants
Demandez un petit catalogue des décisions de conception communes. Des valeurs nommées, souvent appelées design tokens, peuvent définir couleur de marque, rôles typographiques, espacements et apparence des avertissements. « Action principale » explique la raison d’une valeur ; « bouton bleu » renseigne moins sur son rôle. Associez chaque valeur à sa signification et à un exemple.
Le catalogue doit aussi couvrir les formulations et états communs. Brouillon de demande de devis, demande en attente d’examen et demande terminée nécessitent des libellés convenus. Partager des composants peut réduire le travail répété, mais adapter un composant universel complexe peut coûter plus que maintenir deux commandes simples. La réutilisation doit faciliter la compréhension des modifications futures.
Autorisez les différences utiles aux clients
React Native permet de séparer les implémentations par plateforme. Android encourage aussi des présentations adaptées aux différents écrans. Pour notre loueur, tableau sur ordinateur et liste sur téléphone peuvent donc servir la même tâche sans partager tous les détails visuels.
Précisez l’action de Retour, où retrouver un devis inachevé et comment rouvrir une fiche matériel. Vérifiez le clavier sur le site et les interactions tactiles dans l’application. Les recommandations d’accessibilité d’Android préconisent aussi des alternatives aux actions uniquement gestuelles. Ici, retirer un article doit rester possible par une commande repérable, même avec un raccourci par balayage.
Rendez les différences visibles pour l’équipe
Tenez une fiche comparative : tâche client, règle commune, présentation web, présentation mobile et responsable. Chaque différence doit s’expliquer : le tableau facilite la comparaison, la liste mobile donne davantage de place à chaque article. Une différence inexpliquée d’accessoires obligatoires est une anomalie à examiner.
Avant publication, identifiez tous les écrans concernés par une modification de règle commune. Consignez la version des règles et les comportements temporairement non pris en charge. Si une seule plateforme est prête, décidez de reporter la modification ou d’en limiter clairement la disponibilité. Un fichier de conception partagé ne suffit pas à harmoniser des produits publiés séparément.
Utilisez cette liste lors de la prochaine revue
Partez du parcours de devis et recommencez la revue à chaque changement de règles. Demandez les démonstrations suivantes sur des versions fonctionnelles des deux produits.
- Utilisez les mêmes exemples d’équipements et de quantités ; comparez exigences et libellés d’état.
- Rattachez chaque couleur, rôle typographique et avertissement commun à une définition convenue.
- Testez navigation, retrait d’articles et retour au devis inachevé sur chaque plateforme.
- Consignez différences voulues, incohérences restantes et responsable de la prochaine modification.