Design

Ce que couvre cette catégorie

Des outils pour concevoir des interfaces et les systèmes qui les sous-tendent : écrans, composants, variables, documentation et passation à ceux qui construisent. Certains produits s’arrêtent au dessin, d’autres s’étendent aux prototypes, à la recherche et au circuit de contenu.

Les parcours cliquables destinés à tester une idée se trouvent dans le prototypage. Tout ce qui vise une sortie vidéo ou animée relève de vidéo et enregistrement d’écran.

La collaboration a changé la nature de ces outils

Le logiciel de design était une application solitaire qui produisait des fichiers. C’est aujourd’hui surtout un espace de travail partagé, et ce changement décide du produit qui convient à une équipe.

L’édition multijoueur compte moins que le trafic qui l’entoure : commentaires qui se résolvent, versions à l’historique lisible, liens qui montrent toujours l’état courant, et droits qui permettent à un client extérieur de regarder sans rien casser.

Les produits conçus pour le navigateur gagnent sur l’accès et perdent sur le travail hors ligne et les fichiers lourds. Les produits fondés sur des fichiers inversent les deux. Aucun n’est meilleur en général, et la réponse dépend de la façon dont votre équipe travaille réellement, pas de celui qui est le plus récent.

Les systèmes de design sont le vrai produit

Au-delà de quelques écrans, la valeur passe des dessins au système qui les soutient.

Regardez comment les composants gèrent les variantes, les états, l’imbrication et les surcharges, puis combien une mise à jour devient pénible quand un composant apparaît à deux cents endroits. Regardez ensuite les variables ou tokens : couleurs, espacements, rayons et tailles de texte nommés une fois, avec des modes pour les thèmes et les densités.

Le lien avec le code est l’endroit où les systèmes se justifient. Demandez si les tokens peuvent être exportés dans un format qu’un build sait consommer, et si les noms de composants du fichier correspondent à ceux du dépôt. Quand les deux divergent, tout le monde cesse de se fier au fichier et se met à interroger directement le designer.

La documentation mérite une place dans le même espace de travail. Un système sans règles écrites devient quarante variantes du même bouton en un an.

La passation, et ce dont les développeurs ont réellement besoin

• Mesures et espacements lisibles sans ouvrir un poste d’éditeur.
• Tokens nommés plutôt que des valeurs hexadécimales collées dans un ticket.
• Ressources exportables aux bonnes échelles et dans les bons formats, y compris ceux qu’exige votre plateforme.
• États pour le vide, le chargement, l’erreur et le contenu long, c’est-à-dire là où les maquettes échouent généralement.
• Un lien à jour, pour que personne ne construise à partir d’une capture d’écran collée dans un chat le mois dernier.

Ce cinquième point provoque plus de reprises que n’importe quelle fonctionnalité manquante. Quel que soit l’outil choisi, la source de vérité partagée doit se trouver à un seul endroit accessible à tous.

Fichiers, performances et contraintes ennuyeuses

Les gros fichiers sont l’endroit où ces produits se distinguent. Un document de plusieurs centaines de cadres, avec des images intégrées, des composants imbriqués et dix ans d’historique, vous montrera la différence entre un outil rapide et un outil lent en moins d’une minute.

Vérifiez la profondeur de l’historique des versions, car les formules d’entrée en gardent souvent une courte fenêtre et les décisions de design se discutent des mois plus tard. Vérifiez la disponibilité des plugins si votre flux de travail en dépend. Vérifiez ce que deviennent les liens partagés quand une formule expire.

Postes, lecteurs et coût réel d’une équipe

La tarification se fait par éditeur presque partout. Commentateurs et lecteurs sont gratuits ou bien moins chers. Cette structure récompense le fait de décider qui édite réellement.

Les développeurs, chefs de produit, dirigeants et clients ont généralement besoin de lire et de commenter plutôt que de dessiner. Leur acheter des postes complets est la façon habituelle de payer cette catégorie deux fois plus cher qu’il ne faudrait.

Surveillez aussi les limites entre formules : bibliothèques partagées, branches, authentification unique et droits avancés se trouvent souvent au-dessus du niveau d’entrée, et l’un d’eux est généralement la raison pour laquelle une équipe en croissance change de formule. Des schémas semblables sur le marché sont exposés dans ce que cachent les pages de tarifs.

Avant de vous engager, déménagez un vrai projet. Pas un fichier d’exemple : un fichier vivant, aux calques en désordre, avec un client qui commente au mauvais endroit.

Travailler avec des gens qui ne font pas de design

L’essentiel des frictions de cette catégorie vient des personnes autour de l’équipe de design plutôt que de l’outil.

Les développeurs ont besoin de mesures, de tokens et d’un lien à jour. Les chefs de produit ont besoin de commenter sans rien casser. Les dirigeants ont besoin d’une image, pas d’un fichier de quarante plans de travail.

Organisez cela délibérément. Une page unique par projet contenant les écrans courants, l’exploration étant rangée ailleurs, évite la question récurrente de la version qui fait foi.

La même discipline s’applique au nommage. Des fichiers appelés final, final deux et final validé sont le symptôme d’une convention absente, et aucun produit ne la remplace. Convenez de ce vers quoi pointe le lien partagé et écartez tout le reste du chemin de ceux qui ne le cherchent pas.