De Figma a Producción: Sistemas de Diseño para Qatar en 2026

El impulso de la transformación digital de Qatar — desde la agenda de la Qatar National Vision 2030 hasta la oleada de lanzamientos fintech en Lusail y las ambiciones de ciudad inteligente de Msheireb Downtown Doha — ha producido una explosión de archivos Figma. Los bancos están rediseñando sus apps de banca móvil para cumplir con el open banking, los operadores de telecomunicaciones están reconstruyendo sus portales de autoservicio, y las entidades gubernamentales están unificando los servicios ciudadanos bajo iniciativas como Hukoomi. Sin embargo, proyecto tras proyecto, vemos el mismo patrón de fracaso: una librería de Figma bellamente organizada que nunca sobrevive al contacto con producción. Los desarrolladores reconstruyen componentes desde cero. Las versiones en árabe y en inglés se van distanciando. Seis meses después, tres equipos tienen tres 'botones primarios' ligeramente distintos. Este artículo es el manual que usamos en FOCUS POINT para cerrar esa brecha — tokens, gobernanza y adopción, en ese orden.

El Problema Real: Tu Archivo de Figma No Es Tu Sistema de Diseño

Un sistema de diseño no es un conjunto de componentes bonitos en una librería compartida — es un producto con hoja de ruta, un responsable, notas de versión y un ciclo de retroalimentación. Cuando los equipos en Doha tratan Figma como la línea de meta, aparecen casi de inmediato tres síntomas: componentes duplicados con inconsistencias sutiles (espaciados con 2px de diferencia, cuatro tonos distintos del mismo 'azul de marca'), una brecha creciente entre lo que los diseñadores entregan y lo que los desarrolladores realmente construyen porque no existe un mecanismo de traspaso fiable, y — específico del mercado qatarí — una tipografía árabe que nunca se tokenizó correctamente, obligando a los desarrolladores a codificar manualmente tamaños de fuente y alturas de línea para los layouts RTL en cada proyecto. La solución empieza más arriba, con los tokens.

Design Tokens: La Fuente de Verdad Que Sobrevive a Cada Traspaso

Los design tokens son las decisiones atómicas de tu marca y producto — color, espaciado, radio, tipografía, elevación, duración de movimiento — expresadas como variables con nombre en lugar de valores codificados directamente. Estructurados correctamente (idealmente siguiendo el formato del W3C Design Tokens Community Group), los tokens se vuelven independientes de la plataforma: la misma fuente alimenta tu aplicación web, tu app iOS, tu app Android e incluso tu experiencia de kiosco en Flutter en una sucursal bancaria de West Bay.

• Tokens globales: valores en bruto (códigos hexadecimales, escalas de píxeles, familias tipográficas) que rara vez cambian.
• Tokens alias/semánticos: nombres orientados a un propósito como 'color.background.critical' o 'spacing.card.padding' que referencian tokens globales.
• Tokens de componente: la capa más granular, específica de un componente concreto (por ejemplo 'button.primary.background.hover').
• Usa Variables de Figma con modos para gestionar simultáneamente Claro/Oscuro y LTR/RTL, en lugar de duplicar frames.
• Exporta los tokens mediante Tokens Studio o la API nativa de Figma, y transfórmalos con Style Dictionary en propiedades personalizadas CSS, Swift, Kotlin o configuración de Tailwind.

Gobernanza: Convertir un Kit de Piezas en un Producto Vivo

La gobernanza es lo que mantiene coherente un sistema de diseño cuando decenas de colaboradores — diseñadores en la sede central, desarrolladores en un equipo externalizado, un equipo de marketing produciendo un microsite de campaña — lo tiran en direcciones distintas. El modelo que mejor funciona para las organizaciones qataríes a las que hemos dado soporte, ya sea un banco con sede en Doha o una unidad digital ministerial, es híbrido: un pequeño equipo central (2-4 personas) es dueño de la arquitectura, los tokens y el ritmo de publicación, mientras que los equipos de producto contribuyen con nuevos componentes a través de un proceso ligero de RFC (solicitud de comentarios). Cada componente propuesto necesita un caso de uso documentado, una revisión de accesibilidad y ejemplos de contenido en árabe/inglés antes de fusionarse. El versionado semántico (mayor.menor.parche) y un changelog público terminan con la clásica parálisis de 'nadie sabe si es seguro actualizar'.

• Define una matriz RACI: quién es Responsable, Aprobador, Consultado e Informado para cada categoría de token y familia de componentes.
• Publica las directrices de contribución tanto en árabe como en inglés — esto por sí solo elimina una barrera de adopción importante en los equipos multiculturales de Qatar.
• Establece una política de obsolescencia: aviso mínimo de 2 ciclos de publicación antes de eliminar un componente, con codemods automatizados cuando sea posible.
• Celebra mensualmente un consejo del sistema de diseño con representantes de cada unidad de negocio (banca minorista, corporativa, canales digitales) para arbitrar conflictos.

Adopción en Organizaciones Qataríes: Del Mandato al Hábito

Hemos visto iniciativas de sistemas de diseño bien financiadas en Doha fracasar no porque los componentes fueran deficientes, sino porque la adopción se trató como un anuncio puntual en lugar de un programa continuo. Imponer el uso desde la dirección genera cumplimiento inicial; nunca produce una adopción genuina. Lo que funciona es convertir el sistema de diseño en el camino de menor resistencia: más rápido que construir desde cero, mejor documentado que los antiguos archivos de Sketch, y visiblemente mantenido.

• Designa 'champions del sistema de diseño' dentro de cada equipo — a menudo la forma más rápida de difundir las mejores prácticas bilingües entre equipos distribuidos.
• Organiza horas de consulta semanales (presenciales en las oficinas de Doha o por Teams) donde cualquier diseñador o desarrollador pueda plantear un bloqueo.
• Monitorea las analíticas de la librería de Figma y el uso de componentes en el código (mediante reglas de ESLint o escaneo de imports) para identificar qué equipos han adoptado el sistema y cuáles no.
• Integra el onboarding en la formación de nuevas incorporaciones — algo crítico en un mercado como Qatar donde los equipos suelen mezclar talento local, regional e internacional con hábitos de herramientas de diseño distintos.

RTL y Bilingüismo por Diseño: Lo No Negociable de Qatar

Cualquier producto digital lanzado en Qatar — ya sea una app bancaria, un portal de autogestión de telecomunicaciones o un servicio electrónico gubernamental — debe manejar impecablemente el RTL árabe y el LTR inglés, a menudo dentro de la misma sesión mientras los usuarios cambian de idioma. Integrar esto a nivel de componente, en lugar de parchearlo después del lanzamiento, es donde los sistemas de diseño demuestran su valor. Usa propiedades lógicas de CSS (margin-inline-start en lugar de margin-left) para que los componentes se inviertan automáticamente sin necesidad de una base de código RTL separada. Los iconos que transmiten direccionalidad (flechas, botones de retroceso, chevrones) necesitan un token de variante espejada, mientras que los iconos que no la transmiten (una lupa de búsqueda, una marca de verificación) nunca deben invertirse — un error que todavía vemos en aplicaciones en producción en toda la región. Los numerales son otra sutileza: decide desde el principio si tu producto usa numerales arábigos occidentales (0-9) o numerales arábigo-índicos orientales, y codifica esa elección como un token para que sea consistente en cada pantalla.

De Figma al Código: El Pipeline Que Realmente Publica

El pipeline técnico que implementamos para nuestros clientes suele verse así: los diseñadores gestionan los tokens como Variables de Figma, sincronizadas con un repositorio Git a través del plugin de Tokens Studio. Un workflow de GitHub Actions ejecuta Style Dictionary en cada merge para transformar los tokens en salidas específicas de cada plataforma — propiedades personalizadas CSS para la app web, XML/Kotlin para Android, Swift para iOS. Los componentes se documentan y se prueban visualmente en Storybook, que se convierte en la fuente de verdad compartida tanto para diseñadores como para desarrolladores (mucho más fiable que un hilo de comentarios en Figma). Herramientas de pruebas de regresión visual como Chromatic detectan cambios no deseados antes de que lleguen a staging. De forma crucial, un paso de QA de diseño — un diseñador revisando el componente construido frente a la especificación de Figma — ocurre antes de cada lanzamiento, no después de que lleguen las quejas de los usuarios.

Medir Lo Que Importa: KPIs para Ejecutivos en Doha

• Tasa de adopción de componentes: % de pantallas en producción construidas con componentes del sistema frente a soluciones personalizadas puntuales.
• Tiempo de entrega: tiempo medio desde el traspaso de diseño hasta el lanzamiento en producción, antes y después de implementar el sistema.
• Tasa de cumplimiento de accesibilidad: % de componentes que aprueban WCAG 2.2 AA, especialmente importante para los servicios digitales gubernamentales en Qatar.
• Puntuación de consistencia diseño-desarrollo: tasa de diferencia visual entre la especificación de Figma y la UI publicada, medida mediante comparación automatizada de capturas de pantalla.
• Reducción de tickets de soporte relacionados con inconsistencias de UI entre las versiones bilingües (AR/EN) del producto.

Un Escenario Fintech en Doha: Cómo Se Ve el Éxito

Imagina un equipo de servicios financieros digital-first en Doha lanzando un nuevo producto de ahorro en web, iOS y Android, en árabe e inglés, dentro de un plazo regulatorio ajustado ligado a los requisitos de open banking. Con los tokens como fuente de verdad, la renovación de marca (un nuevo color primario y una escala tipográfica actualizada) se propaga a las tres plataformas en un único pull request en lugar de tres actualizaciones manuales separadas. Con la gobernanza implementada, un componente de banner promocional liderado por marketing pasa por un RFC de dos días en lugar de codificarse fuera del sistema y romperse en el siguiente rediseño. Con la adopción integrada, los nuevos empleados se incorporan usando la documentación del sistema en lugar de tener que hacer ingeniería inversa de pantallas antiguas. El resultado no es solo un lanzamiento más rápido — es un producto que se mantiene consistente mientras la organización escala sus ambiciones digitales de cara a 2030.