Culqi - Omnicanal Payment

Contexto

Entré a Culqi en mayo de 2023, en un momento donde el producto estaba creciendo rápido y la empresa avanzaba hacia la certificación de adquirencia. El reto no era solo claridad, seguridad y consistencia mientras el ecosistema se expandía.

Mi primer frente fue Dashboard (Panel) 1.0, donde los clientes podían ver ventas y abonos, crear links de pago y suscripciones, gestionar devoluciones y más. Ese producto evolucionó a Dashboard 2.0: una nueva versión que combinó migración de lo existente con nuevas necesidades de adquirencia y seguridad.

Con el tiempo asumí liderazgo y amplié mi alcance hacia POS, BackOffice y CulqiApp, coordinando decisiones de interfaz a nivel ecosistema y buscando reducir el gap entre lo diseñado y lo desarrollado.

El problema de negocio

Este ecosistema tiene fricción real porque conviven perfiles con objetivos distintos:

Dueños / administradores de negocio (B2B): necesitan control, visibilidad y decisiones rápidas (ventas, abonos, comisiones, devoluciones).
Operadores en punto de venta (POS): prioridad es velocidad y acceso inmediato a lo más usado (contexto de alta presión, turnos, rotación).
Operación interna / BackOffice: requiere control, configuración y soporte de procesos sin romper consistencia.
Soporte: absorbía fricciones del producto (cuando algo no se entiende o no existe un camino claro, el costo se traslada a soporte).
Producto + desarrollo: necesitaban reglas y handoff más claros para evitar re-trabajo y QA visual correctivo.

Stakes reales: Sin consistencia entre productos, cada nueva feature generaba retrabajo de QA visual, fricción en handoffs, y confusión para usuarios que operaban múltiples superficies. Esto ralentizaba delivery justo cuando el negocio necesitaba acelerar para certificación.

Desafio clave

El dilema más difícil no era "diseñar bonito". Era construir un Design System escalable mientras el negocio empujaba features urgentes para certificación de adquirencia (deadline externo no negociable).

Trade-off brutal: Si invertía tiempo en foundations (tokens, componentes, reglas), ralentizaba delivery de features que el negocio necesitaba YA. Si no invertía, heredaba caos exponencial: cada nueva feature generaba inconsistencias, retrabajo de QA visual, y fricción en handoffs.

Por qué era difícil:

Presión operativa real: Certificación de adquirencia era condición para crecer. No podía decir "esperen, construyamos sistema primero".
Deuda técnica visual creciente: Cada squad tomaba decisiones aisladas. Variaciones repetidas (botones con 5 variantes de padding, alerts con reglas distintas) se multiplicaban.
QA visual correctivo consumía tiempo que no teníamos: Developers entregaban basado en Figma, pero sin reglas claras. QA encontraba inconsistencias tarde. Se corregía reactivamente.
Sin métrica, no había conversación de hechos: "Hay inconsistencias" era percepción. Necesitaba convertir eso en estado medible del sistema.

Constraints adicionales:

Ecosistema multi-producto (Panel, POS, BackOffice, App) con equipos distribuidos
Sin proceso compartido claro entre diseño y desarrollo
Liderazgo distribuido (5 diseñadores sin rituales consolidados)

Mi approach estratégico

Mi trabajo combinó diseño de producto con orden interno para sostener calidad bajo presión.

Decisión 1: Trabajo por ecosistema, no pantallas sueltas

‍Qué aprendí: Al auditar el ecosistema, vi que el problema no era "falta de diseño". Era decisiones repetidas sin criterio compartido. Cada squad resolvía el mismo problema (estados de botón, feedback de error) de forma distinta.‍
Qué decidí: Prioricé patrones repetidos y rutas críticas antes de sumar más features. Mapear qué se repetía en Panel, POS, BackOffice. Eso redujo fricciones reales y me dio leverage para argumentar inversión en Design System.‍
Por qué: Si no sabía QUÉ reutilizar, construir un DS era desperdicio. Identificar patrones críticos primero = ROI claro.

Decisión 2: Culqi Design Process v1.0 - Framework de ownership claro

‍Qué aprendí: El gap entre diseño y desarrollo no era técnico, era de expectativas. ¿Quién valida antes de handoff? ¿Qué significa "listo para desarrollo"? No había criterios compartidos.‍
Qué decidí: Diseñé e implementé una primera versión del Culqi Design Process para alinear Experience Design con Scrum. Definí ownership por etapa (Discovery/Definición/Ideación/Iteración/Desarrollo/Producción) y criterios de aceptación por fase.‍
Por qué: Sin proceso, cada handoff era negociación. Con proceso, "Design Ready" tenía definición concreta.‍
Limitación: Se usó en fase inicial. No pude seguir iterándolo por mi salida.

Decisión 3: Rituales de alineamiento - Crits estructurados + workshops

‍Qué aprendí: Con 5 diseñadores trabajando en paralelo, las inconsistencias aparecían silenciosamente. Un diseñador usaba spacing de 16px, otro 20px. Nadie lo notaba hasta handoff.‍
Qué decidí: Implementé rituales semanales: design crits para revisar trabajo en progreso, workshops para decisiones de ecosistema (navegación, estados, arquitectura).‍
Por qué: Reducir ambigüedad temprano = menos retrabajo. Elevar consistencia entre squads antes de que llegara a código.

Decisión 4: Handoff con criterio - Arquitectura UI + componentes reutilizables + QA visual preventivo

‍Qué aprendí: Los developers recibían Figma pero sin contexto de decisiones. "¿Por qué este botón es outline y este filled?" quedaba implícito. Eso generaba interpretación y errores.‍
Qué decidí: Estandaricé handoff con tres capas: (1) Arquitectura UI (estructura, jerarquía, flujo), (2) Componentes reutilizables mapeados con reglas (estados, variantes, cuándo usar qué), (3) Revisión de QA visual ANTES de pasar a desarrollo (no después).‍
Por qué: QA visual preventivo = detectar inconsistencias en diseño, no en código. Más barato corregir en Figma que en producción.

Decisión 5: Medición simple (Design Ready) - Excel tracking + conversaciones con hechos

‍Qué aprendí: "El DS está avanzando" no generaba urgencia. Necesitaba convertir percepción de caos en métrica concreta.‍
Qué decidí: Usé un Excel para medir preparación de componentes por Web/Mobile (Design Ready = % de catálogo UI diseñado, documentado, listo para handoff). Esto me permitió sostener conversaciones con hechos: "Estamos en 45% Design Ready. Si invertimos 2 sprints en consolidar forms y feedback, subimos a 70%".‍
Por qué: Medir cambia la conversación. No es "siento que hay inconsistencias". Es "tenemos 55% del sistema sin definir".‍
Impacto medible: Design Ready subió de 45% a 83% (~85% al cierre).

Migración completa con nuevos requerimientos de seguridad y adquirencia. Rediseñé flujos críticos priorizando claridad en transacciones, estados y acciones.

Panel 2.0

Ventas - Detalle

El flujo parte en el listado de Ventas para buscar y filtrar transacciones. Al entrar al Detalle, el usuario entiende el monto abonado con desglose de comisiones e IGV, reduciendo dudas típicas de soporte.

Ventas - Abonos

Como complemento, Abonos permite revisar depósitos por día (y/o en listado), diferenciando “abonado” vs “por abonar” y dando trazabilidad al dinero que llega al negocio.

POS - Cobro

Teclado digital integrado para reducir pasos y tiempos.
Navegación directa (Cobrar / Ventas / Anular / Soporte) para cambiar de tarea sin perder contexto.
Propina opcional con montos sugeridos para acelerar el input.
Cierre con confirmación + acciones claras (imprimir/enviar) para terminar la operación.

BackOffice (operación interna) — Gestión de comercios

BackOffice es la capa operativa del ecosistema: herramientas internas para configurar, auditar y dar soporte a comercios sin romper consistencia con Panel/POS.

En este caso muestro un flujo representativo: Gestión de comercios → Detalle de comercio.

Parte del listado (búsqueda + filtros + estados), y al entrar al detalle se centraliza la información crítica del comercio (datos generales, cuentas bancarias, direcciones y terminales) con acciones claras para mantener la operación al día.

Otros módulos del BackOffice: riesgos, traffic control, abonos, controversias, prevención de fraudes y reportes.

CulqiApp

Iteración para acercar control del negocio a la palma de la mano, complementando el Dashboard.

Todas las pantallas están reconstruidas con data ficticia para fines de portafolio

Design System

Para que el ecosistema no se rompa con el crecimiento, trabajé en consolidar una base de UI reutilizable (no como "librería bonita", sino como palanca de eficiencia).

Qué resolvía:

Había variaciones repetidas, componentes similares con reglas distintas y decisiones visuales que se reabrían en cada squad. Eso afectaba consistencia, velocidad y calidad de handoff.

Qué construimos:

Foundations: color, tipografía, espaciado, layout, bordes, sombras e iconografía (reglas reutilizables + criterios).
Componentes prioritarios por familias: forms (Field Wrapper, inputs, select, checkbox, radiobutton, switch), feedback (alerts, toast/snackbar), acciones (button/icon button), estado/metadata (badge/tag/chip/loading), entre otros.
Reglas y estados: default/hover/focus/disabled donde aplica, y micro-decisiones que suelen romper consistencia (focus rings, densidad, spacing, stroke vs fill).

Resultado medible:

Subí el Design Ready de 45% a 83% (≈85% al cierre), con el catálogo de componentes 100% mapeado y diseñado en una primera versión lista para ejecución/handoff.La documentación en Confluence quedó en 12% porque prioricé construir el set de componentes primero.Storybook quedó en plan/conversación con un partner dev, sin implementación cerrada en mi etapa.

Impacto

Diagnóstico + decisión + resultado

El problema: Observé que ~50% del tiempo de desarrollo se gastaba en retrabajo de componentes (validé con entrevistas a 12-15 developers). El Design System estaba al 15% de cobertura, solo desktop. Cada squad resolvía el mismo problema (botones, estados, feedback) de forma distinta, generando QA visual correctivo tardío.

La decisión: No construí "un sistema bonito". Construí una estrategia faseada sin nuevos recursos:

Fase 1 (Figma): Escalé cobertura de 15% → 85% priorizando web/mobile. Documenté internamente (cuándo usar, estados, copy). Reduje retrabajo de 5 a 3 días/sprint (40% mejora, ~40 días-developer/año liberados). Esto fue posible porque:

Priorizaba patrones repetidos antes de sumar features
Implementé rituales (design crits, workshops) para reducir ambigüedad temprano
Hice QA visual preventivo en diseño, no correctivo en código
Medía todo con Design Ready (% catálogo UI listo para handoff)

Fase 2 (Paralela): Documentación en Confluence y QA en Storybook, sin romper producción. La idea era que mientras yo documentaba, developers validaban código en paralelo, sin bloqueos.

Handoff: 2 meses antes de salir, dejé toda documentación en Figma y transicioné a 2 PD. El DS quedó listo para que continuaran adoptando código sin fricción.

Resultados medibles:

Design Ready: 45% → 85% (catálogo UI 100% mapeado, diseñado y documentado para handoff)
Retrabajo: 5 → 3 días/sprint (40% reducción, equivalente a ~40 días-dev/año)
5 diseñadores coordinados con rituales estructurados + proceso compartido
Documentación Confluence: 12% (prioricé construir componentes primero; Fase 2 quedó incompleta por mi salida)
Storybook: Arquitectura definida, sin implementación cerrada

Impacto cualitativo:

Developers reportaron menos fricción en handoffs ("ahora sé qué hacer aquí")
Soporte absorbió menos tickets de inconsistencias visuales
Squads dejaron de re-resolver problemas ya resueltos
Conversaciones pasaron de percepción ("hay caos") a estado del sistema ("estamos en 85% Design Ready")

Por qué funcionó:El DS no hizo "consistencia mágica". Lo que aceleró delivery fue: (1) priorizar patrones repetidos primero, (2) crear proceso compartido, (3) medir estado del sistema, (4) QA preventivo en diseño. Eso redujo decisiones repetidas y retrabajo, permitiendo lanzar features más rápido bajo presión de certificación, sin heredar deuda técnica visual.

Aprendizajes

Construir sin iteración "ahorra" tiempo solo al inicio; luego se paga en soporte y retrabajo.
Un sistema útil reduce decisiones repetidas y acelera delivery, no es el que tiene más variantes.
Medir (Design Ready) cambia la conversación: deja de ser percepción y pasa a ser estado del sistema.

Qué haría diferente:Cerrar el loop de Storybook antes de salir. Dejarlo en "plan" sin implementación piloto significa que el siguiente diseñador tiene que re-evangelizar. Hubiera hecho al menos un componente end-to-end (Figma → Storybook → QA) para demostrar flujo.

‍