Diseño de respuesta

Y el papel del desarrollo en el diseño.

Esta es una inmersión profunda en el papel del desarrollo en el proceso de diseño, con un enfoque en el diseño receptivo. Está dirigido a líderes / gerentes de diseño y desarrolladores que trabajan con equipos de diseño y diseñadores visuales que buscan convertirse en mejores diseñadores web. Intentaré exponer los problemas y sugerir soluciones prácticas. Espero que ayude.

Diseño web adaptable. ¿Un arte oscuro?

Es 2018. ¿Por qué seguimos hablando de diseño receptivo?

Aprendí por primera vez el diseño receptivo en 2011. Comencé leyendo el libro de Ethan Marcotte, "Diseño web receptivo".

¿Un arte oscuro del diseño web?

El diseño receptivo ha sido una cosa durante aproximadamente 8-9 años. En los primeros días, fue francamente impresionante ver un sitio web receptivo. Casi, un "arte oscuro" de diseño web. Pero eso fue hace mucho tiempo.

En mi papel de diseñador o desarrollador, me resulta extraño que clientes, agencias y diseñadores me sigan pidiendo:

"... Un sitio web receptivo ..."

Mi primer pensamiento es siempre:

'Bueno obviamente…'

Pero, gran parte de mi trabajo de desarrollo web independiente implica "hacer que las cosas respondan". Los diseñadores me piden que les cree un sitio web y luego me envían una maqueta de un sitio web solo para computadoras de escritorio. Y mi primera pregunta es siempre:

“¿Cómo se ve esto en el móvil? ¿En tableta?

Piensa más allá del escritorio

Para citar el libro de Ethan:

Piense más allá del escritorio y cree diseños que respondan a las necesidades de sus usuarios, sin importar cuán grande o pequeña sea la pantalla.

Según mi experiencia, los diseñadores visuales, incluso ahora, no están haciendo esto. O al menos, no hacerlo lo suficientemente bien.

Una historia de horror del diseño web que salió mal

Por contexto, quiero compartir mi peor experiencia real de diseño web que salió mal. Obviamente no nombraré nombres. Solo diré que el sitio web recibió un tráfico significativo, incluido un gran volumen en dispositivos móviles. Y que el negocio dependía de las ventas de su sitio web. ¡Así que fue un gran problema hacer esto bien!

Una empresa había pasado más de 3 meses y más de $ 100,000 en un rediseño masivo de su sitio web. Habían creado un trabajo conceptual hermoso, pero no estaban cerca de un diseño listo para construir, y una fecha de lanzamiento difícil se estaba acercando dolorosamente.

El equipo no había pensado en cómo funcionaría más allá del escritorio. Y cuando pregunté al equipo responsable acerca de cómo funcionaría en otros tamaños, me devolvieron expresiones en blanco, ¡como si estuviera haciendo preguntas locas! Realmente no lo veían como parte de su trabajo pensar en estas cosas.

Habían diseñado una bonita imagen de un sitio web, solo. No hay nada que se pueda construir.

Ahora, no estoy sugiriendo que un período de exploración del concepto de diseño no valga la pena, antes de entrar en el diseño listo para producción ... Pero, habían agotado casi todo el cronograma del proyecto, y la construcción ahora estaba muy atrasada (o más bien, no había comenzado).

Cuando abrí su primer PSD, descubrí que el contenedor del sitio web tenía aproximadamente 1.750 px de ancho. Si aún no estás jadeando, ¡considera que este ancho solo habría funcionado para el 1-5% del tráfico!

Después de un poco de excavación, las razones de todo esto quedaron claras:

Durante meses, hubo un equipo de diseñadores visuales que diseñaron con amor píxeles aislados de cualquier persona con conocimientos de desarrollo o respuesta.

De manera reveladora, habían estado revisando su trabajo en grandes pantallas de televisión e imprimiendo maquetas en pequeños trozos de papel, clavados en la pared de un estudio. Sorprendentemente, nadie durante este proceso había considerado cómo se ve realmente en un navegador web, y mucho menos en pantallas más pequeñas y dispositivos móviles.

Al final, lanzaron (algo) en la fecha límite. Pero, con solo la mitad del sitio web creado, una miríada de problemas y muchos interesados ​​muy infelices que preguntan con enojo:

"¡¿Cómo pasó esto?!"

Los desarrolladores lo resolverán

Desgraciadamente, así es como piensan muchos diseñadores.

He trabajado en innumerables proyectos en los que he tenido que tomar un diseño de escritorio y convertirlo en un sitio web funcional, construible y receptivo.

Como diseñador, estoy llenando los vacíos en el trabajo de otros diseñadores. Pero, como desarrollador, voy más allá * para terminar lo que el diseñador debería tener.

* Nota: Sinceramente, en realidad (a veces) disfruto este desafío como desarrollador creativo. Esto es más que decir; Su desarrollador promedio / equipo de desarrollo no apreciará esto.

¿Qué podemos hacer al respecto?

Creo que todo se reduce a un cambio de mentalidad:

  • Pensar con respuesta.
  • Para repensar su proceso de diseño.

Más adelante en este artículo, voy a cubrir algunas cosas que he probado con los equipos de diseño con los que he trabajado y que han resultado exitosas. Pero primero; La parte más polémica de este artículo ... Prepárate ...

El caso para los diseñadores que aprenden a codificar

Me estoy metiendo el cuello aquí ... ¡Pero no te asustes! Sigue leyendo para conocer mi lógica completa. No es tan "blanco y negro" como podría pensar ...

Esta mentalidad de "los desarrolladores lo descubrirán" no es lo suficientemente buena.

Sin embargo, un diseñador experimentado es más que capaz de ser un buen diseñador web receptivo, si piensa de manera receptiva.

No es tan blanco y negro como los "diseñadores deberían codificar". No es. Pero sí ayuda.

Si realmente no entiendes cómo funciona algo, entonces realmente solo lo apuñalarás. Pero los desarrolladores no quieren que los diseñadores lo apuñalen y luego dejen que ellos descubran cómo funciona realmente.

Todos tenemos que hacerlo mejor, ya sea que los diseñadores aprendan a codificar o que trabajen con diseñadores visuales para enseñarles cómo diseñar mejores sitios web receptivos.

Este es un grabado del siglo XVI, llamado "Dos hombres desollados y sus esqueletos" por el escultor italiano, Domenico del Barbiere.

Esta obra de arte es representativa de artistas renacentistas italianos, como el gran Leonardo da Vinci y Miguel Ángel, que diseccionaron cuerpos humanos muertos para comprender mejor cómo funcionan los músculos, para que pudieran crear pinturas y esculturas más realistas.

Esta práctica es un increíble ejemplo de dedicación a tu oficio. ¡No estoy sugiriendo que comencemos a analizar los usuarios de nuestro sitio web o los desarrolladores web! Pero, es bueno pensar en cómo:

Obtener una mejor comprensión de cómo funciona algo es vital para hacer su mejor trabajo.

Diseccionando una analogía popular

Si alguna vez ha debatido "si los diseñadores conocen el código" con los diseñadores visuales, probablemente haya escuchado esta línea:

"¡Pero los arquitectos no saben cómo construir!"

Bueno no. La mayoría de los arquitectos no pueden construir un edificio. Pero, un buen arquitecto tendrá una buena idea de lo que implica. No solo hacen bonitos dibujos de edificios. Dibujan esquemas. Conocen los materiales utilizados: cómo se ven, se sienten, responden a diferentes luces, etc.

Mi papá era agrimensor. Su trabajo incluía la evaluación de riesgos y poner precio a la visión de los arquitectos, a menudo poco realista. Y comprensiblemente, ¡no le gustaban algunos arquitectos con los que trabajó! (¿Le suena familiar la relación entre diseñadores visuales y desarrolladores? ”)

Pero, los mejores arquitectos con los que trabajó, los que realmente conocían su oficio, diseñaron edificios más realistas y edificables, ahorrando a todos mucho tiempo y dinero. ¡Y le encantaba trabajar con esos arquitectos! Al igual que a los desarrolladores les encanta trabajar con diseñadores que saben lo que hacen. Lo que lo convierte en una cultura laboral más saludable y un mejor producto final.

Mi consejo honesto es:

Aprende a construir lo que diseñas. Simplemente te hará un mejor diseñador web. Creo que te sorprenderá lo mucho que lo disfrutas. ¡Es divertido y muy satisfactorio dar vida a sus propias creaciones y mejorarlas en el navegador!

Pero, en su defecto:

Todo esto no quiere decir que los diseñadores visuales no puedan ser buenos diseñadores web o que se les enseñe un diseño receptivo. Solo tienen que aprender a pensar de manera receptiva, a pensar como un desarrollador, sin saber realmente el código.

Dos formas de abordar el diseño web receptivo

Hay dos formas de abordar el diseño web, pero el proceso de pensamiento, esta noción de pensar de manera receptiva, es siempre la misma. Lo cual, creo que es clave.

Esencialmente, cuánto diseño realmente visualmente (es decir, crear maquetas detalladas) depende de quién lo esté construyendo.

Enfoque 1: cuando alguien más va a construir lo que yo diseño

En este caso, como diseñador:

  • Diseño cada punto de quiebre.
  • Me aseguro de cubrir todos los escenarios y estados.
  • Entrego diseños de plantillas receptivas.
  • Entrego una guía de estilo que cubre todo lo que no es obvio en los diseños visuales, como estados de desplazamiento, etc.

Y el producto final se ve así:

Estudio de caso de diseño del sitio web de marketing de Adobe Portfolio (2016)

Enfoque 2: cuando voy a construir lo que diseño yo mismo

Al contrario de lo que he estado diciendo sobre la cobertura de todos los puntos de corte y escenarios, en este caso, solo diseño para escritorio. Pero siempre estoy pensando y visualizando cómo podría verse en pantallas más pequeñas. Como soy el que lo construyo, accedo al navegador lo más rápido posible para validar mis ideas.

Un ejemplo de este enfoque es mi proyecto personal, Club of the Waves:

Caso de estudio de diseño del Club de las Olas

Como puede ver arriba, solo me burlé de las páginas principales del escritorio.

Mi proceso de diseño fue más o menos así:

  • Este fue un rediseño de un sitio web existente. Entonces, utilicé Google Analytics para averiguar en qué tamaño de navegador ‘la mayoría de las personas ven el sitio web. Luego diseñé mis maquetas de escritorio para que coincidan con ese tamaño.
  • A partir de ahí, diseñé el resto en el navegador, escribiendo código, y viendo que mis cambios ocurren en vivo. De esta manera, puedo ajustar el tamaño, el espacio, el diseño y la animación al contenido de mi corazón.
  • Y puedo probarlo en diferentes tamaños de navegador, agregando los puntos de interrupción necesarios y las consultas de medios a medida que avanzo.

Otro ejemplo de este enfoque para el diseño web es el sitio web de Owl Studios. Me burlé en el escritorio, como se ve a continuación:

Estudio de caso de diseño de Owl Studios

Y luego me divertí con eso, en el navegador:

No tenía un plan real sobre cómo se animaría el sitio web. Simplemente lo sentí, escribiendo código y actualizando el navegador hasta que estuve contento con él. Fue en gran medida "una cosa de desarrollo", pero 100% parte del proceso de diseño.

Y el mismo proceso de "diseño en el navegador" se aplica a todos los puntos de interrupción. A continuación, puede ver capturas de pantalla de cómo se veía en el móvil:

La cuestión del ajuste fino

Acabo de describir cómo afino un diseño en el navegador: agregando animación, ajustando tamaños y espacios, etc.

Piense en lo fácil, eficiente y rápido que es para un desarrollador creativo. Ahora, imagine un diseñador tratando de transmitir esos mismos ajustes a un desarrollador ...

  • ¿Les proporcionas una ronda tras otra de ajustes por correo electrónico?
  • ¿Los persigues en Slack?
  • ¿Envían docenas de problemas de GitHub?
  • ¿Les proporciona un nuevo archivo de diseño que resalta los cambios, varias veces?
  • O, ¿te sientas a su lado y les dices qué hacer?
Te lo prometo, ¡ningún desarrollador quiere un diseñador por encima del hombro, conducción en el asiento trasero!

Independientemente de cómo lo haga, este proceso de ida y vuelta puede llevar mucho tiempo, ser ineficiente y frustrante para todos.

El desarrollo es diseño

Los diseñadores, gerentes de producto, gerentes de diseño e incluso desarrolladores, deben dejar de pensar en el desarrollo como algo separado del diseño.

Y eso no tiene que significar:

  • "Los diseñadores deben codificar".
  • O; "Los desarrolladores deberían diseñar".

Significa; Deberíamos trabajar juntos.

HTML, CSS e incluso JavaScript hoy en día son parte del proceso de diseño.

El diseño no se detiene una vez que abandonas Sketch, Photoshop o XD. O una vez que haya lanzado un sitio web o producto.

  • Modificamos nuestros diseños en el navegador.
  • Probamos nuestros diseños con personas reales,
  • Luego, los diseñadores y desarrolladores trabajan juntos para iterar sobre el diseño.

La animación de sitios web es quizás el ejemplo más obvio de cómo el desarrollo es diseño. Nuestra industria se ha obsesionado con la animación de sitios web. Pero, un diseñador no está haciendo eso *, un desarrollador sí.

* Y no me refiero a los diseñadores que utilizan sofisticados softwares de diseño de prototipos para crear videos y simulaciones que imitan estados de carga e interacciones. Lo siento. Eso no es real. Un desarrollador todavía tiene que recrear lo que hizo el diseñador, tan de cerca como sea realista, dentro del presupuesto y la línea de tiempo.

Epicurrence №6 y Cultura básica, como se muestra en:

Si desarrollar cosas como las anteriores no se considera creativo, o parte del proceso de diseño ... Entonces no sé qué es.

Entonces, en relación con el papel del desarrollo en el diseño:

Hacer:

Incluya desarrolladores front-end y creativos en el proceso de diseño. Obtenga sus opiniones desde el principio y elimine cualquier problema antes de que sea demasiado tarde.

No:

Simplemente descargue los diseños en los desarrolladores al final del proceso, y espero que todo esté bien. ¡O terminarás con una historia de terror para rivalizar con la mía, antes!

Eres un equipo, actúa como uno

Una manera simple de alentar a los diseñadores y desarrolladores a trabajar mejor juntos es hacer que sus equipos de diseño y desarrollo se sientan entre sí. O al menos, cerca uno del otro. No los segregues.

  • Dividir a tu equipo pone límites innecesarios.
  • Crea una cultura divisiva.
  • Y dificulta la colaboración.

He experimentado que esto sale mal muchas veces en grandes empresas y agencias de diseño. No es saludable.

Pensando responsablemente

Ningún diseñador tiene la intención de molestar a los desarrolladores, pero a veces, sin darse cuenta, diseñan cosas que no funcionarán, o no cubren todas las bases. Como alguien que codifica, entiendo esto, pero los diseñadores que se centran exclusivamente en imágenes a menudo no lo hacen. Necesitan aprender a pensar de manera receptiva, a pensar como un desarrollador.

Entonces, ¿cómo enseñamos a los diseñadores visuales a pensar de manera receptiva?

La respuesta no es gritarles cuando cometen errores. Es para educarlos, para que formen mejores hábitos en su proceso de diseño y pensamiento.

A continuación hay 5 cosas que probé con los equipos de diseño en Nueva York, que resultaron efectivas:

1) Diseñar con plantillas receptivas

Aquí hay una plantilla de Sketch que creé para un equipo de diseñadores en un trabajo anterior:

Este enfoque es una buena manera de enseñar a los diseñadores a pensar en todos los escenarios y abordar sus diseños de manera más receptiva.

Una buena plantilla receptiva incluye:

  • Una mesa de trabajo para representar cada punto de interrupción.
  • Cada uno con la cuadrícula sensible claramente visible.
  • En este caso, los puntos de corte equivalían aproximadamente a una vista de escritorio, tableta (retrato) y móvil "grande" y "pequeña".

Ahora, debería decir; Creo que es importante no pensar en un sitio web solo como "escritorio", "tableta" y "móvil". O 'punto de interrupción 1', 'punto de interrupción 2' y así sucesivamente ... Pero, es una forma efectiva de enmarcarlo para personas no técnicas. Y, lo suficientemente bueno para un enfoque de diseño visual como este.

Creo que la lección importante aquí es:

Prueba de estrés

Es poco probable que resuelva todos los problemas de respuesta con un enfoque de maqueta con plantilla como este, pero al menos proporciona a los diseñadores un medio simplista para probar sus diseños. Y con suerte, descubre cualquier falla en el diseño antes de entregarlo a un desarrollador.

2) No es una "versión"

Creo que una realización poderosa para algunas personas es dejar de pensar en los dispositivos móviles y las tabletas como una "versión".

  • No es una versión.
  • Es el mismo sitio web.
  • Es el mismo código HTML.
  • Solo el CSS ha cambiado.

"Versión" es un término heredado de una era de redirigir el tráfico móvil a un sitio web completamente diferente, dirigido a usuarios móviles, una era que reemplazó a los sitios web receptivos. Tenemos que pasar de este término heredado.

Creo que esta "mentalidad de versión" es lo que impide que algunos diseñadores diseñen de manera receptiva.

"Alguien más descubrirá la otra versión ..."

O;

"No tanta gente lo verá en el móvil ..."

Bueno, esta actitud ya no es lo suficientemente buena. Porque la "otra versión" está recibiendo mucha más atención de la que algunos piensan, o les importa pensar. Es parte del trabajo del diseñador pensar más allá del escritorio.

3) Diseño para todos los escenarios, no solo el mejor de los casos

Piense en un diseño receptivo como:

  • Una interfaz de usuario que es casi imposible de romper.
  • Puede tomar cualquier cantidad de contenido y personajes.
  • Y funcionará en cualquier ancho o alto del navegador.

Con demasiada frecuencia, veo diseños que funcionan solo para un número limitado de caracteres, pero puede garantizar que el cliente escribirá más palabras en su título que "Lorem Ipsum".

No diseñe con un número conveniente de caracteres para que se ajuste a su diseño.

Piensa en el diseño y el contenido como algo que funciona en conjunto. No independientemente uno del otro.

No diseñe cosas para impresionar a sus amigos diseñadores, para ganar un premio o para obtener Me gusta en Dribbble. Establezca su trabajo en realidad y diseñe con contenido y datos reales, o una aproximación cercana.

4) Piensa en porcentajes, no en píxeles

Puede diseñar algo de 100px de ancho en su software de diseño. Pero, en el navegador, ese 100px será un ancho porcentual de su contenedor. Por lo tanto, a medida que el ancho del navegador se reduzca, su tamaño de 100 píxeles se parecerá más a 80 píxeles, 60 píxeles, 40 píxeles, etc.

Ahora, piense en el contenido que tiene en esa área de 100 píxeles ...

  • ¿Funcionará en un ancho menor que 100px?
  • De lo contrario, debe repensar el diseño o el contenido.
  • O cree un punto de interrupción para cubrir lo que sucede cuando ya no funciona.

Hago hincapié en este punto de pensamiento en porcentajes y no en píxeles, porque esto es con lo que más lucharon los diseñadores visuales en mi último trabajo. Simplemente no podían entender este concepto de cosas cada vez más estrechas y por qué eso es un problema de diseño.

Creé esta maqueta rápida (arriba) para demostrar este punto a los diseñadores visuales junior (y senior) en mi último trabajo, ¡que resultó realmente efectivo!

  • Muestra la misma cuadrícula de 12 columnas, en 2 anchos de navegador diferentes.
  • Muestra claramente cómo las columnas de la cuadrícula se vuelven más estrechas,
  • Y, qué efecto tiene en el mismo texto, abarcando las mismas 4 columnas en ambos escenarios.

A veces, ver es creer. Demostrar cosas como esta, en una maqueta de diseño o una demostración rápida en el navegador (a través de un servicio como Codepen) puede ser clave para que la gente entienda.

5) Ver diseños en el navegador o en un dispositivo

Volviendo a mi historia de terror anterior: los errores se cometen fácilmente cuando no basamos nuestro trabajo en la realidad. Asi que:

  • No (solo) revise su trabajo en monitores grandes o pantallas de TV.
  • No (solo) imprima maquetas, ni las vea fijadas en una pared.

Ninguno de estos ofrece una descripción precisa de lo que verá el usuario final. Que realmente es lo único que importa.

Además, tenga cuidado al diseñar en pantallas de retina y pantallas pequeñas de portátiles. Por ejemplo, diseñar un sitio web en una MacBook, o en cualquier computadora portátil, es difícil, porque es probable que no pueda ver todo el ancho de la página en el software de diseño. Por lo tanto, acerca y aleja para ver el trabajo a medida que diseña. Pero el problema es este: solo usted, sus amigos diseñadores y sus seguidores de Dribbble ven su trabajo así. El usuario final no lo hará.

Con suerte, esto demuestra mi punto:

A la izquierda está la maqueta de diseño de su página web. Su equipo lo revisa como un diseño completo y coherente, al igual que lo haría con una pieza de diseño gráfico.

Pero, a la derecha, es lo que el usuario ve realmente, en el navegador, a medida que se desplaza. ¡Hay una gran diferencia! Por lo tanto, debe considerar esa realidad, más que la página en su conjunto.

Esto no es diseño gráfico, es diseño web.

Una buena manera de evitar este problema es llegar a un prototipo construido lo más rápido posible. O, la mejor opción, algo así como un prototipo de InVision. De esta manera, su equipo puede revisar el trabajo en el navegador, como lo harían sus usuarios finales ... O, en sus manos en un dispositivo móvil.

Es importante mantener la perspectiva y fundamentar sus diseños en la realidad.

Actualización: 2019. ¡Escribí un libro sobre diseño de sistemas y pautas de marca digital! https://designsystemfoundations.com