Diseñando con la Mente de Programación

Ahora vamos a empezar. Bienvenido a Diseñar con Mentes de Programación. Es realmente un placer estar aquí en la edición remota de la React Summit. Así que, mi nombre es Elizabet Oliveira, es un nombre portugués. En realidad, nací en Mozambique y mi padre era portugués y mi madre es de Mozambique, así que soy una mezcla de Portugal y Mozambique, pero crecí en Portugal, en Lisboa. Hace dos años, viví en Dublín durante unos cuatro años. Fue una buena experiencia, pero no pude soportar vivir sin sol y decidí volver a Portugal. Y desde entonces, trabajo para un equipo distribuido en Elastic, soy una diseñadora de productos senior y realmente disfruto trabajar en un equipo distribuido y la mayoría de nosotros trabajamos de forma remota. Y lo que hago en Elastic, trabajo en un proyecto llamado Elastic UI. Es un sistema de design donde tenemos muchos componentes y la idea de este sistema de design nació para proporcionar componentes para otro proyecto llamado Kibana, pero con el tiempo, personas fuera de Elastic comenzaron a usar este sistema de design. Y todos los días, vemos cada vez más personas usando el sistema de design. Además, muchas personas contribuyen con código y es realmente increíble ser parte de este equipo y especialmente de este sistema de design, tenemos los datos en mente, así que tenemos muchos componentes que te ayudan mucho si vas a trabajar con visualización de data. Así que realmente deberías probarlo. Especialmente si tienes un producto con muchos data, realmente, tenemos cajas de selección, selectores de color, iconos, botones. Hay tantas cosas como tablas, rejillas de data, muchas cosas que puedes imaginar, puedes encontrar en este sistema de design.

Entonces esto es como Kibana, Kibana es la ventana, digamos, la ventana de Elastic Stack. Es donde puedes visualizar tus datos y crear visualizaciones de datos y hay diferentes aplicaciones dentro de Kibana. Hay mapas, visualizaciones. Hay muchas cosas allí.

Entonces mi trabajo, básicamente, trabajo la mayor parte del tiempo en el sistema de diseño, pero a veces trabajo en Kibana y hoy quiero hablar sobre por qué tener un diseñador que programa en tu equipo es algo bueno y la razón por la que quiero hablar de esto es porque ahora veo que hay muchos equipos donde tienes diseñadores y desarrolladores y solo colaboran con imágenes y creo que hoy en día es un poco triste cuando las personas solo trabajan con imágenes estáticas, como tener un Figma donde tienes un boceto y trabajas con comentarios o envías el enlace a tu Figma y dices, oh, esto es lo que debes implementar. Este es el estado, esto es lo que debes cambiar y luego el desarrollador implementa eso y luego el diseñador va allí y comienza a decir, oh, esto no está bien implementado y a veces como diseñador no puedes prever todos los escenarios y luego tienes que volver a tu Figma o boceto y luego tienes que arreglar eso. Diseñamos y luego tienes que explicar nuevamente al desarrollador lo que el desarrollador necesita cambiar. Así que creo que este tipo de conversación a veces es un poco difícil o esta forma de trabajar, a veces es difícil y debido a eso quiero convencerte de que es bueno tener a los diseñadores que programan en tu equipo y hoy en día, muchas empresas tienen sistemas de diseño y en realidad un sistema de diseño puede ayudarte mucho pero no es 100% perfecto.

Y ¿por qué no es 100% perfecto? Porque si ves un caso como un producto muy grande como Kibana, está bien tener componentes del sistema de diseño pero a veces aún no tienes el componente listo o tienes que pensar cuando construyes el componente cómo va a funcionar para múltiples aplicaciones dentro de Kibana. Y a veces tienes que crear algo que solo va a vivir dentro de Kibana y no va a formar parte del sistema de diseño. Entonces tienes que proporcionar diseños a los desarrolladores de lo que necesitan implementar y a veces la implementación no es tan fácil si piensas en la parte de diseño. Así que creo que tener a alguien que tenga las habilidades para ir allí y construir esa estructura dentro del producto puede ayudarte mucho. Y a veces, solo tener el sistema de diseño no funciona para este tipo de escenarios.

Entonces, ¿qué es esto de diseñar con código o con código en mente? Para mí es como diseñar con código. Quiero decir, todos los días en Elastic voy a GitHub y creo una serie de solicitudes de extracción con cosas como correcciones o arreglando partes de la documentación, mejorando cosas, agregando logotipos y a veces diseño con código y otras veces diseño con código en mente. Y ¿qué es esto de diseñar con código o con código en mente? Así que creo que funciona mejor si tienes un sistema de diseño. Entonces, necesitas tener que diseñar con código, realmente necesitas tener los componentes ya hechos. Entonces, simplemente te sumerges en un proyecto y arreglas las cosas con el sistema de diseño. Pero a veces tienes, como dije antes, escenarios complejos como el de Kibana donde no tienes todos los componentes en el sistema de diseño y a veces necesitas crear componentes que solo van a vivir dentro de ese proyecto y este componente no va a formar parte del sistema de diseño. Así que creo que para esos escenarios complejos, es bueno esbozar la idea primero. Y también, cuando diseñas con código, no necesitas diseños perfectos en píxeles, a veces solo necesitas, cuando comienzas a diseñar, decir, okay, estos son los colores que quiero usar, este es el diseño que quiero crear. No necesita ser perfecto en píxeles porque luego lo vas a hacer perfecto en píxeles, digamos, con código. Así que solo tienes la idea y luego lo arreglas con código y lo ajustas con código.

Entonces, las ventajas de diseñar con código. En primer lugar, los estados. Ya sabes, cuando trabajas con cosas como Figma o Sketch, es un poco difícil crear todos los estados. Okay, puedes tener símbolos y puedes tener componentes en Figma que cambian de estado. Así que digamos que un botón puede tener diferentes estados, un botón de advertencia, un botón de peligro, pero si lo creas con código, es más fácil porque solo necesitas diseñar una pequeña pieza, digamos el botón y definir, estos son los colores que quiero y luego con código haces el resto. Y creo que con un diseñador que programa en tu equipo, los equipos pueden trabajar más rápido porque no necesitas pedirle a alguien que construya eso y luego a veces ir allí y decir, esto no está bien implementado. Así que creo que tener a un diseñador que programa, los equipos pueden trabajar realmente rápido.

Este es un ejemplo de algo en lo que ayudé. Forma parte de los mapas de Elastic en Kibana, dentro del proyecto Kibana. Así que estaba ayudando a crear esta nueva parte de los mapas llamada estilo de capa. Tuve algunas reuniones, dije, okay, esto es lo que vamos a construir. Creé el diseño y también tenemos el sistema de diseño en Figma.

Entonces, dije, okay, esto es lo que necesitamos implementar y tuvimos algunas discusiones sobre lo que queríamos hacer. Y esto fue cuando el desarrollador implementó. Como diseñador, pude ver de inmediato muchos problemas, como que algunos de los campos no tenían espacio y también había problemas con el espacio entre ellos. Como puedes ver, este campo, este selector de color, no tiene el mismo tamaño que los otros campos. Él usó un tamaño diferente.

Y pude decirle al desarrollador, tal vez con esta captura de pantalla, poner mucho texto rojo encima y decir, oh, necesitas espacio aquí, y flechas que indiquen lo que tenía que arreglar. Luego tuve que ir allí y ver si lo arregló correctamente. Y imagina que al final somos muchas personas trabajando juntas. Entonces lo que hice fue sumergirme en el proyecto y arreglarlo yo mismo con código. Básicamente fui allí e implementé correctamente los componentes que tenemos del sistema de diseño porque él ya estaba usando los componentes del sistema de diseño pero no los estaba usando correctamente. Fui al proyecto y arreglé eso. Puse los campos con el mismo tamaño y el resultado final fue este. Quiero mostrarte cómo funciona. Así que fui al proyecto Kibana y creé una solicitud de extracción. Esta es en realidad la solicitud de extracción. Y me gusta explicar lo que estoy haciendo. Digo, okay, estos son los cambios de diseño. Introduje un espacio entre los dos elementos del formulario. Todos los elementos del formulario ahora están comprimidos. Todas las filas ahora tienen ancho completo. Se introdujo una corrección para los elementos de la izquierda cuando tenemos dos en una fila.

Así que expliqué lo que cambié y básicamente me gusta proporcionar las explicaciones a los desarrolladores. Probablemente en el futuro, sabrás cómo implementar correctamente nuestros componentes del sistema de design. Este es solo un ejemplo básico de cómo puedes trabajar cuando tienes un diseñador que puede programar. Esto es algo diferente, como en este caso el desarrollador implementó primero y luego fui allí y lo arreglé. Solo le di algunas indicaciones, tal vez algunas capturas de pantalla, probablemente no tan perfectas en píxeles, no di tal vez todos los escenarios posibles, y luego fui allí y lo arreglé.

Con este caso, era un nuevo componente que quería introducir en nuestro sistema de design. Y empecé a notar dentro de Kibana que hay muchos lugares donde necesitamos componentes de selector de color. Así que tuve esta idea porque ya estábamos usando diferentes selectores de color en diferentes partes de Kibana. Así que dije, okay, este es un patrón que tenemos que resolver. Decidí crear un nuevo componente e introducir este componente en nuestro sistema de design, Elastic UI. Para eso, creé el componente. Esta es una captura de pantalla de la aplicación Mapas. Y en realidad, esto no es perfecto en píxeles. Solo lo hice como una captura de pantalla. Y nuevamente, a partir de la captura de pantalla, simplemente puse encima esto y lo que tenía en mente, y lo compartí con el equipo de Mapas, lo compartí con mis colegas, dije, ¿qué opinan de estos nuevos componentes? Todos estuvimos de acuerdo. Dije, okay, esto es lo que quiero construir. Y cuando diseñé esto, como puedes ver, solo tengo algunas capturas de pantalla. Así que probablemente, si realmente quisiera dárselo al desarrollador, necesitaría mucho más que esto. Tendría que explicar todo, como, oh, cuando haces clic aquí, esto sucederá. Y tendría que explicar y tal vez dar muchos más detalles y muchas más capturas de pantalla explicando todos los diferentes escenarios. Entonces, como iba a codificar el design de esto y esto era solo una referencia para mí, simplemente diseñé esto. Y cómo iba a verse, no perfecto en píxeles dentro de una de las aplicaciones, y también lo probé en diferentes aplicaciones de Kibana. Y después de eso, decidí, okay, ahora voy a implementar esto con código. Y hemos usado TypeScript, y a partir de cuando estamos definiendo los tipos, en realidad genera nuestra documentation. Así que tenemos que explicarlo todo. Por ejemplo, oh, estas son las paletas, una paleta es como un array de objetos que puede recibir un valor, un título, y lo explico todo. Algunos de ellos, soy un poco perezoso, solo digo, déjalo así, y luego en el futuro, lo cambiaré. Y luego, esta es la parte más importante, en realidad es el design en sí, como los estilos y cómo se verá. Y luego, lo que hago es crear un borrador en nuestro Elastic UI. Así que con un borrador, genera automáticamente nuestra página de vista previa, y luego desde la página de vista previa, este es el estado actual del componente.

Entonces, y luego puedo tener mejores discusiones con los desarrolladores y otros equipos que probablemente vayan a utilizar estos componentes. Y puedo mostrarles, okay, esto es lo que tengo en mente, y podemos tener discusiones, y simplemente programo hasta el aspecto de diseño de eso, probablemente para este componente, puedo crear todo, pero probablemente después de eso, un desarrollador de mi equipo puede corregir mejor lo que no hice correctamente.

Así que creo que este tipo de trabajo puede resolver la brecha entre desarrolladores y diseñadores. Como puedes ver, es mucho mejor si el diseñador puede adentrarse en el código y resolver estos pequeños detalles para que no haya conversaciones interminables de, oh, arregla esto, arregla aquello, oh, olvidé esto, y luego tienes que volver atrás. Creo que es mejor si tienes a alguien que conoce el diseño y va allí y lo arregla o crea algo desde cero con diseño.

Y en diferentes empresas, este diseñador tiene diferentes nombres. En Elastic, es un diseñador de productos. Ahora hay desarrolladores de UX. Algunos desarrolladores de UI realmente tienen habilidades de diseño. Y puedes llamar a este tipo de persona como quieras. Pero no olvides que los equipos deben tener diferentes tipos de diseñadores. No solo contrates o intentes tener un solo tipo de diseñador. Veo muchas empresas que solo tienen diseñadores que crean imágenes estáticas y luego desarrolladores. Creo que deberías tener un equilibrio de diferentes tipos de diseñadores. Algunos que sean realmente buenos con CSS y que sepan programar un poco de JavaScript, React, TypeScript. Y luego puedes tener a alguien que sea más visual y también puedes tener incluso desarrolladores dentro del equipo. Y todos juntos harán que el desarrollo sea mucho más rápido. Y trabajarán mucho más adecuadamente juntos. Y no tendremos esta brecha entre diseñadores y desarrolladores y no más solo imágenes estáticas.

Así que creo que en el futuro tendremos estas nuevas herramientas de diseño. Como hoy en día, sé que hay algunas startups creando herramientas como models, interplay, figma, y creo que eso va a ser el futuro. Y espero que estas herramientas puedan generar código React con TypeScript o no. Y luego no estoy seguro de cómo va a suceder la parte de revisión de código cuando, cómo vas a poner eso en GitHub, pero creo que esas herramientas van a solucionar eso y pensar en eso.

Y espero que les haya gustado la charla. Si tienen preguntas, adelante y háganlas. Y solo quiero decir gracias. Intentemos contratar y tener diseñadores de código trabajando junto con desarrolladores. Mejoremos nuestros equipos y eso es todo. Así que mi nombre, una vez más, es Elisabeth y pueden encontrarme en Twitter. Este es mi sitio web y realmente quiero agradecerles a todos por ver esta charla.

Adelante, pueden hacer preguntas. Gracias.

De acuerdo. Bueno, muchas gracias, Elisabeth. Excelente charla. Desde mi propia experiencia personal, sé que es realmente difícil trabajar con diseñadores que no conocen código. Eso no quiere decir que sean malos diseñadores, pero sí, es mucho mejor si tienes a alguien que al menos tenga conocimientos básicos de lo que estás haciendo y pueda entender cómo pensar en componentes. Y sí, parece que realmente lo lograste. Así que gracias por esta información.

Vamos a pasar directamente a las preguntas. La primera pregunta, no es mía, la primera pregunta que recibimos del canal de Slack es de Rita Castro. ¿Cómo manejas esos casos en los que el sistema de diseño no tiene lo que tú o el diseñador quieren lograr, pero no se te permite cambiar el sistema de diseño?

Sí, esto sucede mucho en Kibana, especialmente porque cada vez que una aplicación diferente necesita algo nuevo. Y a veces, simplemente porque el equipo de Mapas necesita algo nuevo, no creamos un componente para nuestro sistema de diseño porque es solo para uno. Entonces, este componente vivirá dentro del equipo de Mapas o la aplicación de Mapas. Pero luego, si ves que ese componente, el patrón comienza a aparecer en diferentes aplicaciones de Kibana, comenzamos a pensar que probablemente necesitamos crear esto como un componente en el sistema de diseño. Pero a veces, solo creamos algo muy específico para una aplicación en Kibana, simplemente comenzamos a tener reuniones con el equipo, surgen ideas. Esto es lo que tengo en mente. Y luego, a veces, el propio equipo puede hacer el código o puedo ayudar con el código, o puedo crear algún tipo de, comenzamos tal vez con el prototipo. Puedo crear un prototipo funcional. Tal vez el código no esté listo o esté listo al 100% para comenzar a usarse dentro de Kibana. Pero al menos muestra, okay, esto es lo que queremos hacer. Y ya podemos comenzar a ver algunos problemas que el componente podría tener, y eso es todo.

Sí. Sí, es mucho más valioso si puedes tener al menos un prototipo interactivo y no necesita ser código listo para producción, pero es fácil transmitir tus ideas al equipo de desarrollo de código de producción si eres capaz de hacer esto un poco con un poco de código. Así que eso es realmente valioso.

Oh, y una pregunta de seguimiento, también de Rita. ¿Cómo comenzaste a programar como diseñadora? Bueno, como soy de Portugal, allí terminamos haciendo de todo. Hace años, mi rol era de diseñadora web o desarrolladora web, diseñadora web, y en ese momento, un diseñador web era alguien que hacía de todo. Entonces, mi primer rol fue principalmente hacer equipos de WordPress.

Así que comencé comprando equipos y cambiando el CSS, y luego un día tuve que construir un equipo más complejo, así que empecé a construir mis propios equipos desde cero. Tuve que aprender un poco de PHP, y luego desarrolladores de WordPress y diseñadores web y simplemente comencé a moverme hacia roles de front-end.

Terminé- Te ves un poco forzado a hacerlo. Sí, terminé siendo un diseñador y haciendo cosas como UI o más bien CSS. Y un día empecé a hacer cosas con jQuery. Y después de jQuery, empecé, bueno, ahora sé jQuery, la gente dice que jQuery no es bueno. Y dije, oh, tal vez deba empezar a aprender mejor JavaScript. Y luego, a partir de JavaScript, un día terminé en una startup y queríamos crear algo. Y escuché que la gente estaba usando React o Angular. Así que dije, bueno, déjame intentarlo. También probé Angular. Y era tan complejo. Así que dije, oh, déjame intentar React. Y para mí, como diseñador, sentí que era más intuitivo. Y simplemente empecé a usarlo. Y nunca lo dejé.

Sí. Correcto. La siguiente pregunta. ¿Tienes algún consejo sobre cómo facilitar la incorporación de los diseñadores a la programación? Al menos en Elastic, creo que una de las cosas que utilizamos es GitHub para casi todo. Comunicamos dentro de GitHub. Todo es casi de código abierto, por lo que cualquiera puede ver lo que estamos haciendo. Incluso el diseño, cuando intentamos arreglar algo, simplemente coloco el enlace de Figma o pongo la captura de pantalla. Y a veces realmente quieres ayudar. Comienzas a ver el valor de GitHub. Y como diseñador, quieres crear tus solicitudes de extracción y ser un colaborador. Veo a muchos diseñadores en Elastic que realmente quieren ser colaboradores, y comienzan con cosas pequeñas como arreglar un icono o cambiar una línea de CSS. Entonces, tal vez para aquellos que quieran que los diseñadores programen, si comienzan a usar GitHub, probablemente comenzarán a hablar en GitHub y el diseñador puede solucionar una línea de código allí.

Sí, es porque ven lo que está sucediendo en el código porque tienen que comunicarse con los desarrolladores en código o en el entorno de código, GitHub en tu caso, entonces ven lo que está sucediendo y es posible que estén más inclinados a decir, `oye, esto parece que puedo hacerlo`. Sí, incluso hoy en día en GitHub, tienes las sugerencias. Entonces, cuando estás revisando el código, simplemente puedes imaginar que alguien está usando un Xcode en lugar de una variable de color. Y dices, `oye, puedes usar este Xcode, esto, deberías usar esta variable primaria que es la correcta`. Entonces, tal vez puedas sugerir eso en GitHub o puedes comenzar, ok, déjame descargar esto en mi computadora y tratar de cambiarlo en VS Code y luego hacer una solicitud de extracción. Sí, eso es realmente poderoso. Tenemos tiempo para una pregunta más y luego pasaremos al siguiente ponente.

¿Utilizas alguna herramienta para extraer los componentes de tu sistema de diseño directamente en componentes de React? ¿Puedes recomendar alguna? ¿Disculpa? ¿Puedes repetir la pregunta? Sí. ¿Utilizas alguna herramienta para extraer los componentes de tu sistema de diseño directamente en componentes de React? En realidad, ya tenemos nuestro sistema de diseño implementado en React. Y en realidad es muy interesante porque la mayoría de los equipos de diseño tienen una versión más avanzada en Figma o Sketch, pero Elastic es diferente. Ya tenemos todos los componentes en línea en React. Y a veces no tenemos todos los componentes en el diseño en Figma o Sketch. Porque terminamos haciendo muchas cosas con código. Y todo está en vivo. Entonces, a veces algo ya está fusionado y no teníamos un Sketch o Figma. Eso es genial. Eso me dice que muchas personas, como tú, son una especie de híbrido entre diseño y desarrollo en Elastic.

Sí. Incluso como una cosa que mostré en la parte superior, ese selector de paleta de colores. Como has visto, no tenía el design final. Así que hice la solicitud de extracción con mi versión final, digamos, y luego tengo que ir a Figma e incluir el design del selector de paleta de colores. Pero estoy tratando de terminar primero el código, y una vez que se haya fusionado, puedo ponerlo en Figma. Así que estará primero en vivo.

Muy bien. Eso, nunca había oído hablar de hacerlo de esa manera, pero suena como una buena forma de hacerlo. Bueno. Documentado cómo quieres que funcione.

Muy bien, Elizabeth, te voy a pedir que vayas a tu sala de Zoom. Así que hay algunas preguntas más. Así que la gente las hará en tu sala de Zoom. Así que gracias por unirte a nosotros. De acuerdo, gracias. ♪♪