Maquettes: codage vs dessin?


9

Il ne s'agit pas de conception Web, mais de conception d'interface en général. Est-il préférable de coder des maquettes d'interface ou de les "dessiner" dans un programme graphique, comme GIMP, Photoshop, etc.?


3
On me dit toujours "esquissez votre interface, si vous le faites dans Photoshop ou tout ce que les gens penseront que vous êtes plus loin que vous ne l'êtes vraiment. Laissez vos maquettes un peu sommaires, décrivez simplement les bases pour que votre client sache à quoi s'attendre, puis développez sur votre interface utilisateur plus tard. "
Hanna

1
Cela dépend entièrement du projet. Il n'y a pas de «meilleure» réponse universelle.
DA01

Réponses:


14

Posez-vous ces questions:

  • Combien de dispositions / options d'interface utilisateur pouvez-vous explorer en 30 minutes en codant? Combien pouvez-vous explorer en esquissant?

  • À quelle fréquence obtenez-vous une conception d'interface utilisateur exactement dès le premier essai? Si ce n'est pas très souvent, est-il rapide / facile de changer un croquis par rapport à une maquette codée?

  • Pouvez-vous identifier instantanément une couleur simplement en regardant son code hexadécimal / RVB (pas seulement une estimation approximative, mais la nuance / couleur exacte)? Lorsque vous imaginez une couleur dans votre esprit, pouvez-vous immédiatement la traduire en hexadécimal? À quelle vitesse pouvez-vous choisir un schéma de couleurs en tapant des codes hexadécimaux par rapport à un véritable sélecteur de couleurs?

Le fait que vous posiez cette question me dit que vous êtes très probablement un programmeur, pas un concepteur, de formation. Si vous étiez un concepteur, ce serait aussi absurde que de développer une application sans planifier la structure de la classe, la conception de la base de données, l'architecture de l'application, etc. et simplement passer directement au codage - et si vous êtes un développeur expérimenté, alors vous savez quel genre de problèmes ce type de développement ascendant provoque.

De même, si vous passez directement au code sans réellement concevoir d'abord votre interface utilisateur, les résultats ne seront pas jolis, ne serait-ce que parce qu'il est impossible de perfectionner un bon design en codant à l'aveugle.


L'OP pourrait être sur le point d'utiliser un éditeur de code WYSIWYG, avec lui, vous pouvez choisir des couleurs ou même "dessiner" les objets ...
jackJoe

2
En fait, coder sans concevoir d'abord l'interface utilisateur est une technique tout à fait valable. C'est, bien sûr, si le "codage" ne signifie pas les parties UI ou UX :). La plupart des API et des bibliothèques sont conçues en fait sans prendre en compte l'interface utilisateur - ce serait tout simplement impossible.
thebodzio

1
@lese, vous proposez une méthode en cascade. Ce qui peut être correct, mais la tendance actuelle est de devenir agile, dans laquelle il est très probable que vous travailliez dans le code dès le premier jour.
DA01

@ DA01: Vous travaillez sur le code depuis le premier jour, mais vous appliquez toujours une méthodologie descendante. Il n'y a rien dans agile qui dit que vous ne pouvez pas planifier votre architecture de données ou définir l'interface utilisateur avant de coder (ce que je pense que la plupart des entreprises agiles préfèrent à UML, aux diagrammes de classes, etc.).
Lèse majesté

2
@thebodzio: Oui, bien sûr, c'est à cela que sert la séparation des préoccupations. Mais je ne parle pas de coder le backend. Quand je dis le codage en termes de partie de conception de la question (pas l'analogie de programmation que j'ai utilisée pour illustrer le point - je sais, un peu déroutant), je veux dire le codage de la maquette (CSS + HTML ou quel que soit votre langage d'interface utilisateur peut être ).
Lèse majesté

5

Je voterais pour le "dessin" en premier. Dans l'interface graphique, une mise en page / présentation appropriée est la clé et elle nécessite la conception de moyens visuels. La conception graphique de l'interface graphique vous permet de modifier rapidement votre conception sans avoir à «imaginer» chaque modification, à la «traduire en code» et enfin à la tester. L'autre façon est également possible, mais elle est rarement meilleure (par exemple, le projet est extrêmement petit, comme seulement quelques boutons et vous êtes familier et habitué à travailler au niveau du "code"; lors de la conception, certains modèles peuvent émerger, cela peut être juste réutilisé avec une légère modification).

Si vous concevez pour une boîte à outils de widget spécifique, vous pouvez également utiliser une application "GUI designer" si disponible. Cela accélérera encore plus le processus de conception de l'interface graphique, car il montre à la fois à quoi ressemblera l'interface graphique conçue dans le programme en cours d'exécution et peut exporter une description GUI prête à l'emploi au niveau de la présentation.


2
"et vous êtes familier et habitué à travailler au niveau" code "" -> Il est important que l'équipe UI / UX puisse travailler au niveau du code. Chaque concepteur ne doit pas nécessairement être un codeur, mais l'équipe doit être en mesure de construire tout ce qu'il conçoit et de comprendre l'ingénierie autant que la conception visuelle.
DA01

Je peux être d'accord tant que vous parlez d'une équipe dans son ensemble. Je pense que, lorsque vous concevez simplement l'interface utilisateur / UX, pas le codage, la connaissance du fonctionnement interne du code peut en fait vous retenir, car vous aurez tendance à éviter certaines solutions potentielles uniquement parce que vous les considérerez "trop ​​difficiles à mettre en place". Cela signifie que vos conceptions peuvent être dépouillées de certaines idées brillantes, car la "réflexion sur la boîte à outils" enfermera des parties de votre imagination. Là encore… ce n'est qu'un côté de la lame :) En outre, la question portait uniquement sur les «maquettes».
thebodzio

1
J'entends souvent l'argument `` vous retenir '', mais je trouve que cela ne vient que de concepteurs visuels qui sont obstinément opposés à l'apprentissage du code de couche de présentation. Ces gens ont également tendance à tout faire dans Flash. :) J'aime suggérer que ce n'est pas différent de la conception d'impression. Savoir comment fonctionne l'impression ne vous «retient» pas en tant que concepteur d'impression. Au contraire, cela vous empêche de créer des fichiers qui vont étouffer le RIP, ou faire crier l'imprimante pour vous pour une couverture d'encre de 300%. Il s'agit simplement de comprendre le support et ses contraintes associées.
DA01

1
WYSIWYG n'est pas destiné à faciliter la «pensée visuelle». C'est pour permettre aux gens qui ne veulent pas apprendre quelque chose de boiteux. ;) Quant aux contraintes, elles définissent le support. Un architecte qui peut dessiner de superbes images, mais qui ne comprend pas les bases des charges et des portées est en grande partie retenu ... car rien de ce qu'ils dessinent ne peut réellement être construit.
DA01

1
(et une grande partie de mon opinion a été formée en travaillant avec ou sur des équipes UX qui n'ont aucune idée de comment construire tout ce qu'elles proposent. Elles n'innovent pas la plupart du temps ... mais conçoivent plutôt à moitié réfléchi des solutions qui ne sont pas pratiques en termes d'implémentation, de délais, d'utilisateurs ou de budgets [qui sont toutes des contraintes supplémentaires qui, plutôt que d'être des «murs», contribuent à définir la solution de conception]) PS: bonne discussion!
DA01

3

Pour la conception de l'interface utilisateur, j'ai trois étapes avec des objectifs différents:

  1. Esquisse. Tout d'abord, vous voulez avoir une idée de base de quels éléments il y aura et comment ils s'emboîteront. Tout détail fin ou perfectionnisme esthétique à ce stade est une distraction. J'utilise un tableau blanc et un gros stylo effaçable, il est donc impossible de se laisser distraire par trop de détails et de griffonner des tonnes d'idées différentes et de recommencer à tout moment. J'ai entendu parler de gens qui ne font que des croquis sur de petits post-it ou qui n'utilisent que leur main (par exemple la main gauche si vous êtes droitier) pour se forcer à ne pas prêter attention à l'esthétique et à se concentrer à 100% sur l'idée et la fonction. (image pas la mienne, de Frank Prendegast )

Photo de tableau blanc filaire

  1. (2!) Simuler.Deuxièmement, vous voulez obtenir un aperçu et obtenir des commentaires, en savoir autant que possible sur les intuitions et les réponses spontanées des gens avant de commencer le travail d'implémentation qui prend du temps. Cela devrait être dans tout ce que vous travaillez le plus efficacement, car si vous le faites correctement, vous devriez souvent revenir `` à la planche à dessin '', chercher des critiques et chercher à identifier le plus tôt possible des problèmes inattendus. Si vous êtes une machine à coder folle et que vous travaillez le plus confortablement, le codage est bien, mais la plupart des gens travailleront plus rapidement dans quelque chose comme Fireworks, Photoshop, un logiciel de wireframing dédié ou peut-être un constructeur d'interface basé sur l'interface utilisateur comme Flash Catalyst (très bien si le produit final n'est pas Flash, l'objectif est d'obtenir de bons commentaires avant de commencer la mise en œuvre).

  2. (3!) Mise en œuvre. Enfin, vous implémentez la chose et visez à le faire d'une manière qui vous permette d'obtenir plus de commentaires tôt et souvent.

Ces trois parties du cycle de projet ont des objectifs différents, donc s'il s'agit d'un grand projet, il est logique d'utiliser l'outil le plus approprié pour le travail à chaque étape.


2

Cette question est un peu vague et, à ce titre, tout comme les réponses.

De plus, les projets varient énormément, tout comme les équipes.

Cela dit, il n'y a pas de «meilleur». Il s'agit d'utiliser tous les outils dans un flux de travail qui a le plus de sens pour vous et votre équipe.

De manière générale, je dirais que c'est le type de workflow que vous devriez viser:

  1. Esquisser. Crayon + papier. Tableaux blancs. Répéter. Travaillez avec autant de membres de l'équipe que possible.
  2. maquettes low-fi. Pourrait être PSD, pourrait être visio. Cela pourrait être du papier. L'utilisateur les teste.
  3. Accédez à la construction de prototypes. C'est là que vous voulez commencer à en faire autant que possible dans le code de travail. Sautez dans Photoshop selon vos besoins et extrayez-les dans le code aussi rapidement que possible. Poursuivez les tests / itérations des utilisateurs.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.