Culqi - Product Design

Diseñé y escalé el ecosistema Culqi (Dashboard 2.0, POS, BackOffice, CulqiApp) y consolidé una base de UI y proceso para acelerar delivery y reducir retrabajo.

≈85%

Design Ready (UI lista para desarrollo)

100%

Catálogo UI mapeado y diseñado (v1)

Diseñadores liderados (rituales + QA + handoff)

Product Designer

Lead Product Designer

Fintech

B2B

SaaS

Payments

Design System

2023 - 2025

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 sumar funcionalidades: era sostener 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.

Usuarios

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.

Proceso

Mi trabajo combinó diseño de producto con orden interno para sostener calidad en un ecosistema que crecía rápido.

Trabajo por ecosistema (no pantallas sueltas): prioricé patrones repetidos y rutas críticas antes de sumar más features.
Proceso compartido (Culqi Design Process v1.0): diseñé e implementé una primera versión para alinear Experience Design con Scrum, definiendo ownership por etapa y criterios de aceptación. Se usó en una fase inicial; no pude seguir iterándolo por mi salida.
Rituales de alineamiento: crits, revisiones y workshops para reducir ambigüedad y elevar consistencia entre squads.
Handoff con criterio: arquitectura UI, componentes reutilizables y revisión de QA visual antes de pasar a desarrollo.
Medición simple (Design Ready): usé un Excel para medir preparación de componentes por Web/Mobile y sostener conversaciones con hechos.

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”, complementando el Dashboard.

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

Sistema de Diseño

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 se priorizó construir el set de componentes primero.
Storybook quedó en plan/conversación con un partner dev, sin implementación cerrada en mi etapa.

Este proyecto fue Product Design en complejidad real: múltiples superficies (Dashboard, POS, BackOffice, App), presión por delivery y tensiones operativas. Mi aporte principal fue sostener claridad de interfaz y criterio de calidad a nivel ecosistema, mientras empujaba una base de UI y proceso para reducir fricción diseño ↔ desarrollo.

Aprendizajes clave

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