Cómo los desarrolladores frontend pueden ayudar a cerrar la brecha entre diseñadores y desarrolladores
Publicado: 2022-03-10En los últimos nueve años, casi todos los diseñadores con los que trabajé me expresaron su frustración porque con frecuencia tenían que pasar días dando retroalimentación a los desarrolladores para corregir espacios, tamaños de fuente, aspectos visuales y de diseño que simplemente no se habían implementado correctamente. . Esto a menudo conduce a debilitar la confianza entre diseñadores y desarrolladores, y causa diseñadores desmotivados junto con una mala atmósfera entre las dos disciplinas.
Muchas veces, los desarrolladores todavía parecen tener la mala reputación de ser demasiado técnicos e ignorantes cuando se trata de ser considerados con los detalles que se le ocurrieron al equipo de diseño. Según un artículo de Andy Budd, "[...] muchos desarrolladores están en la misma posición sobre el diseño, simplemente no se dan cuenta". Sin embargo, en realidad (como señala Paul Boag), "los desarrolladores [necesitan] tomar decisiones de diseño todo el tiempo".
En este artículo, proporcionaré consejos prácticos para que los desarrolladores frontend eviten la frustración y aumenten la productividad cuando trabajen con su contraparte creativa.
Mirando a través de los ojos de un diseñador
Imaginemos por un momento que eres un diseñador y pasaste las últimas semanas, si no meses, para elaborar un diseño para un sitio web. Usted y sus compañeros de equipo pasaron por múltiples revisiones internas, así como presentaciones de clientes, y pusieron un gran esfuerzo en ajustar detalles visuales como espacios en blanco, estilos de fuente y tamaños. (En una era receptiva, para múltiples tamaños de pantalla, por supuesto). Los diseños fueron aprobados por el cliente y entregados a los desarrolladores. Te sientes aliviado y feliz.
Unas semanas más tarde, recibe un correo electrónico de su desarrollador que dice:
“El sitio de ensayo está configurado. Aquí está el enlace. ¿Puedes hacer el favor de control de calidad?”
En una emoción de anticipación, abre ese enlace de puesta en escena y después de desplazarse por algunas de las páginas, nota que el sitio se ve un poco fuera de lugar. Los espacios ni siquiera se acercan a lo que sugirió su diseño y nota algunas torceduras en el diseño: fuentes y colores incorrectos, así como interacciones y estados de desplazamiento incorrectos. Su entusiasmo comienza a desvanecerse lentamente y se convierte en un sentimiento de frustración. No puedes evitar preguntarte: "¿Cómo pudo haber sucedido eso?"
La búsqueda de razones
Tal vez hubo muchos malentendidos desafortunados en la comunicación entre los diseñadores y los desarrolladores. Sin embargo, te sigues preguntando:
- ¿Cómo fue la entrega de diseños? ¿Hubo solo algunos archivos PDF, Photoshop o Sketch compartidos por correo electrónico con algunos comentarios, o hubo una reunión de entrega real en la que se discutieron varios aspectos, como un posible sistema de diseño, tipografía, comportamiento receptivo, interacciones y animaciones?
- ¿Existieron prototipos interactivos o de movimiento que ayudan a visualizar ciertas interacciones?
- ¿Se creó una lista de aspectos importantes con niveles definidos de prioridad?
- ¿Cuántas conversaciones tuvieron lugar, con diseñadores y desarrolladores juntos en la misma sala?
Dado que la comunicación y el traspaso son dos puntos clave muy importantes, echemos un vistazo más de cerca a cada uno.
La comunicación es clave
Diseñadores y desarrolladores, hablen entre ellos. Habla mucho . Cuanto antes en el proyecto y más a menudo, mejor. Si es posible, revisen juntos el trabajo de diseño en progreso al principio del proyecto (y regularmente) para evaluar constantemente la viabilidad y obtener aportes interdisciplinarios. Los diseñadores y desarrolladores, naturalmente, se enfocan en diferentes aspectos de la misma pieza y, por lo tanto , ven las cosas desde diferentes ángulos y perspectivas .
El registro desde el principio permite a los desarrolladores familiarizarse con el proyecto para que puedan comenzar a investigar y planificar con anticipación los términos técnicos y aportar sus ideas sobre cómo optimizar las características. Tener controles frecuentes también une al equipo a nivel personal y social , y aprenden a acercarse entre sí para comunicarse de manera efectiva.
El traspaso del diseño al desarrollo
A menos que una organización siga un flujo de trabajo verdaderamente ágil, es probable que en algún momento del proyecto se produzca una transferencia inicial de componentes y activos de diseño (del equipo de diseño a los desarrolladores). Este traspaso, si se hace a fondo, puede ser una base sólida de conocimiento y acuerdos entre ambas partes. Por lo tanto, es esencial no apresurarse y planificar un tiempo extra.
Haga muchas preguntas y hable sobre cada requisito, página, componente, función, interacción, animación, cualquier cosa , y tome notas. Si las cosas no están claras, pida una aclaración . Por ejemplo, cuando se trabaja con equipos externos o por contrato, tanto los diseñadores como los desarrolladores pueden firmar las notas tomadas como un documento de mutuo acuerdo para futuras referencias.
Las composiciones de diseño plano y estático son buenas para mostrar aspectos gráficos y de diseño de un sitio web, pero obviamente carecen de la representación adecuada de interacciones y animaciones. Solicitar prototipos o demostraciones de trabajo de animaciones complejas creará una visión más clara de lo que se debe construir para todos los involucrados.
Hoy en día, existe una amplia gama de herramientas de creación de prototipos disponibles que los diseñadores pueden utilizar para simular flujos e interacciones en diferentes niveles de fidelidad. Javier Cuello explica cómo elegir la herramienta de creación de prototipos adecuada para su proyecto en uno de sus completos artículos.
Cada proyecto es único, al igual que sus requisitos. Debido a estos requisitos, no siempre se pueden construir todas las características conceptualizadas. A menudo, el tiempo y los recursos disponibles para construir algo pueden ser un factor limitante. Además, las restricciones pueden provenir de requisitos técnicos como la viabilidad, la accesibilidad, el rendimiento, la facilidad de uso y la compatibilidad con varios navegadores, requisitos económicos como el presupuesto y las tarifas de licencia o restricciones personales como el nivel de habilidad y la disponibilidad de los desarrolladores.
Entonces, ¿qué pasa si estas restricciones causan conflictos entre diseñadores y desarrolladores?
Encontrar compromisos y construir conocimiento compartido
Para enviar con éxito un proyecto a tiempo y cumplir con todos los requisitos definidos, es casi inevitable encontrar compromisos entre las dos disciplinas. Los desarrolladores deben aprender a hablar con los diseñadores en términos no técnicos cuando explican las razones por las que las cosas necesitan cambios o no se pueden construir en una situación específica.
En lugar de simplemente decir: "Lo sentimos, no podemos construir esto", los desarrolladores deben tratar de dar una explicación que sea comprensible para los diseñadores y, en el mejor de los casos, preparar sugerencias para una solución alternativa que funcione dentro de las limitaciones conocidas. Respaldar su punto con estadísticas, investigaciones o artículos puede ayudar a enfatizar su argumento. Además, si el tiempo es un problema, ¿tal vez la implementación de algunas partes que consumen mucho tiempo se puede trasladar a una fase posterior del proyecto?
Aunque no siempre es posible, hacer que los diseñadores y desarrolladores se sienten uno al lado del otro puede acortar los bucles de retroalimentación y facilitar la elaboración de una solución comprometida. La adaptación y la creación de prototipos se pueden realizar directamente mediante la codificación y la optimización con DevTools abierto.
Muestre a sus compañeros diseñadores cómo usar DevTools en un navegador para que puedan modificar la información básica y previsualizar pequeños cambios en su navegador (por ejemplo, rellenos, márgenes, tamaños de fuente, nombres de clase) sobre la marcha.
Si el proyecto y la estructura del equipo lo permiten, la creación y creación de prototipos en el navegador lo antes posible puede brindar a todos los involucrados una mejor comprensión del comportamiento de respuesta y puede ayudar a eliminar errores y fallas en la etapa inicial del proyecto.
Cuanto más tiempo trabajen juntos los diseñadores y los desarrolladores, mejores comprenderán qué es más fácil y qué es más difícil de construir para los desarrolladores. Con el tiempo, eventualmente pueden referirse a soluciones que han funcionado para ambas partes en el pasado:
"Hemos usado esa solución para encontrar un compromiso en el Proyecto A. ¿Podemos usarla también para este proyecto?"
Esto también ayuda a los desarrolladores a tener una mejor idea de qué detalles son muy específicos y qué aspectos visuales son importantes para ellos.
Los diseñadores esperan que la interfaz se vea (y funcione) como su diseño
El archivo de diseño vs. Comparación de navegadores
Una técnica útil para evitar que los diseñadores se frustren es hacer una comparación simple de izquierda a derecha entre el archivo de diseño que le entregaron y su estado actual de desarrollo. Esto puede sonar trivial, pero como desarrollador, debe ocuparse de tantas cosas que deben funcionar bajo el capó que es posible que se haya perdido algunos detalles visuales. Si ve algunas discrepancias notables, simplemente corríjalas.
Piénselo de esta manera: cada detalle en su implementación que se ve exactamente como fue diseñado le ahorra a usted y al diseñador un tiempo valioso y dolores de cabeza, y fomenta la confianza. No todos pueden tener el mismo nivel de atención a los detalles, pero para entrenar su ojo para notar las diferencias visuales, una ronda rápida de Can't Unsee podría ser una buena ayuda.
Esto me recuerda con nostalgia a un juego que solíamos jugar hace mucho tiempo llamado "Encuéntralo". Tenías que encontrar discrepancias comparando dos imágenes aparentemente similares para ganar puntos.
Aún así, puede que estés pensando:
“¿Qué pasa si simplemente no hay un sistema notable de tamaños de fuente y espacios en el diseño?”
Bueno, buen punto! La experiencia me ha demostrado que puede ser útil iniciar una conversación con los diseñadores pidiéndoles aclaraciones en lugar de comenzar a cambiar radicalmente las cosas por su cuenta y crear sorpresas no deseadas para los diseñadores más adelante.
Aprenda las reglas básicas tipográficas y de diseño
Como afirma Oliver Reichenstein en uno de sus artículos, el 95% de la información en la web es lenguaje escrito. Por lo tanto, la tipografía juega un papel vital no solo en el diseño web sino también en el desarrollo. Comprender los términos y conceptos básicos de la tipografía puede ayudarlo a comunicarse de manera más efectiva con los diseñadores y también lo hará más versátil como desarrollador. Recomiendo leer el artículo de Oliver, ya que explica la importancia de la tipografía en la web y explica términos como micro y macro tipografía .
En la "Guía de referencia para la tipografía en el diseño web móvil", Suzanne Scacca cubre minuciosamente la terminología tipográfica, como el tipo de letra, la fuente, el tamaño, el peso, el interletraje, el interlineado y el seguimiento, así como el papel de la tipografía en el diseño web moderno.
Si desea ampliar aún más su horizonte tipográfico, puede valer la pena leer el libro de Matthew Butterick "Tipografía práctica de Butterick". También proporciona un resumen de las reglas clave de la tipografía.
Una cosa que encontré particularmente útil en el diseño web receptivo es que uno debe aspirar a una longitud de línea promedio (caracteres por línea) de 45 a 90 caracteres, ya que las líneas más cortas son más cómodas de leer que las líneas más largas.
¿Deberían diseñar los desarrolladores?
Ha habido mucha discusión sobre si los diseñadores deberían aprender a codificar, y es posible que te estés haciendo la misma pregunta al revés. Yo creo que uno difícilmente puede sobresalir en ambas disciplinas, y eso está totalmente bien.
Rachel Andrew describe muy bien en su artículo "Trabajando juntos: cómo los diseñadores y desarrolladores pueden comunicarse para crear mejores proyectos" que para colaborar de manera más efectiva , todos necesitamos aprender algo del lenguaje, las habilidades y las prioridades de nuestros compañeros de equipo para que podamos puede crear un lenguaje compartido y áreas de especialización superpuestas.
Una forma de adquirir más conocimientos en el campo del diseño es un curso en línea conocido como "Diseño para desarrolladores" ofrecido por Sarah Drasner en el que habla sobre los principios básicos de diseño y la teoría del color, dos áreas fundamentales en el diseño web.
"Cuanto más aprenda fuera de su propia disciplina, en realidad es mejor para usted [...] como desarrollador".
— Sarah Drasner
El Centro Visual
Al colaborar con diseñadores, aprendí la diferencia entre el centro matemático y el visual. Cuando queremos llamar la atención del lector sobre un determinado elemento, el punto focal natural de nuestro ojo se encuentra ligeramente por encima del centro matemático de la página.
Podemos aplicar este concepto, por ejemplo, para colocar modales o cualquier tipo de superposición. Esta técnica nos ayuda a captar la atención del usuario de forma natural y hace que el diseño parezca más equilibrado:
Estamos todos juntos en esto
En entornos de agencia acelerados y no tan ágiles con plazos ajustados, a menudo se les pide a los desarrolladores que implementen interfaces receptivas completamente funcionales basadas en una maqueta móvil y de escritorio. Esto obliga inevitablemente al desarrollador a tomar decisiones de diseño a lo largo del proceso. Preguntas como "¿A qué ancho disminuiremos el tamaño de fuente de los titulares?" o "¿Cuándo deberíamos cambiar nuestro diseño de tres columnas a una sola columna?" podría surgir.
Además, en el calor del momento, puede suceder que detalles como estados de error, notificaciones, estados de carga, modales o estilos de páginas 404 simplemente se pierdan. En tales situaciones, es fácil comenzar a señalar con el dedo y culpar a las personas que deberían haber pensado en esto antes. Idealmente, los desarrolladores nunca deberían estar en tal situación, pero ¿y si ese fuera el caso?
Cuando escuché al fundador y director ejecutivo de Ueno, Haraldur Thorleifsson, hablar en una conferencia en San Francisco en 2018, presentó dos de sus valores fundamentales:
“Nada aquí es problema de otra persona”.
“Recogemos la basura que no tiramos”.
¿Qué pasa si más desarrolladores comienzan de manera proactiva a simular las partes faltantes mencionadas anteriormente lo mejor que puedan en primer lugar, y luego las refinan junto con el diseñador sentado junto a ellos? Los sitios web viven en el navegador, entonces, ¿por qué no utilizarlo para construir y refinar?
Si bien es posible que corregir las piezas faltantes u olvidadas no siempre sea lo ideal, he aprendido en mis experiencias pasadas que siempre nos ha ayudado a avanzar más rápido y eliminar errores sobre la marcha, como equipo .
Por supuesto, esto no significa que los diseñadores deban ser anulados en el proceso. Significa que los desarrolladores deberían tratar de encontrar a los diseñadores a mitad de camino mostrando iniciativa en la resolución de problemas. Además de eso, el equipo me valoraba mucho más como desarrollador simplemente por preocuparme y asumir la responsabilidad.
Construyendo confianza entre diseñadores y desarrolladores
Tener una relación positiva y de confianza entre el equipo creativo y el técnico puede aumentar considerablemente la productividad y el resultado del trabajo. Entonces, ¿qué podemos hacer nosotros, como desarrolladores, para aumentar la confianza entre las dos disciplinas? Aqui hay algunas sugerencias:
- Muestre un ojo para los detalles .
Construir las cosas exactamente como fueron diseñadas les mostrará a los diseñadores que te importan y les pondrá una gran sonrisa en la cara. - Comunicarse con respeto .
Todos somos seres humanos en un entorno profesional que se esfuerza por obtener el mejor resultado posible. Mostrar respeto por la disciplina de los demás debe ser la base de toda comunicación. - Regístrese temprano y regularmente .
Involucrar a los desarrolladores desde el principio puede ayudar a eliminar errores desde el principio. A través de la comunicación frecuente, los miembros del equipo pueden desarrollar un lenguaje compartido y una mejor comprensión de las posiciones de los demás. - Ponte a disposición .
Tener al menos una ventana opcional de 30 minutos al día en la que los diseñadores pueden discutir ideas con los desarrolladores puede darles a los diseñadores una sensación de apoyo. Esto también brinda a los desarrolladores la oportunidad de explicar cosas técnicas complejas en palabras que las personas no tan técnicas pueden entender mejor.
El resultado: una situación en la que todos ganan
Tener que dedicar menos tiempo al control de calidad a través de una comunicación efectiva y una entrega adecuada de los diseños le da al equipo creativo y de desarrollo más tiempo para concentrarse en crear cosas reales y menos dolores de cabeza. En última instancia, crea una mejor atmósfera y genera confianza entre diseñadores y desarrolladores. La voz de los desarrolladores frontend que muestran interés y conocimiento en algunos campos relacionados con el diseño se escuchará más en las reuniones de diseño.
Contribuir de manera proactiva a encontrar un compromiso entre diseñadores y desarrolladores y resolver problemas como desarrollador puede brindarle un sentido más amplio de propiedad e involucramiento con todo el proyecto. Incluso en la floreciente industria creativa actual, no es fácil encontrar desarrolladores que, además de sus habilidades técnicas, se preocupen y tengan buen ojo para los detalles visuales. Esta puede ser su oportunidad de ayudar a cerrar la brecha en su equipo.
Recursos Relacionados
- “Cómo elegir la herramienta de creación de prototipos adecuada”, Javier Cuello
- “Una guía de referencia para la tipografía en el diseño web móvil”, Suzanne Scacca
- "La tipografía práctica de Butterick", Matthew Butterick
- “Trabajando juntos: cómo los diseñadores y desarrolladores pueden comunicarse para crear mejores proyectos”, Rachel Andrew
- "Diseño para desarrolladores", Sarah Drasner, maestra de frontend
- “El diseño web es 95% tipografía”, Oliver Reichenstein
- “Can't Unsee”, un cuestionario de navegador para entrenar su sentido de reconocer detalles visuales.