Maquetas: ¿codificación vs dibujo?

No se trata del diseño web sino del diseño de la interfaz en general. ¿Es mejor codificar las maquetas de interfaz o "dibujarlas" en un programa gráfico, como GIMP, Photoshop, etc.?

Hágase estas preguntas:

• ¿Cuántos diseños / opciones de UI puede explorar en 30 minutos codificando? ¿Cuántos puedes explorar dibujando?

• ¿Con qué frecuencia obtienes un diseño de interfaz de usuario exactamente correcto en el primer intento? Si no es muy frecuente, ¿qué tan rápido / fácil es cambiar un boceto versus una maqueta codificada?

• ¿Puede identificar instantáneamente un color simplemente mirando su código hexadecimal / rgb (no solo una suposición aproximada, sino la sombra / color exacto)? Cuando imaginas un color en tu mente, ¿puedes traducirlo inmediatamente a hexadecimal? ¿Qué tan rápido puede elegir un esquema de color escribiendo códigos hexadecimales en lugar de usar un selector de color real?

El hecho de que esté haciendo esta pregunta me dice que es muy probable que sea un programador, no un diseñador, por capacitación. Si fueras diseñador, sería tan absurdo como desarrollar una aplicación sin planear la estructura de clase, el diseño de la base de datos, la arquitectura de la aplicación, etc. y simplemente saltar directamente a la codificación, y si eres un desarrollador experimentado, entonces sabes qué tipo de problemas causa este tipo de desarrollo ascendente.

Del mismo modo, si saltas directamente al código sin diseñar primero tu interfaz de usuario, entonces los resultados no serán bonitos, aunque solo sea porque no es práctico perfeccionar un buen diseño al codificar a ciegas.

Yo votaría por "dibujar" primero. En la GUI, el diseño / presentación adecuados es la clave y requiere medios visuales para ser diseñados. El diseño visual de la GUI le permite cambiar rápidamente su diseño sin tener que "imaginar" cada cambio, "traducirlo a código" y finalmente probarlo. La otra forma también es posible, pero rara vez es mejor (por ejemplo, el proyecto es extremadamente pequeño, como solo un par de botones y estás familiarizado y acostumbrado a trabajar en el nivel de "código"; durante el diseño pueden surgir algunos patrones, que pueden ser simplemente reutilizado con ligera modificación).

Si está diseñando para un kit de herramientas de widgets específico, también puede usar alguna aplicación de "diseñador de GUI" si está disponible. Acelerará aún más el proceso de diseño de la GUI, ya que muestra exactamente cómo se verá la GUI diseñada en el programa en ejecución y puede exportar la descripción de la GUI lista para usar a nivel de presentación.

Para el diseño de UI tengo tres etapas con diferentes objetivos:

1. Bocetos Primero, desea obtener una idea básica de los elementos que habrá y cómo encajarán. Cualquier detalle fino o perfeccionismo estético en esta etapa es una distracción. Utilizo una pizarra blanca y un rotulador borrable, así que es imposible distraerse con demasiados detalles y es fácil garabatear un montón de ideas diferentes y comenzar de nuevo en cualquier momento. He oído hablar de personas que solo dibujan en pequeñas notas adhesivas o solo usan su mano izquierda (por ejemplo, la mano izquierda si eres diestro) para obligarse a no prestar atención a la estética y enfocarse al 100% sobre la idea y la función. (imagen no mía, de Frank Prendegast )

2. (2!) Simulando.En segundo lugar, desea mirar hacia abajo y obtener comentarios, descubriendo todo lo que pueda sobre cuáles son las intuiciones y las respuestas inesperadas de las personas antes de comenzar el trabajo de implementación que consume mucho tiempo. Esto debería estar en lo que sea que trabaje de manera más eficiente, ya que si lo está haciendo bien, debe regresar a la mesa de dibujo a menudo, buscando críticas y con el objetivo de identificar tantos problemas inesperados lo antes posible. Si eres una máquina de codificación loca y es en lo que trabajas más cómodamente, entonces la codificación está bien, pero la mayoría de la gente trabajará más rápido en algo como Fireworks, Photoshop, software de estructura de alambre dedicado, o tal vez un generador de interfaz impulsado por UI como Flash Catalyst (bien si el producto final no es Flash, el objetivo es obtener buenos comentarios antes de comenzar la implementación).

3. (3!) Implementación. Finalmente, implementa la cosa y apunta a hacerlo de una manera que le permita obtener más comentarios temprano y con frecuencia.

Estas tres partes del ciclo del proyecto tienen objetivos diferentes, por lo que si es un gran proyecto, tiene sentido utilizar la herramienta más adecuada para el trabajo en cada etapa.

Esta pregunta es un poco vaga y, como tal, como lo son las respuestas.

Además de eso, los proyectos variarán enormemente, al igual que los equipos.

Dicho esto, no hay 'mejor'. Se trata de utilizar todas las herramientas en un flujo de trabajo que tenga más sentido para usted y su equipo.

Hablando genéricamente, diría que este es el tipo de flujo de trabajo al que debe aspirar:

1. Bosquejo. Lápiz + papel. Pizarras blancas. Iterar. Trabaja con tantos miembros del equipo como puedas.
2. maquetas de baja fidelidad. Podría ser PSD, podría ser visio. Podría ser papel. El usuario prueba estos.
3. Llega a la construcción de prototipos. Aquí es donde desea comenzar a hacer todo lo que pueda en el código de trabajo. Acceda a Photoshop cuando lo necesite y saque las cosas del código lo más rápido que pueda. Continuar las pruebas de usuario / iteración.

Lo que funciona para mí es crear maquetas usando un programa que enfatiza no crear diseños perfectos en píxeles. Para mí eso es Balsamiq Mockups, que puedes consultar en http://www.balsamiq.com/products/mockups