Pourquoi les guides de styles ont quoi ne pas faire?
Je suis chargé d'écrire un guide de style pour une application . NET . Actuellement, il y a environ six développeurs qui font tout ce qu'ils veulent en termes de style. Des boutons similaires se trouvent à différents endroits, différentes commandes sont utilisées, etc., etc. C'est un gâchis.
J'ai recherché d'autres guides de style, et ils montrent souvent (toujours?) Ce que pas à faire. Le développeur principal a mentionné que le guide de style serait mieux reçu si j'omis tout "ne pas faire" et que j'inclus uniquement les "faire".
Pourquoi les guides de style ont-ils aussi ce qu'il ne faut pas faire?
Lorsque vous ne fournissez qu'un côté de l'histoire, vous permettez à l'auditeur de remplir lui-même l'autre moitié. Cela peut être un puissant outil de narration d'histoire ...
... mais quand vous ne voulez pas laisser une situation ouverte à l'interprétation, vous devez fournir les deux côtés de l'histoire.
Lorsque vous apprenez à faire quelque chose de nouveau, vous trouverez des guides expliquant les "choses à faire et à ne pas faire de [ma nouvelle compétence]". En fournissant les deux côtés de l'histoire, vous renforcez le bon comportement, vous montrez au lecteur que ce que vous dites comme "correct" est vrai, et "voici quelques exemples de ce qu'il ne faut pas faire, et pourquoi ".
Sans "ne pas", un lecteur peut facilement formuler une justification en faveur de la violation de la suggestion. Rappelez-vous, c'est un "style guide" - pas un "style mandat". Un lecteur peut facilement dire: "Ils l'ont suggéré mais je pense que cela fonctionnera, et ils ne m'ont pas dit de ne pas le faire!".
Fournir un exemple (ou plusieurs exemples) des choses à ne pas faire fait quelques choses pour avoir un grand impact:
- Ils comblent des lacunes qui pourraient autrement être interprétées différemment par différentes personnes.
- Ils donnent une rétroaction visuelle de l'apparence "bonne", par opposition à "mauvaise".
- Ils expliquent pourquoi vous devez le faire correctement et comment le faire incorrectement peut affecter l'expérience.
- Ils montrent au lecteur que vous savez de quoi vous parlez ! Ce n'est pas seulement un guide de style plein de vos préférences subjectives, il prend le lecteur à travers toute l'histoire et leur fait comprendre pourquoi "c'est correct" et "c'est mauvais".
Regardez l'une des directives d'interface humaine (aka: Guides de style) des grandes marques. Ils incluent tous DOS et NE PAS NOTER, et expliquent pourquoi et/ou fournissent des alternatives appropriées:
iOS: 
Android: 
OSX: 
Windows: 
Les Dont peuvent être aussi importants que les Do dans l'UX
Bien que les cadres de conception doivent se concentrer sur la description des pratiques et principes positifs (à faire), il est important de fournir des conseils pour éviter les pièges, les contre-modèles et les erreurs courants.
Certaines meilleures pratiques sont tout simplement plus faciles à articuler dans le négatif que dans le positif. Par exemple, lequel de ces éléments est plus facile à comprendre?
- Assurez-vous que le contenu ne bouge pas lorsque l'utilisateur le lit. De plus, veille à ce que le contenu qui est censé être égal en importance soit affiché simultanément à l'écran (c'est-à-dire qu'il n'y ait pas de biais involontaire vers les éléments visibles vs cachés) ).
- Ne pas utiliser des carrousels.
Suivre les conseils positifs (# 1) devrait éviter l'utilisation de carrousels. Mais cela nécessite beaucoup de réflexion et une compréhension très claire des directives abstraites de la part du concepteur, qui doit trouver comment appliquer les directives à un widget particulier.
Étant donné que les carrousels sont un élément concret populaire, il est très utile de couvrir l'antipattern spécifiquement comme un "ne pas". Les deux ne s'excluent pas mutuellement: par exemple, vous pouvez articuler un principe positif et également signaler les contre-modèles courants à éviter.
Ce principe n'est pas propre à UX. Puisque vous en discutez avec un développeur, il peut être utile de souligner que la plupart des directives de développement utilisent également une combinaison de choses à faire et à ne pas faire. Par exemple, le zen de python contient les choses à ne pas faire suivantes:
Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.
... et les principes de conception Android contiennent ces points négatifs:
Never lose my stuff
Don't interrupt me unless it's important
Le message clé à communiquer au lecteur n'est pas le do et ce n'est pas non plus le don't. C'est la différence entre les deux.
Le fait de montrer les deux côte à côte communique cette différence aussi clairement que possible. Si vous ne leur montrez qu'un seul des deux, ils devineront quelle différence vous aviez réellement en tête.
Il est également utile lorsque quelqu'un a fait une erreur et que vous le référez au guide. Si le guide a un exemple ne pas faire, qui correspond exactement à ce qu'ils ont fait, alors la correction apparaît plus clairement.
J'ai trouvé qu'il y a des exemples de NE PAS FAIRE qui peuvent réellement avoir un impact plus négatif sur un produit qu'un exemple de DO pourrait l'affecter positivement. Un mauvais contraste de couleur ou un mauvais choix de police peut rapidement désactiver les gens, même s'il dispose d'un système de navigation bien pensé et que le flux d'un écran à un autre est parfaitement logique.
Dans le développement de logiciels, nous appelons les exemples NE PAS FAIRE "anti-patterns". Montrer ce qu'il ne faut pas faire a un avantage supplémentaire en ce qu'il vous permet d'identifier des exemples que vous avez pu voir dans le passé et vous empêche de commettre ces erreurs critiques.
Avoir des exemples illustratifs d'une utilisation correcte et incorrecte est idéal pour quelques raisons qui me viennent à l'esprit.
- Renforcement des bons comportements juxtaposés aux mauvais comportements. Sans le
don't, vous autorisez un développeur à s'éloigner trop loin lors de l'implémentation. - Certaines personnes sont des apprenants visuels. Exemple: Ce n'est pas parce que vous dites que la hauteur de ligne doit être 1,5 que quelqu'un comprendra pourquoi sans un exemple illustré de la mauvaise lisibilité fournie par d'autres hauteurs de ligne. Le guide de style est une opportunité pour faire appliquer les directives mais aussi pour enseigner aux autres la valeur de vos décisions de décision.
Don't'scréez des garanties qui prouvent que vous avez réfléchi aux interactions et souhaitez renforcer la cohérence. Si un développeur implémente volontairement ou autrement undon't, vous avez quelque chose de concret à référencer comme sauvegarde de votre point.
J'utilise moi-même un guide de style sur notre application - et je trouve que l'un de ses avantages les plus importants est que vous avez documenté non seulement l'interface utilisateur, mais également la justification de votre décision - qui devrait servir de fondement à la discussion et, finalement, à une meilleure conception. J'espère que cela t'aides.
Si les guides de style ont des "choses à faire" comme "seulement sur du noir" ou seulement des "coins arrondis 4px", vous n'avez pas vraiment besoin de ne pas faire. Du point de vue du concepteur, cette approche peut limiter la créativité mais améliorera certainement la cohérence de l'interface de votre application.
Beaucoup de gens ont naturellement beaucoup d'idées géniales et aussi beaucoup d'idées pas si géniales. Si un développeur reçoit une liste des différentes façons de faire les choses, mais que la liste ne décrit pas comment faire tout ce qui doit être fait, le développeur devra inventer des façons de faire les choses qui ne figurent pas sur la liste. Un développeur dont la première idée sur la façon de faire quelque chose est mauvaise peut perdre du temps à développer cette mauvaise idée si ses problèmes ne sont pas immédiatement apparents. Un développeur qui connaît de nombreuses idées qui peuvent sembler attrayantes mais qui ne le sont vraiment pas peut être en mesure de reconnaître plus rapidement les mauvaises idées et ainsi éviter de passer trop de temps sur elles.
Plus généralement, pour vraiment comprendre ce qui est bon dans quelque chose, il faut comprendre ce qui est mauvais dans les alternatives. Souvent, les leçons les plus intéressantes de l'histoire ne viennent pas de savoir quelles choses ont été essayées avec succès, mais plutôt de savoir quelles fausses voies existent qu'il faut éviter.