¿Pueden los diseñadores e ingenieros utilizar una única fuente de verdad? Parte 1.

La pesadilla recurrente para diseñadores e ingenieros (Parte 1 de 2)

Eres un diseñador

Su último proyecto, al igual que todos los proyectos anteriores, terminó en una espiral de caos.

Comenzó con su limpio archivo vectorial que detalla las pantallas principales, pero terminó como semanas de ida y vuelta con ingenieros y partes interesadas. Todos querían opinar. Todos encontraron algo perdido. Tantas piezas de UI tienen muchos estados, ¡no es de extrañar que hayas olvidado dibujar una mesa de trabajo completa para cada una de ellas! Además, el primer ministro te estaba amenazando con todos los plazos. Ah, y su herramienta de vectores comenzó a retrasarse con más de 100 mesas de trabajo que detallan los estados que las personas han solicitado ver. ¡Las cosas se pusieron agitadas rápidamente! Justo cuando pensabas que tienes algo de control sobre este desastre, los desarrolladores terminaron el primer conjunto de características. Sentiste la sangre corriendo por tu cara, nada se ve como se supone que debe ser. La tipografía estaba en mal estado. Los colores están apagados.

Te preguntaste: "¿Por qué los ingenieros no pueden hacer las cosas bien?" Después de todo, les enviaste tu proyecto vectorial acompañado de una especificación CSS generada por esta nueva herramienta moderna. Los ingenieros dijeron que usaron la especificación y que debes dejar de usar herramientas de ilustración vectorial para el diseño de la interfaz de usuario, pero no estás de acuerdo. Todos en su comunidad de Slack de diseño usan esta herramienta.

Empiezas a alzar la voz al notar que tu selector de fechas se ve completamente diferente. Dicen que ya tienen un selector de fechas y que codificar uno nuevo retrasaría el proyecto, probablemente generaría más errores y probablemente sería terrible para los usuarios también. No tienes idea de lo que están hablando. Su biblioteca de símbolos de vectores no tiene este selector de fecha que mencionaron. Y para agregar insulto a la lesión, ni siquiera crearon esta increíble animación para la que les enviaste un GIF. Aparentemente, tomará al menos dos semanas recrearse.

Te sientes derrotado. Utiliza las herramientas que parecen ser populares y, sin embargo, nunca puede ofrecer las experiencias que planeó. El proceso parece roto.

Eres ingeniero

Su último proyecto, al igual que todos los proyectos anteriores, terminó en una espiral de caos. Los diseñadores, una vez más, no especificaron todos los estados de los componentes, pero generaron una alarma cuando llenaron los espacios en blanco con los elementos de desplazamiento y activos basados ​​en las clases que ya tenían en sus archivos CSS. Su impaciencia llegó al límite en una reunión de 3 horas sobre inconsistencias entre las imágenes vectoriales y el código real. Hiciste todo lo posible para explicar que las ilustraciones estáticas creadas en esos archivos vectoriales no pueden recrearse con precisión en el código. Los navegadores y las herramientas vectoriales viven en mundos completamente diferentes y las cosas siempre se verán diferentes. Los diseñadores no querían escuchar y constantemente atacaban a su equipo con el concepto de "diseño perfecto de píxeles". Querías decir que sería perfecto en píxeles si usaran herramientas que realmente usan CSS para el estilo. Sin embargo, te detuviste. Has tenido esta discusión (argumento) antes. Todavía espera que algún día los diseñadores comprendan, que los usuarios no se preocupen por sus archivos vectoriales perfectos, los usuarios solo experimentan lo que se creó en el código. A menos que los diseñadores comiencen a trabajar más cerca del código, las cosas siempre se romperán.

Pusiste los ojos en blanco cuando trajeron el tema de un selector de fechas. Su equipo hizo el esfuerzo de crear una biblioteca modular de componentes que se reutilizan en todas las interfaces. Le ahorra mucho tiempo a todo su equipo, definitivamente mejoró la experiencia del usuario (todos los componentes se prueban correctamente) y hay menos errores en el sistema. No es tu culpa que los diseñadores tengan problemas para sincronizar con esta realidad. Si le preguntaran, diría que intentar dibujar manualmente todos los componentes que ya existen en el código es una idea terrible y siempre será una fuente de errores. Ellos no escuchan

Y la gota que colmó el vaso: una vez más, diseñaron algunas animaciones en una herramienta que genera un GIF. ¿Realmente esperan que codifiques algo mientras miras un GIF de 5 segundos? No solo es un proceso terrible, sino ¿qué pasa con la fecha límite del proyecto? ¿Qué pasa con el rendimiento de esta elegante animación?

Te sientes derrotado. Estás viendo otra larga noche tratando de ponerte al día con todos los cambios que se harán. Usted sabe que el resultado final será decepcionante y desearía que las cosas estuvieran más unificadas. Este proceso está completamente roto.

Herramientas incorrectas Procesos incorrectos.

¿Suena familiar? Este es el estado del desarrollo de productos digitales en 2019.

Los diseñadores e ingenieros expresan sus pensamientos e ideas con herramientas que carecen de compatibilidad y sincronicidad. Los desarrolladores trabajan con las tecnologías de producción finales específicas de la plataforma, los diseñadores a menudo usan herramientas de ilustración vectorial (Sketch, Figma, XD ...) para diseñar representaciones estáticas de interfaces.

Esos dos no podrían ser más diferentes y menos compatibles:

  • Los diferentes motores de representación utilizados, por ejemplo, en un navegador y una herramienta de ilustración vectorial, causan diferencias irresolubles en la representación de fuentes, colores y gradientes.
  • Animar mesas de trabajo estáticas con herramientas que generan archivos GIF (por ejemplo, Principio) conduce a un proceso a menudo doloroso y lento de traducir un GIF en código confiable y con rendimiento.
  • La falta de conexión entre componentes codificados y herramientas de ilustración vectorial detiene la adopción de sistemas de diseño y conduce a una experiencia de producto inconsistente, con errores y costosa.

La salida incorrecta de una herramienta de diseño conduce a la entrada incorrecta proporcionada al proceso de desarrollo. Esos resultados combinados en la salida incorrecta experimentada por los usuarios. Mientras la entrada siga siendo incorrecta, el resultado final no será satisfactorio.

Dejame darte una analogía. Imagina que estás horneando un pastel. Estás viendo la foto de un pastel de limón con un aspecto excelente en un libro de recetas. Lo primero que debe hacer es obtener una taza de harina. Sin embargo, te sientes creativo, así que, en cambio, arrancas la receta del libro y la trizas hasta obtener un grano fino. Mmm ... Parece harina y está hecha de las mismas cosas que la ilustración del libro. Debe llevar a un delicioso postre, ¿verdad? No. La entrada es completamente incorrecta y, a menos que la reemplace por algo real, ese pastel enfermará a su querida familia. Sin mencionar el sabor horrible.

Hornea el pastel con ingredientes reales. Foto de Alexandra Golovac en Unsplash.

Los diseñadores deben volver a la realidad y "hornear el pastel" con ingredientes reales, no imágenes de ingredientes. Y las herramientas de diseño tienen que poder generar los ingredientes reales ... no meras imágenes.

He aquí una idea: no culpe a los diseñadores. No culpes a los ingenieros. Culpe a las herramientas de diseño que están atrapadas en el paradigma incorrecto y evitan que la industria avance hacia un diseño unificado - proceso de ingeniería.

Echa un vistazo a la segunda parte de este artículo sobre cómo resolver esta pesadilla en curso.