Pros / Contras de las maquetas de PSD frente a las maquetas de HTML

Si está creando un sitio web o una aplicación, las maquetas HTML son muy superiores porque está diseñando la maqueta en el formato lo más cercano posible al producto final. Esto le permite establecer expectativas mucho más fácilmente, lo limita a lo que es posible en el producto final y le brinda una flexibilidad mucho mayor.

Esta convención se está volviendo gradualmente conocida como "diseño en el navegador". Diseñar en el navegador evita el método de cascada por su propia naturaleza. Las maquetas de Photoshop introducen una barrera entre el diseñador visual y el diseñador de interacción/experiencia de usuario: la persona que trabaja en Photoshop se puede ubicar lejos, pensando completamente en términos de fidelidad visual, sin considerar el producto final y las limitaciones del navegador. Una vez que la maqueta de Photoshop está lista, se "arroja" al equipo de UX para pasar a la siguiente etapa. Esto no promueve un proceso iterativo orientado a la retroalimentación.

Escribí na publicación de blog hace un par de meses sobre esta filosofía, que hemos estado utilizando para construir nuestra herramienta de creación de prototipos. Aquí hay algunos artículos a los que hice referencia allí que pueden ser útiles (incluido el de Megan Fisher al que se vinculó):

Otros diseñadores y desarrolladores están de acuerdo con él:

• 37 señales ’ Por qué omitimos Photoshop explica su proceso: las maquetas de Photoshop no son interactivas; no te dan una idea del flujo de la aplicación; te alientan a concentrarte en los detalles demasiado pronto.
• El artículo 24ways.org de Meagan Fisher Make Your Mockup in Markup habla más sobre los principios de Clarke y explica cómo comenzar con la estructura HTML permite a los diseñadores iterar rápidamente sobre múltiples diseños de página.
• Estos 12 consejos para diseñar en el navegador en Design Shack también ofrecen algunas buenas ideas.

Es un problema de fidelidad.

El problema es que cualquiera de los documentos puede ser de mayor fidelidad que el otro dependiendo de en qué se esté enfocando.

Un prototipo HTML es realmente la única forma de simular realmente cualquier interacción de complejidad incluso moderada. Simplemente no hay forma de documentar completamente el diseño de interacción dentro de un archivo PSD.

Por el contrario, si se encuentra en un entorno donde el diseño visual se modifica/mejora/itera constantemente, la PSD podría ser el mejor 'documento de registro' para manejar los elementos de diseño visual.

Al final, no creo que se reduzca a PSD vs. HTML. Necesita ambos en diferentes cantidades dependiendo de los detalles de sus necesidades en función del proyecto y de los miembros del equipo.

Un posible inconveniente del uso de maquetas HTML es que el cliente podría pensar que ha finalizado la aplicación, incluso si le ha dicho qué es.

En serio, he conocido personas, tanto clientes como gerentes, que al ver una maqueta usando las herramientas que usas normalmente para construir el producto real piensan que has hecho la mayor parte del trabajo y te sorprendes cuando dices que tomará otros 6 semanas (o el tiempo que sea) para hacer el trabajo.

Eliminar las maquetas un paso podría ayudar a disipar este malentendido.

Sin embargo, habiendo dicho que una maqueta dinámica les permitirá a usted y al cliente comprender mejor cómo funciona el sistema y cómo navega por la aplicación.

No es el trabajo de diseñador visual preparar maquetas interactivas, sino el de diseñador de UI/UX. Es cierto: a menudo son lo mismo, principalmente debido a razones presupuestarias, pero sus trabajos son muy diferentes.

De hecho, su pregunta podría reformularse como Estática vs. Dinámica maquetas.

En mi opinión, las maquetas dinámicas son casi siempre superiores a las estáticas:

La razón principal, en mi opinión, es que pueden usarse para pruebas de usabilidad precisas: imaginar que estás haciendo algo es muy diferente de hacerlo, darse cuenta del tiempo que lleva, la cantidad de clics, movimiento, etc. Por lo tanto, proporciona un sensación real del flujo en el sistema.

Sin embargo, nada tiene un precio: crear una maqueta dinámica generalmente requiere mucho más tiempo. Además, crea expectativas más altas con el cliente: si presiona un botón y hace algo en el sistema, esperaría que todos los botones funcionen de la misma manera (y algunos podrían ser menos relevantes para el escenario principal).

Con una maqueta estática, también podría ser más fácil guiar a los clientes y desarrolladores a través de los casos de uso: simplemente muestra las pantallas una por una en el orden "correcto", asegurándose de que todos los casos de uso estén cubiertos como pretendías Si bien el uso de uno dinámico podría dar a los usuarios "demasiada" libertad, haciéndolos perder casos de uso clave, etc.

Por cierto, no tienes que ser un programador para crear maquetas html. Hay muchas herramientas (por ejemplo, Axure, Balsamic, Flair Builder y muchas otras) que permiten la creación de tales maquetas por parte de no programadores.

Con la creciente popularidad del diseño receptivo, tiene sentido más usar un modelo dinámico (HTML presumible). Al diseñar el diseño aproximado inicial, me encuentro cambiando constantemente el tamaño del navegador para ver cómo funciona el diseño en muchos anchos.

Intentar especificar un diseño receptivo con una imagen estática no es posible, y expresarlo con múltiples imágenes estáticas lleva mucho tiempo y es demasiado complejo.

Respuesta anecdótica

Recientemente trabajé en un sitio donde la plantilla principal fue diseñada en Photoshop (a la que me referiré como "PS"), pero las secciones individuales del sitio aún necesitaban ser diseñadas. Estaba trabajando en varias secciones con algunos requisitos de interfaz de usuario no estándar y tuve que decidir si iba a imitarlos en Photoshop o simplemente hacerlo con HTML/CSS. Elegí este último y estaba MUY agradecido por ello.

De hecho, comencé marcando el contenido de la página y los elementos de navegación en HTML. Una vez que tuve eso, comencé a jugar con CSS y a ver qué funcionaba. Pude crear muy rápidamente varios diseños totalmente diferentes y realmente probarlos en un navegador de inmediato. Había varias opciones que sabía que no funcionarían casi al instante y pude abandonarlas rápidamente (donde normalmente habría terminado el diseño en PS). También pude agregar elementos interactivos (mostrar/ocultar/etc.) que no hubieran sido posibles en Photoshop.

Hay algunas cosas que simplemente van camino más rápido en HTML vs PS, tablas por ejemplo. Se necesita un esfuerzo real para diseñar visualmente tablas en PS con contenido de texto variable dentro de las celdas y encabezados. Es súper rápido en HTML y realmente ves cómo se verá realmente.

Por supuesto, esto solo te lleva muy lejos porque no puedes hacer todo con CSS. De vez en cuando volvía a Photoshop y creaba tal o cual imagen para una parte en particular, pero en su mayor parte me sorprendió ver cuánto podía hacer solo con CSS.

Mi toma

Todavía voy a tomar esto caso por caso. Pero definitivamente me inclinaré por las maquetas HTML en el futuro.

Si estoy en lo cierto, creo que VB se escribió inicialmente como una forma de eliminar rápidamente algunas maquetas ... Con eso en mente, diría que la respuesta "correcta" es probablemente para seguir el camino de las maquetas HTML.

Sin embargo, estoy en el proceso de crear maquetas para un nuevo producto a medida que escribo, y francamente, no creo que valga la pena el esfuerzo involucrado en crear maquetas html que se vean tan bien como en formato PSD. Hacer que un poco de texto, o una imagen, etc., aparezca exactamente donde lo desea, con un diseño de diseño complejo, llevará más tiempo a un desarrollador web que a un artista de Photoshop con niveles similares de habilidad.

Además, si va a hacer más que texto y diseños básicos, probablemente usará Photoshop (o paquetes de gráficos similares) para hacer ese trabajo de diseño, ¿por qué molestarse en complicar el asunto?

De acuerdo, si existe una justificación real para usar maquetas interactivas (por ejemplo, un gran grupo de usuarios para demostrar cómo cree que funcionará una pantalla interactiva en particular), entonces vale la pena el esfuerzo adicional.

Pero si solo le está mostrando a un cliente cómo cree que deberían verse varias ventanas de una aplicación, no creo que exista la justificación del esfuerzo adicional.