Pourquoi n'y a-t-il pas plus de guides de conception / style interactifs? Ne sont-ils pas plus conviviaux?
Il semble que seules les grandes entreprises travaillant sur des cadres de développement et de conception produisent des documents interactifs qui fournissent des informations sur les composants/éléments de conception visuelle et interactive. Je fais cette hypothèse parce que dans les projets où j'ai plaidé pour la création de tels actifs, elle rencontre généralement beaucoup de résistance en raison de l'effort perçu nécessaire pour les créer et de la valeur perçue de ces actifs pour guider l'effort de conception et de développement . Cela ne veut pas dire que d'autres entreprises ne les créent pas et ne les maintiennent pas en interne, mais elles ne sont certainement pas visibles à l'état sauvage.
Avec la relance de Google Design (y compris les directives Material Design), les modifications apportées au guide de développement Atlassian et même le nouveau guide de marque d'Uber , ne devrions-nous pas nous orienter vers une forme de documentation interactive et basée sur le Web, car elle convient à la façon dont la conception et les normes UX évoluent?
Quelques références intéressantes que les gens aimeraient peut-être également consulter:
Je pense que la réponse est simple: les petites équipes de conception n'ont pas le temps de le faire. Tout le monde veut publier son propre guide de style. Uber est plutôt bon. Google a un nouveau guide de style pour Android M. Les grands joueurs les ont, et ils les ont pour deux raisons: pour promouvoir leurs styles (qui est une extension de la marque) et à la publicité. Même les équipes de conception, qui aiment partager leur travail, en retirent peu, sauf pour l'exposition. Mais si vous êtes Google ou Apple ou Uber, alors vous êtes prêt à laisser vos vastes équipes de conception travailler sur un guide de style public? Pourquoi pas.
L'autre chose est que de nombreuses entreprises ne veulent pas partager leurs guides de style. Les grandes entreprises le font parce qu'elles veulent que les gens utilisent leurs styles. Cela fait la différence entre une application conçue pour Android ou ... enfin, juste une application.
Les vraies équipes n'ont pas le luxe de ranger leurs guides de style pour la perfection. Ils n'ont pas non plus le luxe de les "finaliser" car rien ne se termine complètement. Finalement, vous n'avez qu'à expédier, et si vous êtes chanceux, il était proche de ce que le guide de style avait au moment de la livraison. Seulement pour une grande entreprise qui peut consacrer les ressources et le temps nécessaires pour créer un guide de style parfait ... c'est pourquoi ils sont les seuls à publier habituellement des guides de style. Le reste d'entre nous a du mal à sortir de bons produits.
Comme le dit Devin dans son commentaire , cette question obtiendra des réponses basées sur des opinions et des observations personnelles. Ce sont les miens.
D'après mon expérience, il existe une différence entre les directives d'une marque (comme ber's ) et les directives générales de conception. Il existe de nombreuses lignes directrices sur la marque publique et la plupart d'entre elles autorisent les tiers à utiliser leur marque et, ce faisant, elles devraient le faire de la bonne manière.
Les directives générales de conception ou les directives de conception de produits sont une autre chose. La réponse à ces questions est de savoir à quoi devrait ressembler l'aspect général d'un produit dans un environnement ou un écosystème spécifique.
Un bon exemple de directives de conception "complètes" est Atlassian's . Il se compose de trois caractéristiques principales; conception du produit, marque et interface utilisateur. Il est utilisé par leurs propres équipes pour développer de nouvelles fonctionnalités et de nouveaux produits mais aussi pour aider les développeurs de plugins à construire leur plugin avec le "look and feel Atlassian". Cela aidera l'utilisateur final à faire la transition entre un produit Atlassian officiel et un plugin tiers.
Les mêmes arguments pourraient être appliqués à directives iOS d'Apple ou directives de conception matérielle de Google . Ils veulent tous que les transitions soient aussi douces que possible et gardent une sensation unifiée de l'écosystème.
Une chose à retenir cependant, ces lignes directrices ne devraient pas restreindre un développeur ou un concepteur - elles devraient aider et être considérées comme ce qu'elles sont, des lignes directrices.