CONTEXTO, RESTRICCIONES Y OBJETIVOS
La inconsistencia no era solo visual. Afectaba reconocimiento y confianza.
Los usuarios no evalúan interfaces. Evalúan señales de confianza. Cuando esas señales son inconsistentes, la confianza se debilita y aumenta la fricción durante la interacción.
Banco de Crédito del Perú (BCP), uno de los bancos más grandes del Perú, operaba a través de múltiples productos digitales, equipos y puntos de contacto. Cada equipo avanzaba rápido, pero tomando decisiones de forma aislada, sin coordinación operacional compartida.
Con el tiempo, esto creó un ecosistema fragmentado donde:
- Las interfaces se veían y comportaban distinto.
- Los componentes se reconstruían en lugar de reutilizarse.
- Las señales de confianza se volvieron inconsistentes.
El problema no era falta de diseño.
Era falta de alineación.
EL OBJETIVO
- Establecer señales de confianza en canales digitales.
- Estandarizar patrones visuales y de interacción.
- Reducir trabajo duplicado entre equipos.
- Acelerar la velocidad de entrega.
El banco no necesitaba otra guía.
Necesitaba una base compartida.
Lineamientos independientes
Experiencias
fragmentadas
La falla no estaba en la ejecución. Era estructural.
Cada equipo optimizaba localmente. El sistema se degradaba globalmente.
ROL Y ALCANCE
Lead designer · Visión, evolución y escalabilidad del sistema · 2016–2022
Lo que comenzó como un UI kit evolucionó hacia un sistema compartido entre plataformas, equipos y flujos de trabajo.
Lideré la definición de la visión, estructura y modelo de adopción del sistema entre diseño e ingeniería, alineando diseño e ingeniería alrededor de un modelo operativo compartido que redujera dependencia de decisiones aisladas por proyecto.
Esto no fue asignado como una iniciativa de producto. Surgió como respuesta a una brecha sistémica: los equipos resolvían problemas repetidamente, duplicando decisiones y generando fricción operacional entre productos.
Participé directamente en la definición de la arquitectura inicial, la lógica de componentes y los patrones de interacción, asegurando que el sistema no solo estuviera diseñado, sino preparado para escalar.
EXPERIENCIAS FRAGMENTADAS
El trabajo no consistía en diseñar interfaces.
Consistía en diseñar un sistema que definiera las interfaces en adelante.
EL CAMBIO CLAVE
No lo era. Era reconocimiento de confianza.
Los usuarios no siempre podían reconocer patrones consistentes entre plataformas digitales, generando fricción y dudas durante la interacción.
Esto no se trataba de hacer que los productos se vieran similares.
Se trataba de estandarizar señales de confianza en todo el ecosistema digital.
El diseño dejó de ser una capa visual.
Se convirtió en un sistema de reconocimiento y confianza.
INSIGHTS HUMANOS Y DEL SISTEMA
En los proyectos, los patrones de inconsistencia aparecían una y otra vez.
La inconsistencia no era una decisión individual. Era el resultado de trabajar sin un sistema compartido.
Los equipos no la elegían. Caían en ella bajo presión de tiempo, fragmentación y ausencia de sistemas compartidos.
Insight 1:
La inconsistencia debilita la confianza
En entornos financieros, la consistencia funciona como una señal de seguridad.
El reconocimiento reduce la duda.
Cuando los usuarios no pueden reconocer patrones consistentes entre interfaces, la confianza se debilita y aumenta la fricción durante la interacción.
Insight 2:
Reinventar genera costos invisibles
El tiempo no se perdía diseñando funcionalidades. Se perdía reconstruyendo bases.
Cada nueva iniciativa reiniciaba decisiones que ya habían sido tomadas y pagadas en otro lugar.
- Reconstrucción repetida de componentes y decisiones ya resueltas en otros productos.
- Decisiones de diseño redefinidas múltiples veces entre proyectos.
- Divergencia progresiva entre componentes, patrones y experiencias.
- Dependencia de conocimiento aislado entre equipos.
Insight 3:
Los sistemas funcionan por adopción, no por documentación
La documentación por sí sola no cambia comportamientos. La adopción sí.
La educación se volvió tan importante como el diseño.
Un sistema que los equipos no usan no es un sistema. Es una librería.
No escales componentes.
Escala dependencia.
SYSTEM THINKING
Antes de definir componentes o librerías, una pregunta cambió la dirección del trabajo:
¿Qué hace realmente que algo sea un sistema?
Un sistema no es una colección de recursos visuales. Es un conjunto de partes interconectadas trabajando hacia un objetivo compartido.
La estructura compartida habilita comportamiento compartido, coordinación cross-functional y escalabilidad operacional.
Entender esto transformó la iniciativa de crear lineamientos visuales a diseñar interconexión entre equipos.
Como un sistema nervioso coordinando movimiento en el cuerpo, el sistema de diseño conectaría principios, documentación, componentes y flujos de trabajo, permitiendo que equipos independientes se movieran consistentemente sin control centralizado.
PRINCIPIOS DE DISEÑO
Tres principios guiaron la adopción y gobernanza del sistema en toda la organización.
Un lenguaje, muchos productos
Cada interfaz debía sentirse inequívocamente BCP. Los patrones visuales compartidos refuerzan reconocimiento, confianza y consistencia en todos los canales digitales.
Reutilizar antes que reinventar
Los componentes son inversiones de largo plazo, no entregables de proyecto.
Las bases reutilizables reducen duplicación y aceleran la entrega de producto.
Contribución antes que control centralizado
El sistema evoluciona mediante responsabilidad compartida entre equipos. La contribución distribuida permite escalar el sistema sin convertirlo en un cuello de botella operacional.
DISEÑO DEL SISTEMA
El sistema fue estructurado para coordinar decisiones entre diseño, tecnología y negocio mediante bases reutilizables compartidas.
Los diseñadores reutilizaban componentes del sistema y los desarrolladores reutilizaban código existente por defecto. Los nuevos requerimientos impulsaban la creación colaborativa de componentes, permitiendo que los equipos aprendieran el sistema aplicándolo en proyectos reales.
La adopción estaba integrada en la creación de componentes y patrones, permitiendo que los equipos aprendieran el sistema utilizándolo y contribuyendo al sistema desde sus proyectos.
Esto generó un ciclo natural:
- Consumir el sistema.
- Extenderlo colaborativamente.
- Reforzarlo mediante reutilización.
Con el tiempo, no usar el sistema
se volvió visible e ineficiente.
EVOLUCIÓN DEL SISTEMA
El sistema no surgió completamente formado. Evolucionó a través de distintas etapas mientras la organización maduraba en cómo estructuraba y reutilizaba decisiones de diseño.
Lo que comenzó como lineamientos visuales aislados evolucionó gradualmente hacia un sistema de diseño estructurado, con bases semánticas, componentes reutilizables y escalabilidad multiplataforma.
2016 - UI KIT
Tool: Adobe Illustrator
Primeros intentos de estandarizar elementos visuales entre proyectos.
- Estilos de color definidos como valores estáticos en lugar de tokens semánticos.
- Lineamientos visuales documentados, pero no conectados a bases reutilizables.
- Estados de interacción aplicados de forma inconsistente.
- Componentes recreados manualmente en distintos proyectos.
2018 - STYLEGUIDE
Tool: Sketch
Evolución hacia una referencia visual compartida para los equipos de diseño.
- Estilos de UI compartidos entre múltiples proyectos.
- Patrones de componentes documentados, pero aún débilmente conectados.
- Decisiones de diseño centralizadas en lineamientos en lugar de estructuras reutilizables.
- Estados de interacción aún aplicados de forma inconsistente entre productos.
2020 - Design System (Conecto)
Tool: Sketch → Figma
Evolución hacia un sistema de diseño escalable para múltiples productos.
- Tokens de color semánticos reemplazando valores estáticos.
- Librerías de componentes reutilizables compartidas entre equipos.
- Estados de interacción consistentes en todo el sistema.
- Fundamentos preparados para implementarse en múltiples plataformas.
ATOMOS
MOLECULAS
ORGANISMos
PRODUCToS
ITERACIÓN BAJO RESTRICCIONES ORGANIZACIONALES REALES
El sistema no podía sostenerse únicamente desde el diseño. Su adopción dependía de la participación coordinada entre diseño, ingeniería y producto, transformando la forma en que las decisiones eran tomadas y compartidas dentro de la organización.
La adopción requería más que herramientas. Requería modificar cómo los equipos colaboraban, reutilizaban y tomaban decisiones.
Los equipos primero necesitaban entender cómo funcionan y evolucionan los sistemas. Eso llevó a diseñar y liderar programas de formación estructurados para acelerar adopción, reducir fragmentación y alinear equipos de UX, UI, Research y Service Design dentro de una lógica operativa común.
- Estándares centralizados para asegurar consistencia.
- Contribución federada que permitía a los equipos evolucionar componentes colaborativamente.
El sistema de diseño se convirtió en un ecosistema vivo, continuamente mejorado por quienes lo utilizaban.
LO QUE EVITAMOS
Las primeras versiones del sistema mostraron el riesgo con claridad. Los equipos lo trataban como una referencia, no como una dependencia. Los componentes eran copiados, modificados y desviados del sistema.
En pocos meses:
- Las variantes se multiplicaron.
- La reutilización disminuyó.
- La inconsistencia regresó.
El sistema no estaba fallando técnicamente. Se estaba volviendo opcional.
La solución no era imponer su uso.
Era convertirlo en la forma más eficiente de trabajar.
IMPACTO A ESCALA
Unificando decisiones de diseño y desarrollo a escala.
+75%
Reducción en tiempo de producción
Métrica estimada calculada a partir de tiempos promedio de producción y reutilización entre equipos.
28
Productos integrados al Design System
- Menor reconstrucción de componentes y decisiones ya resueltas en otros productos.
- Onboarding más rápido entre equipos de diseño y desarrollo.
- Mayor coordinación y colaboración entre producto, diseño e ingeniería.
- Escalabilidad operacional entre múltiples productos digitales.
- Adopción compartida entre equipos de producto y diseño.
EXPERIENCIA 2016:
Sistema legacy: fragmentación previa al sistema de diseño.
Ver experiencia legacy →
Evolución del sistema
Sistema de diseño aplicado en todo el ecosistema digital.
Ver experiencia actual →
El diseño pasó de ser una actividad de producción a convertirse en infraestructura estratégica.
Ver evolución del sistema →SISTEMA ESCALABLE
La validación más fuerte no ocurrió en el lanzamiento. Ocurrió con el tiempo.
Aparecieron nuevos productos.
Los equipos evolucionaron.
Las tecnologías cambiaron.
El sistema se adaptó sin requerir rediseño.
Los componentes escalaron sin requerir redefiniciones constantes entre productos.
El conocimiento permaneció.
La consistencia se sostuvo.
Lo que comenzó como una iniciativa de UIse convirtió en infraestructura organizacional.
INSIGHT FINAL
Cuando la inconsistencia se convierte en riesgo,
el diseño se convierte en infraestructura.
A escala, la confianza deja de ser visual.
Se convierte en comportamiento.
