Decodificación del diseño: cómo el diseño y la ingeniería pueden prosperar juntos en el código abierto

El código abierto prospera en procesos impulsados ​​por la ingeniería. Bucles de retroalimentación rápidos, herramientas de terminal, flujos de trabajo de Git: son el elemento vital de cómo construimos software públicamente. Pero para que el software realmente destaque, necesitamos crear experiencias de usuario que permitan a las personas utilizarlas.

Quiero mantener esta conversación en el centro de atención. El diseño abierto de Canonical iniciativa. ¿Qué mejor manera que en FOSS entre bastidores 2026 Berlín?

Para ayudar a centrar la conversación, reuní un panel de algunos de los diseñadores e ingenieros más talentosos en código abierto: Gloria LongoriaDirector senior de diseño de GitHub, eliot zorromantenedor principal del diseño de código abierto y diseñador (asistente del hogar) de Open Family Foundation, y David AdlerGerente de Ingeniería de Canonical.

Esto es lo que obtuve de «Navegue por un entorno centrado en la ingeniería.»

Uno de los mayores conceptos erróneos que enfrentamos es que los diseñadores y desarrolladores necesitan flujos de trabajo separados y aislados. Glòria inmediatamente cuestionó esto: en GitHub, los equipos trabajan en un modelo EPD (Ingeniería, Producto y Diseño) y trabajan al unísono. En última instancia, a los usuarios no les importa cómo está organizado su equipo interno, solo les importa el producto final.

Una forma de combinar estos flujos de trabajo es integrar el diseño directamente en el ciclo de ingeniería que ya utiliza. Eriol compartió una historia sobre la introducción del «control de calidad del diseño» junto con el control de calidad de ingeniería estándar, lo que convirtió el proceso de control de calidad en un espacio colaborativo de discusión entre ambas partes para comprender las perspectivas de cada uno y los puntos estándar para aprobación. David estuvo de acuerdo y brindó la perspectiva de un gerente de ingeniería. Él cree que antes de incorporar cualquier RP, realizar el control de calidad del diseño es un paso necesario: los diseñadores deben revisar los cambios propuestos para garantizar que los resultados de ingeniería realmente coincidan con su intención de diseño original.

El diseño no es una capa final de «toques» que se añaden después. Si la experiencia no funciona, es necesario solucionarla de inmediato, al igual que una mala codificación.

Puntos clave:

• Para diseñadores: no preestablezca marcos de diseño ni ciclos de vida estrictos. Tómese el tiempo para comprender el contexto específico del equipo de ingeniería con el que está trabajando.
• Para ingenieros: invite a los diseñadores a su proceso desde el principio. Elior señala que los ingenieros a menudo «simplemente esperan una invitación» para participar en un diseño, y viceversa.

Los choques culturales a menudo ocurren cuando no entendemos las limitaciones que enfrenta la otra parte.

Por ejemplo, Glòria compartió cómo los diseñadores pueden frustrarse cuando el modelo de datos backend bloquea filtros de interfaz de usuario aparentemente simples, lo que lleva a la suposición injusta de que los desarrolladores son «vagos». ¿reparar? Los diseñadores deberían ampliar nuestras habilidades para comprender cómo funcionan realmente la arquitectura y los modelos de datos.

Del mismo modo, los ingenieros siempre encontrarán casos extremos en los diseños. Los diseñadores e ingenieros necesitan una cultura de crítica compartida donde la retroalimentación se brinde sin miedo y a la vista. La comunicación es crucial.

Pero, ¿cómo se comunican eficazmente los equipos en la comunidad de código abierto? El trabajo asincrónico es la norma y las reuniones cara a cara pueden ser raras. Eliol ofrece un enfoque novedoso a este debate.

Esto significa tratar los archivos de diseño como archivos. Al agregar control de versiones, fechas y registros de decisiones directamente a los documentos de diseño, los diseñadores pueden utilizar un lenguaje que los desarrolladores respeten. Compartir espacios de trabajo y normas de esta manera ayuda a eliminar la fricción y permite a los equipos comprender de manera más efectiva qué decisiones se toman, cómo se toman y por qué se toman.

Puntos clave:

• Para diseñadores: a medida que se acerca al código y a los prototipos con componentes reales, la brecha de traducción entre diseño e ingeniería se reduce. Mantenga los primeros conceptos en baja fidelidad para invitar a la colaboración, en lugar de presentar un modelo «terminado» de alta fidelidad en el que los ingenieros sienten que no pueden contribuir.
• Para ingenieros: comprenda la intención detrás del diseño. Cuando comprende por qué un diseñador utilizó intencionalmente un espacio en blanco o una jerarquía de información específica, crea un conjunto de herramientas mental que se puede aplicar a funciones futuras.

¿Cómo demostramos el impacto en un entorno donde el diseño puede considerarse secundario a su función de transporte? La respuesta es simple: muestre su producto a personas reales que lo utilicen.

David dice que es muy motivador para los ingenieros participar en sesiones de prueba de usuarios con investigadores o diseñadores. Ver a alguien usando una herramienta o producto instantáneamente te hace querer hacerlo bien, un sentimiento respaldado por la experiencia personal de cada panelista.

Glòria compartió cómo ver a un usuario con discapacidad visual navegar por el proceso de registro impulsó al equipo de ingeniería a priorizar las correcciones de accesibilidad a la mañana siguiente.

Elior contó una historia sobre un ingeniero que participó en una prueba de campo en Kenia para probar una aplicación con una conexión deficiente. ¿resultado? El ingeniero se quedó despierto toda la noche, escribiendo con entusiasmo problemas de historias de usuarios desde una perspectiva nueva (y esperando que ellos también durmieran).

Más allá de las pruebas de usuario, Glòria señala que el trabajo de UX, al igual que la estandarización de patrones y la construcción de sistemas de diseño, tiene que ver fundamentalmente con el pensamiento sistémico. Cuando los desarrolladores se dan cuenta de que los componentes estandarizados de la interfaz de usuario significan que pueden eliminar el código heredado, escalar más rápido y reducir la deuda técnica, obtener soporte de ingeniería se vuelve más fácil.

Puntos clave:

• A los diseñadores: no se limiten a decirles a los ingenieros qué hacer. Muéstreles los puntos débiles de los usuarios y escriba historias de usuarios para establecer sus especificaciones.
• Para los ingenieros: el diseño no se trata sólo de embellecer las cosas; se trata de mejorar las cosas. Resuelve problemas complejos de visibilidad, accesibilidad y coherencia.

Crear un excelente software de código abierto requiere una gran ingeniería y un diseño bien pensado. El camino a seguir se basa en la curiosidad y la colaboración mutuas.

Los ingenieros que lean este artículo no teman buscar opiniones sobre el diseño, hacer preguntas sobre las necesidades de los usuarios y asistir a reuniones centradas en el diseño. Para los diseñadores, no se dejen intimidar por los obstáculos técnicos. Introduzca los puentes colgantes en su disciplina, entre en espacios de ingeniería, vea cómo funcionan y haga una contribución real.

Como lo resume Eliol: «El código abierto no se trata sólo del software, sino también de la comunidad».

Cuando respetamos los flujos de trabajo de cada uno y construimos juntos desde el principio, podemos crear software que realmente ayude a las personas que lo utilizan.

Vea el panel de discusión completo YouTube!

Únase al equipo de diseño de Canonical

Buscamos diseñadores que se preocupen por la artesanía y por cómo funcionan los sistemas entre bastidores. En Canonical, el diseño se encuentra en la intersección de la experiencia del usuario, la ingeniería y el código abierto, donde creamos experiencias coherentes y accesibles en la nube, el escritorio y los productos de IoT.

Si le gusta resolver problemas complejos y dejar clara la profundidad técnica, explore nuestras vacantes: canonical.com/careers