ux-design-for-architects
Guide permettant aux architectes de concevoir et auditer l'UX des points de contact utilisateur non-UI (API / configuration / extensions). Le design des interfaces visuelles (couleurs, mise en page, etc.) n'est pas couvert.
L'UX ne se limite pas à l'UI ; elle englobe tous les points de contact entre le système et l'utilisateur. Une mauvaise UX sur ces points est difficile à corriger ultérieurement (car les utilisateurs en deviennent dépendants) et réduit les chances de succès global du système. C'est pourquoi elle doit être décidée avant l'implémentation.
Démarche
- Identifier les points de contact : il s'agit d'API, de configurations ou d'extensions (ou plusieurs).
- Identifier l'utilisateur (principe 1) : qui, pour quoi faire, avec quel niveau technique ?
- Lire le guide détaillé correspondant :
- Configuration →
references/configuration.md - API →
references/api.md - Extensions →
references/extensions.md
- Configuration →
- Vérifier selon les 6 principes (ci-dessous). Si vous proposez un design, ajoutez une justification en lien avec un principe.
- Pour un audit, utilisez le format de
references/review-checklist.md. - En cas de divergence, demandez confirmation à l'utilisateur avec une hypothèse (AskUserQuestion).
Les 6 principes de l'UX
| # | Principe | Point clé | Pourquoi |
|---|---|---|---|
| 1 | Comprendre l'utilisateur | Connaître ses objectifs, son niveau technique, son modèle mental et son workflow typique pour agir conformément à ses attentes (principe de moindre surprise) | L'utilisateur agit différemment de ses propres prédictions. Observer et mesurer est plus efficace que demander |
| 2 | Faire le minimum nécessaire | Ne proposer que les fonctionnalités nécessaires. Adopter les standards largement utilisés (OAuth, OpenID, etc.) | Ce qui est fourni devient une dette. Une fois habitués, les utilisateurs supportent mal les changements |
| 3 | Rendre le manuel inutile | Rendre l'utilisation évidente, guider par des recommandations et des indices | L'utilisateur ne lit pas le manuel. Si un problème n'est pas résolu, il juge le produit défaillant |
| 4 | Penser en termes d'échange d'information | Éviter de demander > demander moins > demander de manière facile. Ne pas redemander la même chose | Saisir est une charge. La deviner, la mémoriser, la déduire peut la réduire |
| 5 | Garder le simple simple | Supprimer les obstacles des premières opérations. Fournir des clients préconfigurés ou des exemples | Les débutants abandonnent facilement. La première expérience détermine l'adoption |
| 6 | Concevoir l'UX avant l'implémentation | Concevoir l'UX avant l'architecture, itérer avec des retours | Modifier l'UX après implémentation coûte cher. Retarder l'implémentation, approfondir la conception |
Jugement lorsqu'il faut demander une information (précision du principe 4)
Prioriser :
- Ne pas demander : valeur par défaut raisonnable, détection automatique depuis l'environnement, mémorisation des entrées précédentes, déduction à partir d'informations connues
- Demander moins : uniquement ce qui est vraiment nécessaire
- Demander de manière facile : ne pas utiliser le jargon de l'implémentation interne, mais poser la question de façon que l'utilisateur puisse répondre sans calcul mental (ex. : au lieu de « nombre maximal d'entrées du cache », demander « limite de mémoire pour le cache », ou déduire les détails d'un choix de mode comme « serveur ou client »)
Scène où l'on renvoie une sortie ou une réponse (principe 4)
Sauf contrainte de performance, renvoyer suffisamment d'informations dans un format compréhensible par l'utilisateur pour lui permettre d'anticiper l'action suivante. Si le résultat d'un appel est passé à l'appel suivant, le transmettre avec un minimum de transformation.
Résumé par point de contact
- Configuration : La meilleure configuration est « aucune configuration ». Ensuite, la détection automatique. En dernier recours, l'introduction avec une valeur par défaut raisonnable. La question est : « L'utilisateur a-t-il un meilleur contexte que nous ? » — Si oui, seulement alors en faire une configuration. Ne pas ignorer silencieusement les clés inconnues ou les échecs d'application ; signaler une erreur. Permettre de vérifier les valeurs de configuration valides au démarrage.
- API : Les utilisateurs sont des développeurs. Facile à apprendre, difficile à utiliser de manière incorrecte, chaque étape suivante toujours claire. Faire bien une chose. Ne pas faire écrire de code standard. Suivre les standards. Versionner dès le début. Retarder la publication jusqu'à ce qu'elle soit nécessaire, d'abord utiliser en interne.
- Extensions : Attendre d'avoir une compréhension approfondie du cas d'usage avant d'ajouter (on peut ajouter plus tard par refactoring). Faire bien une chose. Définir les entrées/sorties, ne pas exposer la structure interne. Une fois publié, difficile à modifier.
Échecs fréquents (à suspecter lors de la conception ou de l'audit)
- Manque d'expertise UX / recrutement tardif d'un expert
- Ne regarder que l'UI, négliger l'UX des API, configurations et extensions
- Le responsable technique décide de l'UX, l'expert ne fait que des ajustements mineurs sur l'UI
- Ignorer les propositions de l'expert
- Hésiter entre deux options et se réfugier dans la configuration (reporter le problème sur l'utilisateur)
En l'absence d'expert, le mentionner explicitement et recommander d'impliquer un expert UX tôt. Mais ne pas bloquer la conception faute de conseil ; proposer une solution provisoire suivant ce guide.
Connexion avec la démarche itérative
- Dériver la conception du parcours utilisateur → appliquer ce guide à chaque point de contact du parcours
- Découper itérativement → ne créer que les points de contact nécessaires pour la première tranche (les API publiques ou les extensions peuvent souvent attendre après le MVP)
- Concevoir en profondeur ce qui est difficile à modifier, implémenter lentement → l'UX en est l'exemple typique. Apprendre par l'observation de l'utilisation réelle
Format de sortie
Proposition de design : concis, dans l'ordre « point de contact cible → profil utilisateur → proposition → principe concerné et justification → points en suspens ».
Audit : format de references/review-checklist.md.