03 / Design system · Banca · 2026
NATIVO / BCI
Convertir decisiones repetidas en reglas compartidas.
Desde conversaciones con las áreas y una auditoría global de las librerías existentes hasta la construcción y revisión de componentes de Nativo, el sistema de diseño transversal de BCI.
Resultado: Construcción y revisión en Figma
- Rol
- Product Designer · equipo Nativo DS
- Proyecto
- Discovery · auditoría · componentes
- Mi foco
- Construcción y revisión de componentes en Figma
- Periodo
- 2026
Caso destacado
El reto
El reto: Unificar librerías que resolvían lo mismo de formas distintas
Varias librerías convivían en productos distintos: App Kit y Pagos SDK para app; Web Kit, Wholesale, Pyme y el design system web de Productos de Pagos para web. Resolvían necesidades similares con nombres, anatomías, configuraciones y niveles de documentación diferentes.
La homologación exigía reconocer qué podía compartirse y qué respondía a un comportamiento distinto. Cada variante adicional también implicaba nuevas decisiones de construcción y mantenimiento.
Mi contribución
Mi contribución: Del levantamiento a la construcción de componentes
Participé en el levantamiento con las áreas y en la auditoría visual de las librerías. Después, mi responsabilidad se concentró en construir y revisar componentes en Figma: interpretar las definiciones del equipo, aplicar acuerdos a la anatomía y a las propiedades, y comprobar la consistencia entre estados.
La arquitectura general, el modelo de tokens y las decisiones de marca formaban parte del marco compartido del equipo. No se presentan como decisiones individuales.
Propuesta de valor
Propuesta de valor: Criterios compartidos en lugar de soluciones paralelas
Conectar objetivos del banco, necesidades de las áreas y herramientas existentes en criterios compartidos para un sistema transversal: una base que el equipo pueda revisar y reutilizar.
Decisiones y evidencia
Decisiones y evidencia: De la auditoría a decisiones visibles en las piezas
Discovery y auditoría global
El trabajo comenzó con conversaciones con los equipos para entender los objetivos del banco, las áreas involucradas y el alcance de cada práctica de diseño. Antes de construir componentes, alineamos el sistema que debía existir.
01 · Contexto de negocio
Objetivos, productos y alcance esperado del nuevo sistema.
02 · Áreas y herramientas
Design systems, UI kits y archivos de producto utilizados por cada equipo.
03 · Inventario y solapamiento
Componentes duplicados, nombres distintos y usos equivalentes o particulares.
04 · Criterios compartidos
Qué debía unificarse, qué conservar diferencias y qué requería validación.
Qué se duplicaba
- El mismo tipo de componente aparecía con nombres distintos según la librería: Snackbar y Toast, Alert y Banner alert, o varias versiones de Stepper.
- Un mismo componente se clasificaba en familias diferentes: Stepper, por ejemplo, era navegación en una librería y feedback en otra.
- La documentación funcional y técnica tenía niveles desiguales: completa, incompleta, desactualizada o no disponible, según la librería.
- En los tokens, un mismo valor podía existir en varios lugares sin una cadena de alias que los conectara.
Cómo definió el equipo los criterios transversales
- Un inventario común por familia funcional —Actions, Forms & Inputs, Navigation, Feedback & Status y Data Display & Content—, uso, plataforma y estado de la documentación.
- La comparación de propósito, anatomía, estados, tokens, accesibilidad y contexto de uso, para distinguir duplicación real de variaciones necesarias.
- Un modelo de capas para tokens —referencia, marca, sistema y componente, encadenadas en ese orden— y preguntas para ubicar cada valor: ¿cambia por marca, por tema o por tamaño?, ¿es un valor primitivo?
- Una revisión antes de crear un token: si ya existía uno equivalente y si la nueva pieza añadía una diferencia real de estado, variante o marca.
Evidencia reconstruida · lectura del ecosistema
- Productos / áreas
- App Kit · Web Kit · Wholesale · Pyme · Pagos
- Activos observados
- Componentes · UI kits · estilos · tokens · documentación
- Preguntas de auditoría
- Propósito · duplicación · utilidad · dependencia · mantenimiento
- Salida
- Inventario común + criterios de homologación + excepciones justificadas
La auditoría no buscaba uniformar por apariencia: convertía hallazgos dispersos en reglas que pudieran sostenerse transversalmente.
Las reglas también eran parte del diseño
Antes de construir: definir los límites
El equipo había documentado propósito, anatomía, naming, consumo de tokens y accesibilidad. El marco distinguía cambios por marca, tema y tamaño, y ayudaba a decidir qué debía heredar una pieza, qué podía configurar y cuándo una diferencia justificaba una nueva variante.
Durante el trabajo: incorporar las definiciones
Las revisiones ajustaban esas reglas: propiedades que se separaban, dependencias que impedían cerrar una pieza y acuerdos que requerían una nueva validación. El registro distinguía decisiones vigentes, en revisión y descartadas.
Tres decisiones que se pueden ver en los componentes
01 · Tabs · Flexibilidad dentro de una estructura común
Se acordó distribuir el ancho por igual y mantener 48 px de altura, descartando el tamaño Compact. La flexibilidad quedó en la cantidad de pestañas y en elementos opcionales. Al construir, conservé separados State y Selected: una pestaña puede estar seleccionada y, además, recibir foco.
02 · TextInput · Separar el estado del contenido
El equipo registró una definición concreta: separar State de Content para evitar nombres como «enabled filled» o «error empty». El estado conserva su significado con o sin contenido. La construcción muestra esa separación en Size, State y Content; la etiqueta y el mensaje de ayuda o error corresponden a FormField.
03 · Tooltip · Cambiar la configuración, conservar la anatomía
Tooltip debía resolver desde una ayuda breve hasta contenido con título y acción. La construcción distingue Default y Rich, con cuatro posiciones y propiedades opcionales para título, acción y flecha. Separar Container de Arrow permite cambiar la posición sin redefinir el contenido.
Construido, revisado y validado son estados distintos
El proceso del equipo precisó que un componente debía presentarse y validarse antes de considerarlo cerrado. Los cronogramas registraban mejoras, dependencias y nuevas rondas de revisión.
La documentación también separaba verificaciones automatizables de revisión humana. El orden de foco, la navegación por teclado y los lectores de pantalla requieren comprobar el comportamiento real: un estado Focus dibujado en Figma aporta una definición visual; la validación funcional continúa en la implementación.
Impacto y alcance real
Impacto y alcance real: Una base que el equipo puede revisar y reutilizar
El discovery y la auditoría global dieron contexto a la homologación. Mi contribución se materializó en componentes con anatomías consistentes, propiedades explícitas y estados diferenciados: una base revisable para continuar la construcción.
Aprendizajes
Aprendizajes: El costo de una decisión aparece cuando otros la usan
Este proyecto reforzó mi atención a las consecuencias de cada ajuste: qué excepción introduce, qué otras piezas afecta y quién tendrá que mantenerlo.
Construir un sistema exige hacer explícitas esas dependencias y conservar el criterio detrás de la solución. Ese es el aprendizaje que traslado a mi trabajo de producto.
Lo que no puede afirmarsepor falta de medición
Lo que no puede afirmarse: Construcción y revisión, no adopción
- El resultado es construcción y revisión en Figma. No hay métricas de adopción, eficiencia del equipo ni desempeño en producción.
- Los criterios de auditoría y el modelo de tokens fueron trabajo del equipo; algunos documentos seguían en revisión.
- Un estado dibujado en Figma no demuestra accesibilidad funcional: esa validación ocurre en la implementación.