Avantages / inconvénients des maquettes PSD par rapport aux maquettes HTML
J'ai lu récemment des articles ( celui-ci et celui-ci ) qui m'ouvrent les yeux sur les maquettes HTML par opposition aux maquettes PSD habituelles.
Dans l'article, ils citent certains avantages:
- Les changements sont beaucoup plus rapides (y compris les changements de couleurs et, dans une certaine mesure, les polices).
- Lorsque vous mettez la page en HTML, vous montrez au client quelque chose de beaucoup plus proche de ce à quoi ressemblera le produit final.
- Ils peuvent voir les effets d'une disposition liquide en modifiant la taille de la fenêtre.
Les inconvénients:
- Tous les concepteurs visuels ne peuvent pas créer une maquette en HTML. Ce sera une tâche à deux. Une personne HTML et une personne Photoshop.
Quels sont, selon vous, les avantages/inconvénients de l'une ou l'autre approche?
Si vous créez un site Web ou une application, les maquettes HTML sont de loin supérieures car vous concevez la maquette dans le format le plus proche possible du produit final. Cela vous permet de définir les attentes beaucoup plus facilement, vous contraint à ce qui est possible dans le produit final et offre une plus grande flexibilité.
Cette convention prend progressivement le nom de "conception dans le navigateur". La conception dans le navigateur contourne la méthode de la cascade par sa nature même. Les maquettes Photoshop introduisent une barrière entre le concepteur visuel et le concepteur d'interaction/UX: la personne travaillant dans Photoshop peut être située loin, en pensant complètement en termes de fidélité visuelle, sans tenir compte du produit final et des contraintes associées du navigateur. Une fois que la maquette de Photoshop est prête, elle est "jetée" à l'équipe UX pour passer à l'étape suivante. Cela ne favorise pas un processus itératif et axé sur la rétroaction.
J'ai écrit n article de blog il y a quelques mois à propos de cette philosophie, que nous avons utilisée dans la construction de notre outil de prototypage. Voici quelques articles auxquels j'y ai fait référence qui peuvent être utiles (y compris celui de Megan Fisher auquel vous avez lié):
D'autres designers et développeurs sont d'accord avec lui:
- 37signals ’ Pourquoi nous ignorons Photoshop explique leur processus: les maquettes Photoshop ne sont pas interactives; ils ne vous donnent pas une idée du flux de l'application; ils vous encouragent à vous concentrer trop tôt sur les détails.
- L'article 24ways.org de Meagan Fisher Make Your Mockup in Markup parle plus des principes de Clarke et explique comment commencer avec la structure HTML permet aux concepteurs d'itérer rapidement sur plusieurs mises en page.
- Ces 12 conseils pour la conception dans le navigateur sur Design Shack offrent également de bonnes informations.
C'est un problème de fidélité.
Le hic, c'est que l'un ou l'autre des documents peut être plus fidèle que l'autre selon ce sur quoi vous vous concentrez.
Un prototype HTML est vraiment le seul moyen de simuler véritablement toute interaction de complexité même modérée. Il n'y a tout simplement aucun moyen de documenter entièrement la conception d'interaction dans un fichier PSD.
À l'inverse, si vous êtes dans un environnement où la conception visuelle est constamment modifiée/améliorée/itérée, le PSD pourrait être le meilleur `` document d'enregistrement '' pour gérer les éléments de conception visuelle.
En fin de compte, je ne pense pas que cela se résume à PSD vs HTML. Vous avez besoin des deux en différents montants en fonction des spécificités de vos besoins sur la base d'un projet et des membres de l'équipe.
Un inconvénient potentiel de l'utilisation de maquettes HTML est que le client peut penser que vous avez terminé l'application - même si vous lui avez dit de quoi il s'agit.
Sérieusement, je connais des gens - à la fois des clients et des gestionnaires - qui, en voyant une maquette utilisant les outils que vous utilisez normalement pour créer le produit réel, pensent que vous avez fait la plupart du travail et sont surpris lorsque vous dites que cela prendra encore 6 semaines (ou quelle que soit la durée) pour faire le travail.
La suppression d'une étape des maquettes pourrait aider à dissiper ce malentendu.
Cependant, après avoir dit qu'une maquette dynamique vous permettra, ainsi qu'au client, d'avoir une meilleure compréhension du fonctionnement du système et de la manière dont vous naviguez dans l'application.
Ce n'est pas le travail du concepteur visuel de préparer des maquettes interactives, mais plutôt celui du concepteur UI/UX. Vrai - souvent, ils sont une seule et même chose, principalement pour des raisons budgétaires, mais leurs emplois sont très différents.
Votre question pourrait en fait être reformulée comme statique vs dynamique maquettes.
À mon avis, les maquettes dynamiques sont presque toujours supérieures aux statiques:
À mon avis, la raison principale est qu'ils peuvent être utilisés pour des tests d'utilisabilité précis - imaginer que vous faites quelque chose est très différent de le faire réellement, en réalisant le temps qu'il faut, la quantité de clics, les mouvements, etc. sensation réelle du flux dans le système.
Cependant, rien n'est sans prix - la création d'une maquette dynamique nécessite généralement beaucoup plus de temps. De plus, cela crée des attentes plus élevées avec le client - si vous appuyez sur un bouton et qu'il fait quelque chose dans le système, vous vous attendriez à ce que tous les boutons fonctionnent de la même manière (et certains pourraient être moins pertinents pour le scénario principal).
Avec une maquette statique, il pourrait également être plus facile de guider les clients et les développeurs à travers les cas d'utilisation - vous affichez simplement les écrans un par un dans le "bon" ordre, en vous assurant que tous les cas d'utilisation sont couverts comme vous le vouliez. L'utilisation d'un modèle dynamique peut donner aux utilisateurs "trop" de liberté, leur faisant manquer des cas d'utilisation clés, etc.
BTW - vous n'avez pas besoin d'être programmeur pour créer des maquettes html. Il existe de nombreux outils (par exemple Axure, Balsamic, Flair Builder et bien d'autres) qui permettent la création de telles maquettes par des non-programmeurs.
Avec la popularité croissante de la conception réactive, il est même plus utile d'utiliser un modèle dynamique (HTML présumé). Lors de la conception de la disposition grossière initiale, je me retrouve à redimensionner constamment le navigateur pour voir comment la disposition fonctionne à plusieurs largeurs.
Essayer de spécifier un design réactif avec une image statique n'est pas possible, et l'exprimer avec plusieurs images statiques prend du temps et est trop complexe.
Réponse anecdotique
J'ai récemment travaillé sur un site où le modèle principal a été conçu dans Photoshop (que j'appellerai "PS"), mais les sections individuelles du site devaient encore être conçues. Je travaillais sur plusieurs sections avec des exigences d'interface utilisateur non standard et j'ai dû décider si j'allais les simuler dans Photoshop ou simplement les faire avec HTML/CSS. J'ai choisi ce dernier et j'étais TRÈS reconnaissant pour cela.
J'ai commencé par baliser le contenu de la page et les éléments de navigation en HTML. Une fois que j'ai eu ça, j'ai juste commencé à jouer avec CSS et à voir ce qui fonctionnait. J'ai pu créer très rapidement plusieurs mises en page totalement différentes et les tester dans un navigateur immédiatement. Il y avait plusieurs options dont je savais qu'elles ne fonctionneraient pas presque instantanément et j'ai pu les abandonner rapidement (où j'aurais normalement terminé la conception sur PS). J'ai également pu ajouter des éléments interactifs (afficher/masquer/etc) qui n'auraient pas été possibles dans Photoshop.
Il y a des choses qui vont juste façon plus rapides en HTML vs PS, des tables par exemple. Il faut un réel effort pour concevoir visuellement des tableaux dans PS avec un contenu texte variable à l'intérieur des cellules et des en-têtes. Il est super rapide en HTML et vous voyez à quoi il ressemblera vraiment.
Bien sûr, cela ne vous amène à ce stade que parce que vous ne pouvez pas tout faire avec CSS. De temps en temps, je retournais à Photoshop et je créais telle ou telle image pour une partie particulière, mais pour la plupart, j'étais surpris de voir tout ce que je pouvais faire avec CSS uniquement.
Ma prise
Je vais toujours prendre cela au cas par cas. Mais je vais certainement pencher vers des maquettes HTML à l'avenir.
Si j'ai raison, je crois que VB a été initialement écrit comme un moyen de créer rapidement des maquettes ... Dans cet esprit, je dirais que la "bonne" réponse est probablement pour suivre la voie des maquettes HTML.
Cependant, je suis en train de créer des maquettes pour un nouveau produit pendant que je tape, et franchement, je ne pense pas que l'effort impliqué dans la création de maquettes html aussi belles qu'elles le font au format PSD, en vaut la peine. Obtenir un peu de texte, ou une image, ou etc., pour apparaître exactement où vous le souhaitez, avec une conception de mise en page complexe, prendra plus de temps à un développeur Web qu'à un artiste de Photoshop ayant des niveaux de compétence similaires.
De plus, si vous allez faire plus que du texte et des conceptions de base, vous allez probablement utiliser Photoshop (ou des packages graphiques similaires) pour faire ce travail de conception - pourquoi vous embêter à compliquer le problème?
Certes, s'il existe une justification réelle pour l'utilisation de maquettes interactives (par exemple, un grand groupe d'utilisateurs pour démontrer comment vous pensez qu'un affichage interactif particulier fonctionnera), alors l'effort supplémentaire en vaut la peine.
Mais si vous montrez simplement à un client à quoi devraient ressembler plusieurs fenêtres d'une application, je ne pense pas que la justification de l'effort supplémentaire soit là?