Como Líder de Diseño de Producto en uPlanner, encabecé la implementación de un marco de DesignOps que implicó la creación de una «constitución» colaborativa para estandarizar los procesos de diseño en mi equipo de cuatro diseñadores, quienes estaban integrados en equipos de producto. Este enfoque me ayudó a abordar las ineficiencias y las inconsistencias en nuestro flujo de trabajo de diseño, mejorando la coherencia, la eficiencia y la escalabilidad, al tiempo que facilitó la incorporación de nuevos diseñadores. Aunque enfrenté desafíos como equilibrar la colaboración con la eficiencia y mantener actualizada la constitución, el impacto general ha sido transformador, fomentando un equipo fuerte y cohesionado dedicado a ofrecer productos educativos de alta calidad.

La necesidad de DesignOps

Con la creciente complejidad de nuestros productos digitales y las diversas necesidades de nuestra base de usuarios, se hizo evidente que nuestros procesos de diseño existentes no eran escalables. Los diseñadores se encontraban a menudo reinventando la rueda, lo que provocaba incoherencias en la experiencia del usuario e ineficiencias en nuestro flujo de trabajo. Además, la falta de procesos y documentación estandarizados dificultaba la incorporación de nuevos miembros al equipo. Estaba claro que necesitábamos un sistema cohesivo para agilizar nuestras operaciones de diseño y garantizar la coherencia en todos los productos.

La Constitución: Un enfoque colaborativo

Inspirados por un artículo de Nielsen Norman Group sobre DesignOps, decidimos crear una «constitución» para nuestro equipo de diseño. Esta constitución serviría como un documento vivo, esbozando nuestros procesos DesignOps, principios y mejores prácticas. Sin embargo, en lugar de dictar las normas desde arriba, opté por un enfoque colaborativo en el que todos los miembros del equipo pudieran contribuir a la constitución.

El proceso fue sencillo pero eficaz:

• Identificación de problemas: Cada vez que un diseñador encuentra un problema o una ineficacia en su flujo de trabajo, lo pone en conocimiento de todo el equipo durante nuestros talleres de diseño semanales.
• Debate y solución: A continuación, el equipo entabla un debate colaborativo para explorar posibles soluciones. Este diálogo abierto nos permite considerar diferentes perspectivas y llegar a un consenso sobre la mejor forma de actuar.
• Creación de una nueva «ley»: Una vez acordada una solución, el diseñador que identificó el problema redacta una nueva entrada en la constitución de DesignOps. Esta entrada detalla el problema, la solución y cualquier directriz o proceso relevante.
• Revisión y edición por pares: El borrador se comparte con todo el equipo para su revisión. Se anima a todo el mundo a que aporte comentarios y sugiera modificaciones, para garantizar que el documento final refleje la sabiduría colectiva del grupo.
• Finalización y adopción: Tras incorporar todos los comentarios, la nueva entrada se añade oficialmente a los estatutos. A continuación, el equipo adopta la nueva práctica en sus flujos de trabajo diarios.

Beneficios de la constitución colaborativa

La implantación de nuestra constitución DesignOps ha aportado varios beneficios clave a nuestro equipo de diseño:

• Coherencia entre productos: Al documentar nuestros procesos y normas de diseño, hemos logrado un mayor nivel de coherencia en todos nuestros productos. Esto no sólo ha mejorado la experiencia del usuario, sino que también ha reforzado nuestra identidad de marca.
• Mayor eficacia: Los procesos estandarizados han reducido el tiempo dedicado a tareas repetitivas y han permitido a los diseñadores centrarse más en la resolución creativa de problemas. Esto ha dado lugar a iteraciones de diseño más rápidas y a un flujo de trabajo más eficiente en general.
• Mejora de la moral y la implicación del equipo: La naturaleza colaborativa de la constitución ha fomentado un fuerte sentido de propiedad e inclusión entre todos los miembros del equipo. Los diseñadores se sienten capacitados para contribuir a la evolución de nuestros procesos, sabiendo que sus ideas son valoradas y respetadas.
• Escalabilidad e incorporación: Los procesos documentados han facilitado la incorporación de nuevos diseñadores, ya que pueden familiarizarse rápidamente con nuestras prácticas establecidas. Esta escalabilidad ha sido crucial a medida que nuestro equipo sigue creciendo.

Retos y lecciones aprendidas

Aunque la implantación de DesignOps ha sido en gran medida un éxito, nos hemos encontrado con algunos retos en el camino:

• Equilibrio entre colaboración y eficacia: Implicar a todo el equipo en la creación y revisión de cada nueva entrada puede llevar mucho tiempo. Tuvimos que encontrar un equilibrio entre la colaboración exhaustiva y el mantenimiento de un flujo de trabajo eficiente.
• Mantener actualizada la Constitución: A medida que evolucionan nuestros productos y procesos, es esencial mantener actualizada la constitución. Establecimos un proceso de revisión trimestral para garantizar que nuestra documentación sigue siendo relevante y refleja nuestras prácticas actuales.

Conclusión

La introducción de un marco DesignOps a través de nuestra constitución desarrollada en colaboración ha sido una experiencia transformadora para nuestro equipo de diseño. Al fomentar una cultura de participación e inclusión, no sólo hemos mejorado nuestros procesos de diseño, sino que también hemos reforzado la cohesión y el sentido de propósito de nuestro equipo. A medida que seguimos creciendo e innovando, nuestra constitución DesignOps seguirá siendo una piedra angular de nuestro éxito, guiándonos en la entrega de productos educativos excepcionales a nuestros usuarios.

Como Líder de Diseño de Producto en uPlanner, encabecé los esfuerzos de nuestro equipo en una evolución crucial en nuestro proceso de diseño de interfaces. Pasamos de usar estilos en línea, que generaban inconsistencia, redundancia y una reutilización limitada, a implementar hojas de estilo centralizadas para lograr mayor eficiencia y uniformidad. Inicialmente, migramos a archivos LESS centralizados durante nuestra fase con Angular, integrándolos con el framework Bootstrap para establecer un lenguaje de diseño consistente, mejorar la mantenibilidad y aumentar la modularidad. Posteriormente, al cambiar a Vue.js, avanzamos a SASS, aprovechando sus funciones más avanzadas para mejorar la reutilización, escalabilidad y eficiencia, al mismo tiempo que actualizábamos nuestra integración con Bootstrap. Esta transición a estilos centralizados ha mejorado significativamente nuestra capacidad para mantener, escalar y colaborar en el diseño de interfaces en todos nuestros productos digitales en uPlanner.

Desafío

Inicialmente, nuestro enfoque de diseño de interfaz de usuario implicaba el uso de estilos en línea directamente dentro del HTML de nuestras vistas:

• Incoherencia: Los distintos desarrolladores aplicaban estilos diferentes, lo que daba lugar a un aspecto incoherente en toda la aplicación.
• Redundancia: El uso repetido de estilos similares en varios elementos daba lugar a una base de código hinchada.
• Reutilización limitada: Los estilos en línea no se podían reutilizar en varios componentes, por lo que el mantenimiento y las actualizaciones requerían mucho trabajo.

Objetivo

Nuestro objetivo era crear un sistema de estilos más eficaz y coherente centralizando nuestros estilos. Esto implicaría la transición de estilos en línea a hojas de estilo centralizadas para lograr lo siguiente:

• Garantizar un lenguaje de diseño coherente en todas las vistas y componentes.
• Minimizar la redundancia definiendo estilos reutilizables en una ubicación central.
• Mejorar la escalabilidad y la capacidad de mantenimiento mediante una gestión de estilos organizada y modular.

Proceso

1. Implementación inicial: Estilos en línea

En la primera fase de desarrollo, nos basamos en estilos en línea incrustados en elementos HTML. Este enfoque era sencillo, pero pronto reveló sus limitaciones:

• Difícil de mantener: A medida que la aplicación crecía, el mantenimiento de los estilos en línea se hacía cada vez más difícil. Actualizar un solo elemento de diseño requería encontrar y cambiar estilos en varias ubicaciones.
• Falta de coherencia: Los distintos desarrolladores aplicaban a menudo estilos en línea diferentes, lo que daba lugar a una interfaz de usuario fragmentada e incoherente.
• Falta de reutilización: Los estilos inline estaban vinculados a elementos específicos, lo que hacía imposible reutilizarlos en distintas partes de la aplicación.

2. Transición a hojas de estilo centralizadas con LESS

Reconociendo las limitaciones de los estilos en línea, hicimos la transición a un enfoque más estructurado mediante la adopción de LESS, un preprocesador de CSS, durante nuestro desarrollo con Angular. Los cambios clave incluyen:

• Archivos LESS centralizados: Creamos hojas de estilo centralizadas utilizando LESS, que albergaba todos los estilos para la aplicación en una estructura única y organizada. Esto nos permitió definir variables, mixins y estilos reutilizables que podían aplicarse a diferentes componentes.
• Integración de Bootstrap Framework: Basamos nuestra arquitectura de hojas de estilo en el framework Bootstrap, personalizándolo para alinearlo con nuestros requisitos de diseño específicos. Esta integración nos permitió aprovechar el sistema de cuadrícula adaptable de Bootstrap y los estilos predefinidos, manteniendo al mismo tiempo nuestra propia marca.
• Diseño coherente: Al centralizar los estilos en LESS, garantizamos un lenguaje de diseño coherente en toda la aplicación. Todos los desarrolladores utilizaron el mismo conjunto de estilos, lo que redujo las incoherencias.
• Mantenimiento mejorado: Los archivos LESS centralizados facilitaron la actualización de los estilos. Los cambios realizados en un único valor de los archivos LESS se propagaban automáticamente por toda la aplicación, lo que reducía el tiempo y el esfuerzo necesarios para las actualizaciones.
• Modularidad: LESS nos permitió dividir los estilos en archivos modulares, cada uno de los cuales representaba diferentes aspectos de la interfaz de usuario (por ejemplo, tipografía, esquemas de color, diseños). Esta modularidad mejoró tanto la organización como la escalabilidad de nuestros estilos.

3. Avance a SASS con Vue.js

Al pasar de Angular a Vue.js, vimos la oportunidad de mejorar aún más nuestro enfoque de estilo adoptando SASS, un preprocesador de CSS más potente:

• Arquitectura basada en SASS: Estructuramos nuestras hojas de estilo basándonos en SASS, aprovechando al máximo sus características como reglas anidadas, herencia y funciones más avanzadas. Esto nos proporcionó un mayor control y flexibilidad sobre nuestro estilo.
• Actualización del marco Bootstrap: Mantuvimos la arquitectura de nuestra hoja de estilo en el framework Bootstrap, actualizándola a la siguiente versión y personalizándola mediante variables y funciones SASS para alinearla con nuestros requisitos de diseño específicos.
• Modularidad y reutilización mejoradas: Las funciones avanzadas de SASS nos permitieron crear estilos altamente reutilizables y modulares. Por ejemplo, definimos variables globales para colores, fuentes y espaciado, garantizando la coherencia y facilitando la actualización del diseño en toda la aplicación.
• Eficacia y escalabilidad: La combinación de archivos SASS centralizados y las capacidades de personalización de la nueva versión de Bootstrap nos permitieron escalar nuestro sistema de diseño de forma eficiente. Podíamos añadir fácilmente nuevos estilos o modificar los existentes sin alterar la coherencia general del diseño.

Resultados

En general, la transición de estilos específicos para cada vista a hojas de estilo centralizadas ha aportado varias ventajas significativas:

• Coherencia: Los estilos centralizados garantizaron un diseño uniforme en todos los componentes, reduciendo la probabilidad de incoherencias en el diseño.
• Reducción de la redundancia: Con un enfoque centralizado, los estilos comunes se definían una vez y se reutilizaban en varios componentes, lo que reducía la duplicación y mantenía limpia la base de código.
• Facilidad de mantenimiento: Actualizar los estilos se convirtió en algo sencillo, ya que los cambios realizados en las hojas de estilo centralizadas se aplicaban automáticamente a toda la aplicación. Extraer la capa de estilo de cada vista también significa que los desarrolladores ya no tienen que preocuparse de dar estilo al html, ahora todas las mejoras visuales de la interfaz de usuario se aplican automáticamente.
• Colaboración mejorada: Las hojas de estilo centralizadas proporcionaban una única fuente de verdad para todos los estilos, lo que facilitaba la colaboración de los diseñadores y garantizaba que todos siguieran las mismas directrices de diseño.
• Escalabilidad: A medida que la aplicación crecía, las hojas de estilo centralizadas nos permitían escalar el sistema de diseño de forma eficiente, añadiendo nuevos componentes o actualizando estilos sin alterar la coherencia general.

Conclusión

Nuestra evolución de los estilos en línea a las hojas de estilo centralizadas, primero con LESS y luego con SASS, ha mejorado significativamente nuestro proceso de diseño de la interfaz de usuario. Los estilos centralizados nos han proporcionado un sistema escalable, eficiente y fácil de mantener que garantiza la coherencia en todos nuestros productos digitales.

Como Líder de Diseño de Producto en uPlanner, nuestro equipo inicialmente enfrentó desafíos con las cadenas de texto codificadas en español, incluyendo una localización limitada, ineficiencia en las actualizaciones y duplicación de contenido en diferentes versiones para cada cliente. Para abordar estos problemas, desarrollamos un marco de trabajo para la capa de idiomas escalable, comenzando con un sistema basado en Excel que gestionaba las traducciones pero que llevaba a errores manuales y redundancia. Luego, pasamos a utilizar archivos JSON centralizados para cada idioma, gestionando las cadenas de texto mediante claves para reducir la duplicación y agilizar las actualizaciones. Finalmente, integramos Crowdin para la gestión de traducciones y automatizamos el proceso de exportación a Bitbucket, lo que permitió una localización específica para cada cliente sin comprometer la eficiencia o la consistencia. Este nuevo marco ha mejorado significativamente la escalabilidad, eficiencia y personalización en nuestro proceso de localización.

Desafío

El enfoque inicial de incluir contenido de texto en español directo en la interfaz de usuario presentaba varios retos:

• Localización limitada: Nuestros productos estaban bloqueados en un único idioma (español), por lo que era imposible atender a los usuarios que no hablaban español sin un importante rediseño.
• Ineficacia: Cada vez que había que actualizar un texto, los desarrolladores tenían que localizar y modificar manualmente cada instancia de ese texto en el código.
• Duplicación de contenidos: Como intentábamos dar soporte a varios clientes, cada uno con ligeras variaciones en sus requisitos lingüísticos, nuestra solución improvisada provocaba la duplicación de contenidos en las distintas versiones de nuestra interfaz de usuario.

Objetivo

Nuestro objetivo era desarrollar un marco de capa de lenguaje escalable que nos permitiera:

• Dar soporte a múltiples idiomas, con especial atención al español y al inglés.
• Agilizar el proceso de localización para reducir la duplicación y la intervención manual en el código fuente.
• Implementar un sistema centralizado para gestionar las traducciones, minimizar los errores y mejorar la coherencia.

Proceso

1. Implementación inicial: Sistema basado en Excel

Nuestro primer paso hacia un enfoque más estructurado fue crear un sistema basado en Excel para gestionar las traducciones. Este sistema constaba de los siguientes pasos:

• Gestión de clientes por columnas: Cada columna del archivo Excel representaba a un cliente diferente, con filas que contenían textos para diversos elementos de la interfaz de usuario. Esto nos permitió personalizar el contenido para cada cliente y mantener todas las traducciones en un solo lugar.
• Exportación a JSON: Tras actualizar el archivo Excel, exportamos los datos a formato JSON para utilizarlos en nuestras aplicaciones. Sin embargo, este proceso requería trabajo manual para garantizar que el archivo JSON de cada cliente se generaba y cargaba correctamente, lo que provocaba contenido duplicado en varios archivos y un mayor riesgo de errores.

2. Cambio a archivos JSON por idioma

En este nuevo sistema se centralizaron todas los textos en un único archivo JSON para cada idioma (español e inglés). Las características clave de este enfoque incluían:

• Archivos de idioma: Creamos archivos JSON dedicados para cada idioma soportado, albergando todas los textos de interfaz de usuario. Esto eliminó la necesidad de duplicar el contenido para cada cliente.
• Keys: Los textos se gestionaron mediante Keys (variables) dentro de los archivos JSON. Estas Keys se insertan en el código que luego renderiza el texto correspondiente. Esto nos permitió reciclar textos en distintos componentes y clientes. Este enfoque no sólo redujo la redundancia, sino que también garantizó que cualquier actualización de un texto se reflejara automáticamente dondequiera que se utilizara la Key.

3. Localización avanzada con Crowdin e integración con Bitbucket

Reconociendo las ineficiencias del enfoque basado en Excel, hicimos la transición para optimizar aún más nuestro proceso de localización. Después de sopesar muchas opciones, adoptamos Crowdin, un sistema de gestión de la traducción que se integra a la perfección con nuestro flujo de trabajo existente. Los pasos clave fueron los siguientes:

• Integración de Crowdin: Crowdin se convirtió en nuestra plataforma central de gestión de traducciones. Las nuevas Keys y las contenidos correspondientes se crean directamente en Crowdin, donde pueden traducirse fácilmente a varios idiomas.
• Exportación JSON automatizada: Una vez finalizadas las traducciones en Crowdin, se envían automáticamente como archivos JSON a nuestro repositorio Bitbucket. Esto eliminó la necesidad de exportar manualmente y redujo significativamente el riesgo de errores.
• Localización específica del cliente: Para gestionar los requisitos específicos de cada cliente, implementamos un sistema en el que cada cliente tiene su propio archivo JSON que contiene únicamente las Keys personalizadas y los contenidos correspondientes que deben modificarse. Los archivos JSON del idioma base permanecen intactos y sólo se aplican las diferencias por cliente, lo que garantiza la coherencia y permite la personalización.

Resultados

La implementación del marco de la capa de lenguaje dio lugar a mejoras significativas:

• Escalabilidad: Ahora podemos añadir fácilmente compatibilidad con nuevos idiomas y localizar contenidos para distintas regiones o clientes sin necesidad de realizar grandes modificaciones en nuestro código fuente.
• Eficacia: El uso de Keys y archivos JSON centralizados ha reducido drásticamente la duplicación de contenidos, haciendo que nuestro proceso de traducción sea más rápido y menos propenso a errores.
• Flujo de trabajo optimizado: La integración de Crowdin y Bitbucket ha automatizado gran parte del proceso de traducción, permitiendo a nuestro equipo centrarse en tareas más estratégicas en lugar de en actualizaciones manuales.
• Localización personalizable: La capacidad de manejar la localización específica del cliente a través de archivos JSON personalizados garantiza que podamos satisfacer las necesidades únicas de cada cliente sin sacrificar la eficiencia o la coherencia.

Conclusión

Nuestro paso de contenido fijo a un sofisticado marco de capa de lenguaje ha sido transformador. Al centralizar nuestra gestión de idiomas en archivos JSON, adoptar Crowdin para la gestión de traducciones, e implementar la localización específica del cliente mediante archivos JSON personalizados, hemos creado un sistema escalable, eficiente y flexible que satisface las diversas necesidades lingüísticas de nuestra creciente base de usuarios.

Isologo creado para una pequeña fuente de soda local. La idea es comunicar un ambiente cálido con comidas caseras preparadas con mucho afecto. Se crearon algunas piezas adicionales de señalética como listas de precios, baño, salida, etc.

Isologo para una emprendedora dedicada a la masoterapia. Acompañado de algunas piezas gráficas como tarjeta de presentación y certificado de regalo.

Mi hermana vende joyas como actividad complemetaria, así que le diseñé un logo que acompañara sus productos. Con cada venta, ella incluye una pequeña pluma a modo de etiqueta, por lo que quise incluir ese elemento en la imagen de marca.

Fui contactado para desarrollar la interfaz gráfica de un software para configurar proyecciones sobre superficies complejas. La empresa que monta estos espectáculos creó un software propio y para comercializarlo debían empaquetar la experiencia de usuario.

Fue un proceso largo de entrevistas y análisis de lo que la herramienta debía hacer y cómo sería la mejor forma de presentar todo el potencial.

Se estudió cada acción, cada botón, se hicieron casos de uso, wireframes, y maquetas. Finalmente, se entregaron los elementos por separado, con instrucciones para que el equipo de informática pudiera usar todo.

La Federación Chilena de Handball necesitaba un refresco de imagen así que imaginé esta solución. Desfortunadamente, el proyecto nunca vió la luz. Es probable que el trabajo se use en otro proyecto pronto, así que cuando salga de horno actualizaré esta entrada.

Unos amigos montaron una agencia digital y me pidieron ayuda para crear un logotipo que reflejara su actividad. El nombre sería W3 en alusión a las tres WWW. La solución final es un juego de contraste donde el espacio negativo de la W y el 3 generan un cursor.

El Mercurio necesitó implementar una webapp interna que permitiera a ciertos usuarios revisar y aprobar diferentes tipos de transacciones.

Me solicitaron diseñar y construir una UI responsive siguiendo pautas internas conocidas por los usarios.

El resultado fue exitosamente implementado en corto plazo sin contratiempos.

Útiles:

• Diseño
• HTML
• CSS
• JQuery
• Bootstrap
• Fontawesome