Design System
Minerva: el design system que unificó Banco de Chile
Cómo construí componentes y documentación para el sistema de diseño que le dio coherencia visual a todos los productos digitales de uno de los bancos más grandes de Chile.
Year :
2023
Industry :
Banca — Fintech
Client :
Banco de Chile
Rol :
Design System Designer
Contexto
Banco de Chile no es un solo producto digital. Es un ecosistema: la app personal, la banca web, productos de inversión, seguros, el portal empresarial y herramientas internas para los equipos. Cada uno de esos productos había crecido de forma independiente, con equipos distintos, criterios distintos y librerías de componentes que no hablaban entre sí.
El resultado era lo que se conoce como fragmentación visual: el mismo botón con tres tamaños diferentes según el producto, tipografías inconsistentes, colores que variaban entre pantallas y una experiencia que no se sentía como la misma marca. Para un banco, eso no es solo un problema estético. Es un problema de confianza.
Minerva nació para resolver eso: un sistema único que todos los productos pudieran consumir, sin perder la flexibilidad que cada equipo necesitaba.
Fui parte del equipo de Diseño Product Designer responsable de construir y documentar componentes dentro de Minerva. Mi trabajo fue tanto técnico como editorial: no solo crear los componentes en Figma, sino asegurar que cualquier diseñador del banco pudiera entenderlos, usarlos correctamente y adoptarlos sin fricción.
El ecosistema que debía unificar
Minerva tenía que funcionar para productos con necesidades muy distintas. Eso implicaba diseñar componentes lo suficientemente flexibles para adaptarse a cada contexto sin romper la coherencia de marca.
📱 App personal Banca móvil iOS y Android. Alto volumen de usuarios, flujos transaccionales críticos. | 💻 Banca web Portal de escritorio para operaciones complejas. Tablas, formularios y dashboards densos. |
|---|---|
🚀 Portal empresarial Gestión de cuentas corporativas. Usuarios expertos con necesidades distintas al cliente retail. | 💰 Inversiones y seguros Productos financieros especializados con lenguaje y flujos propios del sector. |
🔧 Herramientas internas Productos usados por ejecutivos y equipos del banco. Misma librería, distinto contexto. | 🎢 Onboarding digital Flujos de apertura de cuenta y vinculación de nuevos clientes al ecosistema. |
El problema
Fragmentación visual entre productos. Cada equipo había construido sus propios componentes de forma independiente. El mismo elemento visual tenía hasta tres versiones distintas según el producto donde aparecía. |
|---|
Sin documentación de uso. Los componentes existentes no tenían guías claras de cuándo usarlos, cómo combinarlos o qué variantes existían. Cada diseñador tomaba sus propias decisiones, acumulando deuda de diseño. |
Fricción entre diseño y desarrollo. Sin una fuente de verdad compartida, los handoffs eran lentos y llenos de preguntas. Desarrollo reimplementaba componentes que ya existían porque no había forma de saber qué estaba disponible. |
Escalabilidad bloqueada. Cada vez que un producto nuevo necesitaba un componente, lo creaba desde cero. No había forma de reutilizar trabajo previo de forma confiable. |
Resultados
+35%Reducción en tiempo de diseño por sprint | −30%Tiempo de implementación en desarrollo | +85%Adopción del sistema en equipos internos | −12%Inconsistencias visuales en auditorías |
|---|
Mi rol dentro del sistema
Trabajé como parte del equipo core de Minerva. Mi contribución se concentró en dos frentes: la construcción de componentes en Figma y la documentación de uso para los equipos que consumirían el sistema.
Construir para un design system es diferente a diseñar para un producto. Cada decisión tiene consecuencias para múltiples equipos y productos. Un componente mal documentado genera dudas en diez equipos al mismo tiempo. Una variante innecesaria multiplica la deuda de diseño a escala. Esa responsabilidad cambia completamente cómo piensas cada elemento.
En un DS, diseñas para diseñadores. Tu usuario es el equipo que va a consumir el sistema, no el cliente final del banco.
Mi proceso
Auditoría de interfaces existentes
Antes de crear ningún componente nuevo, auditamos las 70+ pantallas digitales del banco para mapear qué elementos existían, cuántas versiones tenían y cuáles eran los más usados. Esa auditoría definió la prioridad de construcción: primero los componentes de mayor frecuencia y mayor inconsistencia.
Definición de tokens de diseño
textLos tokens fueron la base de todo. Definí los valores primitivos del sistema: paleta de colores completa con semántica clara (brand, feedback, neutral, surface), escala tipográfica, espaciado, radio de bordes y sombras. Cada token tenía un nombre con significado funcional, no solo descriptivo. No "azul-500" sino "color-action-primary"
Construcción de componentes en Figma
Construí los componentes atómicos y moleculares del sistema: formularios, botones, cards, alertas, tablas, inputs, modales, tooltips, navegación y más. Cada componente tenía variantes construidas con Auto Layout, propiedades de componente para controlar estados (default, hover, focus, error, disabled) y estructura interna consistente para facilitar el handoff a desarrollo.
Documentación de uso y guidelines
Cada componente tenía su página de documentación: cuándo usarlo, cuándo no usarlo, qué variante elegir según el contexto, ejemplos de uso correcto e incorrecto, y notas de accesibilidad. La documentación la escribí pensando en el diseñador que llega nuevo al banco y necesita entender el sistema sin que nadie le explique.
Validación con equipos de producto
Antes de publicar cada componente, lo validamos con los equipos de producto que lo iban a usar. Eso reveló casos de uso que no habíamos anticipado y evitó que el sistema se volviera académico: bien documentado pero difícil de aplicar en contextos reales. Las sesiones de feedback con los equipos fueron parte formal del proceso de entrega.
Estrategia de adopción
Un design system que nadie usa no sirve. Trabajamos con los equipos para facilitar la migración desde sus librerías propias a Minerva. Hicimos sesiones de onboarding, creamos plantillas de arranque para proyectos nuevos y establecimos un proceso de contribución para que los equipos pudieran proponer nuevos componentes al sistema de forma ordenada.
Componentes que construí
El sistema cubría desde elementos atómicos hasta patrones complejos de interacción. Estos son algunos de los componentes que construí y documenté directamente.
Buttons Átomo — 6 variantes | Text Fields Átomo — Extended set | Color System Token — Paleta completa |
|---|---|---|
Typography Token — Type & line height | Cards Molécula — Múltiples layouts | Alerts & Feedback Molécula — 4 estados |
Navigation Organismo — Web y mobile | Modales Organismo — Confirmación y flujos | Data Tables Organismo — Portal corporativo |
Forms Patrón — Validación y estados | Tooltips Átomo — 8 posiciones | Checkboxes & Radios Átomo — Accesibles |
La arquitectura de tokens
Colores de marca | Feedback y estados |
|---|---|
--color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; | --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; |
Decisiones clave
La decisión más importante fue establecer el principio de componentes "cerrados pero extensibles". Cada componente tenía un conjunto fijo de variantes oficiales, pero incluía slots y propiedades que permitían adaptaciones controladas. Eso resolvió la tensión entre consistencia y flexibilidad que surgía constantemente cuando los equipos de producto sentían que el sistema era demasiado rígido para sus casos de uso.
La segunda decisión fue priorizar la documentación como producto de primera clase, no como tarea de cierre. Cada componente no se consideraba entregado hasta que tenía su documentación completa. Eso generó resistencia inicial porque ralentizaba el ritmo de entrega, pero fue lo que hizo que la adopción funcionara.
Un componente sin documentación es un componente que nadie va a usar correctamente. La documentación no era el manual del sistema: era parte del sistema.
También definimos un proceso de contribución formal para que los equipos de producto pudieran proponer nuevos componentes. Sin ese proceso, cada equipo tomaba la decisión de crear componentes propios cuando no encontraba lo que necesitaba en el sistema, volviendo al problema original de fragmentación.
Herramientas y metodología
Figma | Auto Layout | Component Properties |
|---|---|---|
Design Tokens | Variables Figma | Figma Libraries |
Storybook | Zeroheight | Accesibilidad WCAG |
Design Critique | Atomic Design | Confluence |
Aprendizajes
Diseñas para diseñadoresEn un DS tu usuario no es el cliente del banco. Es el diseñador que va a usar tu componente. Pensar en esa persona cambió completamente cómo tomaba decisiones de nomenclatura, estructura y documentación. | La adopción es un problema de diseñoTener los mejores componentes no garantiza que los equipos los usen. La adopción requiere onboarding, plantillas, sesiones de soporte y un proceso de contribución que haga sentir a los equipos parte del sistema. |
|---|---|
Los tokens son la inversión más rentableUna arquitectura de tokens bien pensada desde el inicio ahorra semanas de trabajo cuando el sistema escala. Cambiar un color de marca en un token actualiza todos los componentes automáticamente. | Escalar requiere gobernanzaSin un proceso claro de contribución y aprobación, un DS se fragmenta desde adentro. La gobernanza no era burocracia: era lo que mantenía la coherencia cuando el sistema crecía. |
Más proyectos
Design System
Minerva: el design system que unificó Banco de Chile
Cómo construí componentes y documentación para el sistema de diseño que le dio coherencia visual a todos los productos digitales de uno de los bancos más grandes de Chile.
Year :
2023
Industry :
Banca — Fintech
Client :
Banco de Chile
Rol :
Design System Designer
Contexto
Banco de Chile no es un solo producto digital. Es un ecosistema: la app personal, la banca web, productos de inversión, seguros, el portal empresarial y herramientas internas para los equipos. Cada uno de esos productos había crecido de forma independiente, con equipos distintos, criterios distintos y librerías de componentes que no hablaban entre sí.
El resultado era lo que se conoce como fragmentación visual: el mismo botón con tres tamaños diferentes según el producto, tipografías inconsistentes, colores que variaban entre pantallas y una experiencia que no se sentía como la misma marca. Para un banco, eso no es solo un problema estético. Es un problema de confianza.
Minerva nació para resolver eso: un sistema único que todos los productos pudieran consumir, sin perder la flexibilidad que cada equipo necesitaba.
Fui parte del equipo de Diseño Product Designer responsable de construir y documentar componentes dentro de Minerva. Mi trabajo fue tanto técnico como editorial: no solo crear los componentes en Figma, sino asegurar que cualquier diseñador del banco pudiera entenderlos, usarlos correctamente y adoptarlos sin fricción.
El ecosistema que debía unificar
Minerva tenía que funcionar para productos con necesidades muy distintas. Eso implicaba diseñar componentes lo suficientemente flexibles para adaptarse a cada contexto sin romper la coherencia de marca.
📱 App personal Banca móvil iOS y Android. Alto volumen de usuarios, flujos transaccionales críticos. | 💻 Banca web Portal de escritorio para operaciones complejas. Tablas, formularios y dashboards densos. |
|---|---|
🚀 Portal empresarial Gestión de cuentas corporativas. Usuarios expertos con necesidades distintas al cliente retail. | 💰 Inversiones y seguros Productos financieros especializados con lenguaje y flujos propios del sector. |
🔧 Herramientas internas Productos usados por ejecutivos y equipos del banco. Misma librería, distinto contexto. | 🎢 Onboarding digital Flujos de apertura de cuenta y vinculación de nuevos clientes al ecosistema. |
El problema
Fragmentación visual entre productos. Cada equipo había construido sus propios componentes de forma independiente. El mismo elemento visual tenía hasta tres versiones distintas según el producto donde aparecía. |
|---|
Sin documentación de uso. Los componentes existentes no tenían guías claras de cuándo usarlos, cómo combinarlos o qué variantes existían. Cada diseñador tomaba sus propias decisiones, acumulando deuda de diseño. |
Fricción entre diseño y desarrollo. Sin una fuente de verdad compartida, los handoffs eran lentos y llenos de preguntas. Desarrollo reimplementaba componentes que ya existían porque no había forma de saber qué estaba disponible. |
Escalabilidad bloqueada. Cada vez que un producto nuevo necesitaba un componente, lo creaba desde cero. No había forma de reutilizar trabajo previo de forma confiable. |
Resultados
+35%Reducción en tiempo de diseño por sprint | −30%Tiempo de implementación en desarrollo | +85%Adopción del sistema en equipos internos | −12%Inconsistencias visuales en auditorías |
|---|
Mi rol dentro del sistema
Trabajé como parte del equipo core de Minerva. Mi contribución se concentró en dos frentes: la construcción de componentes en Figma y la documentación de uso para los equipos que consumirían el sistema.
Construir para un design system es diferente a diseñar para un producto. Cada decisión tiene consecuencias para múltiples equipos y productos. Un componente mal documentado genera dudas en diez equipos al mismo tiempo. Una variante innecesaria multiplica la deuda de diseño a escala. Esa responsabilidad cambia completamente cómo piensas cada elemento.
En un DS, diseñas para diseñadores. Tu usuario es el equipo que va a consumir el sistema, no el cliente final del banco.
Mi proceso
Auditoría de interfaces existentes
Antes de crear ningún componente nuevo, auditamos las 70+ pantallas digitales del banco para mapear qué elementos existían, cuántas versiones tenían y cuáles eran los más usados. Esa auditoría definió la prioridad de construcción: primero los componentes de mayor frecuencia y mayor inconsistencia.
Definición de tokens de diseño
textLos tokens fueron la base de todo. Definí los valores primitivos del sistema: paleta de colores completa con semántica clara (brand, feedback, neutral, surface), escala tipográfica, espaciado, radio de bordes y sombras. Cada token tenía un nombre con significado funcional, no solo descriptivo. No "azul-500" sino "color-action-primary"
Construcción de componentes en Figma
Construí los componentes atómicos y moleculares del sistema: formularios, botones, cards, alertas, tablas, inputs, modales, tooltips, navegación y más. Cada componente tenía variantes construidas con Auto Layout, propiedades de componente para controlar estados (default, hover, focus, error, disabled) y estructura interna consistente para facilitar el handoff a desarrollo.
Documentación de uso y guidelines
Cada componente tenía su página de documentación: cuándo usarlo, cuándo no usarlo, qué variante elegir según el contexto, ejemplos de uso correcto e incorrecto, y notas de accesibilidad. La documentación la escribí pensando en el diseñador que llega nuevo al banco y necesita entender el sistema sin que nadie le explique.
Validación con equipos de producto
Antes de publicar cada componente, lo validamos con los equipos de producto que lo iban a usar. Eso reveló casos de uso que no habíamos anticipado y evitó que el sistema se volviera académico: bien documentado pero difícil de aplicar en contextos reales. Las sesiones de feedback con los equipos fueron parte formal del proceso de entrega.
Estrategia de adopción
Un design system que nadie usa no sirve. Trabajamos con los equipos para facilitar la migración desde sus librerías propias a Minerva. Hicimos sesiones de onboarding, creamos plantillas de arranque para proyectos nuevos y establecimos un proceso de contribución para que los equipos pudieran proponer nuevos componentes al sistema de forma ordenada.
Componentes que construí
El sistema cubría desde elementos atómicos hasta patrones complejos de interacción. Estos son algunos de los componentes que construí y documenté directamente.
Buttons Átomo — 6 variantes | Text Fields Átomo — Extended set | Color System Token — Paleta completa |
|---|---|---|
Typography Token — Type & line height | Cards Molécula — Múltiples layouts | Alerts & Feedback Molécula — 4 estados |
Navigation Organismo — Web y mobile | Modales Organismo — Confirmación y flujos | Data Tables Organismo — Portal corporativo |
Forms Patrón — Validación y estados | Tooltips Átomo — 8 posiciones | Checkboxes & Radios Átomo — Accesibles |
La arquitectura de tokens
Colores de marca | Feedback y estados |
|---|---|
--color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; | --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; |
Decisiones clave
La decisión más importante fue establecer el principio de componentes "cerrados pero extensibles". Cada componente tenía un conjunto fijo de variantes oficiales, pero incluía slots y propiedades que permitían adaptaciones controladas. Eso resolvió la tensión entre consistencia y flexibilidad que surgía constantemente cuando los equipos de producto sentían que el sistema era demasiado rígido para sus casos de uso.
La segunda decisión fue priorizar la documentación como producto de primera clase, no como tarea de cierre. Cada componente no se consideraba entregado hasta que tenía su documentación completa. Eso generó resistencia inicial porque ralentizaba el ritmo de entrega, pero fue lo que hizo que la adopción funcionara.
Un componente sin documentación es un componente que nadie va a usar correctamente. La documentación no era el manual del sistema: era parte del sistema.
También definimos un proceso de contribución formal para que los equipos de producto pudieran proponer nuevos componentes. Sin ese proceso, cada equipo tomaba la decisión de crear componentes propios cuando no encontraba lo que necesitaba en el sistema, volviendo al problema original de fragmentación.
Herramientas y metodología
Figma | Auto Layout | Component Properties |
|---|---|---|
Design Tokens | Variables Figma | Figma Libraries |
Storybook | Zeroheight | Accesibilidad WCAG |
Design Critique | Atomic Design | Confluence |
Aprendizajes
Diseñas para diseñadoresEn un DS tu usuario no es el cliente del banco. Es el diseñador que va a usar tu componente. Pensar en esa persona cambió completamente cómo tomaba decisiones de nomenclatura, estructura y documentación. | La adopción es un problema de diseñoTener los mejores componentes no garantiza que los equipos los usen. La adopción requiere onboarding, plantillas, sesiones de soporte y un proceso de contribución que haga sentir a los equipos parte del sistema. |
|---|---|
Los tokens son la inversión más rentableUna arquitectura de tokens bien pensada desde el inicio ahorra semanas de trabajo cuando el sistema escala. Cambiar un color de marca en un token actualiza todos los componentes automáticamente. | Escalar requiere gobernanzaSin un proceso claro de contribución y aprobación, un DS se fragmenta desde adentro. La gobernanza no era burocracia: era lo que mantenía la coherencia cuando el sistema crecía. |
Más proyectos
Design System
Minerva: el design system que unificó Banco de Chile
Cómo construí componentes y documentación para el sistema de diseño que le dio coherencia visual a todos los productos digitales de uno de los bancos más grandes de Chile.
Year :
2023
Industry :
Banca — Fintech
Client :
Banco de Chile
Rol :
Design System Designer
Contexto
Banco de Chile no es un solo producto digital. Es un ecosistema: la app personal, la banca web, productos de inversión, seguros, el portal empresarial y herramientas internas para los equipos. Cada uno de esos productos había crecido de forma independiente, con equipos distintos, criterios distintos y librerías de componentes que no hablaban entre sí.
El resultado era lo que se conoce como fragmentación visual: el mismo botón con tres tamaños diferentes según el producto, tipografías inconsistentes, colores que variaban entre pantallas y una experiencia que no se sentía como la misma marca. Para un banco, eso no es solo un problema estético. Es un problema de confianza.
Minerva nació para resolver eso: un sistema único que todos los productos pudieran consumir, sin perder la flexibilidad que cada equipo necesitaba.
Fui parte del equipo de Diseño Product Designer responsable de construir y documentar componentes dentro de Minerva. Mi trabajo fue tanto técnico como editorial: no solo crear los componentes en Figma, sino asegurar que cualquier diseñador del banco pudiera entenderlos, usarlos correctamente y adoptarlos sin fricción.
El ecosistema que debía unificar
Minerva tenía que funcionar para productos con necesidades muy distintas. Eso implicaba diseñar componentes lo suficientemente flexibles para adaptarse a cada contexto sin romper la coherencia de marca.
📱 App personal Banca móvil iOS y Android. Alto volumen de usuarios, flujos transaccionales críticos. | 💻 Banca web Portal de escritorio para operaciones complejas. Tablas, formularios y dashboards densos. |
|---|---|
🚀 Portal empresarial Gestión de cuentas corporativas. Usuarios expertos con necesidades distintas al cliente retail. | 💰 Inversiones y seguros Productos financieros especializados con lenguaje y flujos propios del sector. |
🔧 Herramientas internas Productos usados por ejecutivos y equipos del banco. Misma librería, distinto contexto. | 🎢 Onboarding digital Flujos de apertura de cuenta y vinculación de nuevos clientes al ecosistema. |
El problema
Fragmentación visual entre productos. Cada equipo había construido sus propios componentes de forma independiente. El mismo elemento visual tenía hasta tres versiones distintas según el producto donde aparecía. |
|---|
Sin documentación de uso. Los componentes existentes no tenían guías claras de cuándo usarlos, cómo combinarlos o qué variantes existían. Cada diseñador tomaba sus propias decisiones, acumulando deuda de diseño. |
Fricción entre diseño y desarrollo. Sin una fuente de verdad compartida, los handoffs eran lentos y llenos de preguntas. Desarrollo reimplementaba componentes que ya existían porque no había forma de saber qué estaba disponible. |
Escalabilidad bloqueada. Cada vez que un producto nuevo necesitaba un componente, lo creaba desde cero. No había forma de reutilizar trabajo previo de forma confiable. |
Resultados
+35%Reducción en tiempo de diseño por sprint | −30%Tiempo de implementación en desarrollo | +85%Adopción del sistema en equipos internos | −12%Inconsistencias visuales en auditorías |
|---|
Mi rol dentro del sistema
Trabajé como parte del equipo core de Minerva. Mi contribución se concentró en dos frentes: la construcción de componentes en Figma y la documentación de uso para los equipos que consumirían el sistema.
Construir para un design system es diferente a diseñar para un producto. Cada decisión tiene consecuencias para múltiples equipos y productos. Un componente mal documentado genera dudas en diez equipos al mismo tiempo. Una variante innecesaria multiplica la deuda de diseño a escala. Esa responsabilidad cambia completamente cómo piensas cada elemento.
En un DS, diseñas para diseñadores. Tu usuario es el equipo que va a consumir el sistema, no el cliente final del banco.
Mi proceso
Auditoría de interfaces existentes
Antes de crear ningún componente nuevo, auditamos las 70+ pantallas digitales del banco para mapear qué elementos existían, cuántas versiones tenían y cuáles eran los más usados. Esa auditoría definió la prioridad de construcción: primero los componentes de mayor frecuencia y mayor inconsistencia.
Definición de tokens de diseño
textLos tokens fueron la base de todo. Definí los valores primitivos del sistema: paleta de colores completa con semántica clara (brand, feedback, neutral, surface), escala tipográfica, espaciado, radio de bordes y sombras. Cada token tenía un nombre con significado funcional, no solo descriptivo. No "azul-500" sino "color-action-primary"
Construcción de componentes en Figma
Construí los componentes atómicos y moleculares del sistema: formularios, botones, cards, alertas, tablas, inputs, modales, tooltips, navegación y más. Cada componente tenía variantes construidas con Auto Layout, propiedades de componente para controlar estados (default, hover, focus, error, disabled) y estructura interna consistente para facilitar el handoff a desarrollo.
Documentación de uso y guidelines
Cada componente tenía su página de documentación: cuándo usarlo, cuándo no usarlo, qué variante elegir según el contexto, ejemplos de uso correcto e incorrecto, y notas de accesibilidad. La documentación la escribí pensando en el diseñador que llega nuevo al banco y necesita entender el sistema sin que nadie le explique.
Validación con equipos de producto
Antes de publicar cada componente, lo validamos con los equipos de producto que lo iban a usar. Eso reveló casos de uso que no habíamos anticipado y evitó que el sistema se volviera académico: bien documentado pero difícil de aplicar en contextos reales. Las sesiones de feedback con los equipos fueron parte formal del proceso de entrega.
Estrategia de adopción
Un design system que nadie usa no sirve. Trabajamos con los equipos para facilitar la migración desde sus librerías propias a Minerva. Hicimos sesiones de onboarding, creamos plantillas de arranque para proyectos nuevos y establecimos un proceso de contribución para que los equipos pudieran proponer nuevos componentes al sistema de forma ordenada.
Componentes que construí
El sistema cubría desde elementos atómicos hasta patrones complejos de interacción. Estos son algunos de los componentes que construí y documenté directamente.
Buttons Átomo — 6 variantes | Text Fields Átomo — Extended set | Color System Token — Paleta completa |
|---|---|---|
Typography Token — Type & line height | Cards Molécula — Múltiples layouts | Alerts & Feedback Molécula — 4 estados |
Navigation Organismo — Web y mobile | Modales Organismo — Confirmación y flujos | Data Tables Organismo — Portal corporativo |
Forms Patrón — Validación y estados | Tooltips Átomo — 8 posiciones | Checkboxes & Radios Átomo — Accesibles |
La arquitectura de tokens
Colores de marca | Feedback y estados |
|---|---|
--color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; --color-brand-primary: #001e62; --color-brand-accent: #cc0000; --color-action-primary: #004a99; --color-surface-secondary: #e8ecf5; | --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; --color-feedback-success: #1a7a3e; --color-feedback-error: #cc0000; --color-feedback-warning: #b45c00; --color-feedback-info: #004a99; |
Decisiones clave
La decisión más importante fue establecer el principio de componentes "cerrados pero extensibles". Cada componente tenía un conjunto fijo de variantes oficiales, pero incluía slots y propiedades que permitían adaptaciones controladas. Eso resolvió la tensión entre consistencia y flexibilidad que surgía constantemente cuando los equipos de producto sentían que el sistema era demasiado rígido para sus casos de uso.
La segunda decisión fue priorizar la documentación como producto de primera clase, no como tarea de cierre. Cada componente no se consideraba entregado hasta que tenía su documentación completa. Eso generó resistencia inicial porque ralentizaba el ritmo de entrega, pero fue lo que hizo que la adopción funcionara.
Un componente sin documentación es un componente que nadie va a usar correctamente. La documentación no era el manual del sistema: era parte del sistema.
También definimos un proceso de contribución formal para que los equipos de producto pudieran proponer nuevos componentes. Sin ese proceso, cada equipo tomaba la decisión de crear componentes propios cuando no encontraba lo que necesitaba en el sistema, volviendo al problema original de fragmentación.
Herramientas y metodología
Figma | Auto Layout | Component Properties |
|---|---|---|
Design Tokens | Variables Figma | Figma Libraries |
Storybook | Zeroheight | Accesibilidad WCAG |
Design Critique | Atomic Design | Confluence |
Aprendizajes
Diseñas para diseñadoresEn un DS tu usuario no es el cliente del banco. Es el diseñador que va a usar tu componente. Pensar en esa persona cambió completamente cómo tomaba decisiones de nomenclatura, estructura y documentación. | La adopción es un problema de diseñoTener los mejores componentes no garantiza que los equipos los usen. La adopción requiere onboarding, plantillas, sesiones de soporte y un proceso de contribución que haga sentir a los equipos parte del sistema. |
|---|---|
Los tokens son la inversión más rentableUna arquitectura de tokens bien pensada desde el inicio ahorra semanas de trabajo cuando el sistema escala. Cambiar un color de marca en un token actualiza todos los componentes automáticamente. | Escalar requiere gobernanzaSin un proceso claro de contribución y aprobación, un DS se fragmenta desde adentro. La gobernanza no era burocracia: era lo que mantenía la coherencia cuando el sistema crecía. |