Mockups: ¿Codificación vs Dibujo?

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

Siempre me dicen "dibuja tu interfaz, si lo haces en Photoshop o lo que sea, la gente pensará que estás más lejos de lo que realmente estás". en su interfaz de usuario más tarde".
Depende totalmente del proyecto. No hay una "mejor" respuesta universal.

Respuestas (5)

Hazte estas preguntas:

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

  • ¿Con qué frecuencia obtiene 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 en comparación con una maqueta codificada?

  • ¿Puedes identificar instantáneamente un color con solo mirar su código hexadecimal/rgb (no solo una suposición aproximada, sino el tono/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és haciendo esta pregunta me dice que lo más probable es que seas un programador, no un diseñador, de formación. Si fuera un diseñador, sería tan absurdo como desarrollar una aplicación sin planificar la estructura de clases, el diseño de la base de datos, la arquitectura de la aplicación, etc. y simplemente pasar directamente a la codificación, y si es un desarrollador experimentado, entonces lo sabe. qué tipo de problemas causa este tipo de desarrollo de abajo hacia arriba.

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

El OP podría estar hablando de usar un editor de código WYSIWYG, con él puedes elegir colores o incluso "dibujar" los objetos...
En realidad, la codificación sin diseñar primero la interfaz de usuario es una técnica bastante válida. Eso es, por supuesto, si "codificación" no significa partes de UI o UX :). La mayoría de las API y bibliotecas están diseñadas, de hecho, sin tener en cuenta la interfaz de usuario; eso sería poco práctico.
@lese, estás lanzando un método de cascada. Lo que puede estar bien, pero la tendencia en estos días es volverse ágil, en el que es muy probable que esté trabajando en código desde el primer día.
@DA01: está trabajando en el código desde el primer día, pero aún está aplicando una metodología de arriba hacia abajo. No hay nada en Agile que diga que no puede planificar su arquitectura de datos o definir primero la interfaz de usuario antes de codificar (que creo que la mayoría de las empresas ágiles prefieren a UML, diagramas de clase, etc.).
@thebodzio: Sí, por supuesto, para eso está la separación de preocupaciones. Pero no me refiero a codificar el backend. Cuando digo codificar en términos de la parte de diseño de la pregunta (no la analogía de programación que usé para ilustrar el punto; lo sé, un poco confuso), me refiero a codificar la maqueta (CSS + HTML o cualquiera que sea el idioma de la interfaz de usuario). ).
Creo que es una objeción a lo que queremos decir con 'código'. Yo sostengo que diseñar es codificar. También es dibujar, pero uno puede dibujar en código (al menos en la capa de presentación, pueden hacerlo).
@Lèsemajesté: una explicación valiosa, ¡gracias!
@lese puntos válidos!
@ DA01: No iría tan lejos como para considerar que "diseñar" y "codificar" son sinónimos.
@thebodzio son términos vagos y algo genéricos, tan abiertos a todo tipo de debate.
¡¡¡Todo el mundo!!! Estoy hablando de una maqueta, no de la interfaz final.
@christopher también nosotros.

Votaría por "dibujar" primero. En GUI, el diseño/presentación adecuada es la clave y requiere que se diseñen medios visuales. Diseñar GUI visualmente 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á familiarizado y acostumbrado a trabajar en el nivel de "código"; durante el diseño pueden surgir algunos patrones, que pueden ser solo reutilizado con ligeras modificaciones).

Si está diseñando para un kit de herramientas de widget 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.

"y está familiarizado y acostumbrado a trabajar a nivel de "código"" -> Es importante que el equipo de UI/UX pueda trabajar a nivel de código. No es necesario que todos los diseñadores sean codificadores, pero el equipo debe poder construir todo lo que diseña y comprender tanto la ingeniería como el diseño visual.
Puedo estar de acuerdo siempre que te refieras a un equipo como un todo. Creo que, cuando solo estás diseñando UI/UX, no codificando, el conocimiento del funcionamiento interno del código en realidad puede detenerte, porque tenderás a evitar algunas soluciones potenciales solo porque las considerarás "demasiado difíciles de implementar". Significa que sus diseños se pueden despojar de algunas ideas brillantes, porque el "pensamiento de caja de herramientas" bloqueará partes de su imaginación. Por otra parte... es solo un lado de la hoja :) Además, la pregunta era solo sobre "maquetas".
Escucho mucho el argumento de 'retenerte', pero descubro que solo proviene de diseñadores visuales que se oponen obstinadamente a aprender el código de la capa de presentación. Estas personas también tienden a inclinarse hacia hacer todo en Flash. :) Me gusta sugerir que no es diferente al diseño de impresión. Saber cómo funciona la impresión no lo 'frena' como diseñador de impresión. Más bien, le impide crear archivos que obstruirán el RIP o que harán que la impresora le pida a gritos una cobertura de tinta del 300 %. Se trata solo de comprender el medio y sus limitaciones asociadas.
Los diseñadores piensan "visualmente", así que no los culpo por no estar "calientes" para "traducir" sus ideas a un código abstracto. Si eso no fuera cierto, no habría ninguna herramienta WYSIWYG por ahí. Tampoco culpo a los diseñadores por sentirse atraídos por el flash. Mira lo que pueden hacer con él :). Personalmente, prefiero la forma de HTML5, pero esa es otra cosa. Algunas palabras sobre la impresión entonces. Usted ha dicho que conocer su especificidad se trata simplemente de "comprender el medio y sus limitaciones asociadas". ¿Qué hacen las restricciones, si no te retienen?
WYSIWYG no es para facilitar el "pensamiento visual". Es para dejar que la gente que no quiere aprender algo cojee. ;) En cuanto a las limitaciones, definen el medio. Un arquitecto que puede hacer grandes dibujos, pero que no comprende los conceptos básicos de las cargas y los vanos, se retrae en gran medida... ya que nada de lo que dibuja se puede construir en realidad.
Las restricciones son un muro. Algunos muros se pueden derribar, ahí es donde radica el progreso, otros no por ahora. Es bueno saber que están aquí, pero no habrá progreso si todos los muros se consideran permanentes.
Y para profundizar en la analogía, se podría argumentar que a FLW no le importaban las restricciones en absoluto, dibujó lo que se veía mejor y dejó que los ingenieros descubrieran cómo construirlo. Lo admito, FLW dejó un legado de estructuras de gran apariencia, sin embargo, la mayoría de los ingenieros le dirán que todas son increíblemente frágiles, requieren un mantenimiento constante y siempre están a unos pocos meses del colapso total. Al final, el diseño visual pudo haber sido espectacular, pero el diseño total de todo el paquete dejaba mucho que desear.
(el sitio comenzará a gritarnos que pasemos al chat, pero...) Estoy de acuerdo en que el progreso se encuentra justo al otro lado de la restricción. Pero no creo que puedas llegar a ese lado a menos que entiendas completamente las limitaciones actuales. Dicho todo esto, un punto más pragmático: en términos de diseño de interacción, específicamente, simplemente no puedes diseñar la interacción sin el código. Puedes proponer ideas, pero necesitan ser implementadas. Eso es parte del proceso de diseño.
(y gran parte de mi opinión se formó trabajando con o en equipos de UX que no tienen idea de cómo construir cualquier cosa que se les ocurra. No innovan la mayor parte del tiempo... sino que diseñan solo a medias. soluciones que no son prácticas en términos de implementación, plazos, usuarios o presupuestos [que son restricciones adicionales que, en lugar de ser 'muros', son lo que ayuda a definir la solución de diseño]) PD: ¡buena discusión!
WYSIWYG también facilita el aprendizaje y hace mucho menos esfuerzo para la memoria. "Es para dejar que la gente que no quiere aprender algo cojee. ;)" – obtengo el ";)" :), pero incluso las personas "dispuestas a aprender" crearon ensambladores y lenguajes de nivel superior ;). Y sobre el arquitecto cuyos diseños "no se pueden construir"... ¿o sí, si se pone un poco de esfuerzo en romper barreras? :)
@DA01: ¡También disfruté nuestra discusión! :) Argumentos buenos y de alta calidad de su parte, respaldados por la experiencia. Estoy tomando en cuenta tu opinión. Aunque no puedo estar de acuerdo con él en su conjunto, lo respeto plenamente.

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

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

Foto de la estructura metálica de la pizarra

  1. (2!) Simulando.En segundo lugar, desea obtener la mirada hacia abajo y obtener comentarios, averiguando todo lo que pueda sobre las intuiciones de las personas y las respuestas espontáneas antes de comenzar el trabajo de implementación que consume mucho tiempo. Esto debe ser en lo que sea en lo que trabaje de manera más eficiente, ya que si lo está haciendo bien, debería "volver a la mesa de dibujo" con frecuencia, buscar críticas y tratar de identificar la mayor cantidad de 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 las personas trabajarán más rápido en algo como Fireworks, Photoshop, software dedicado de estructuración de cables o tal vez un generador de interfaz basado en UI como Flash Catalyst. (está bien si el producto final no es Flash, el objetivo es obtener buenos comentarios antes de comenzar la implementación).

  2. (¡3!) Implementando. Finalmente, implementa la cosa y trata de hacerlo de una manera que le permita obtener más comentarios temprano y con frecuencia.

Estas tres partes del ciclo del proyecto tienen diferentes objetivos, por lo que si se trata de 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, al igual que las respuestas.

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

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

En términos generales, diría que este es el tipo de flujo de trabajo al que debe aspirar:

  1. Bosquejo. Lápiz + papel. Pizarras. 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. Prueba de usuario estos.
  3. Llegar a la construcción de prototipos. Aquí es donde desea comenzar a hacer todo lo que pueda en el código de trabajo. Salta a Photoshop cuando lo necesites y convierte las cosas en código lo más rápido que puedas. Continúe con las pruebas/iteraciones de los usuarios.

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 puede consultar en http://www.balsamiq.com/products/mockups

Mockups: ¿Codificación vs Dibujo?
RespuestasAquíPolítica de privacidad1y, 0v