- Rol
- Diseñador líder, 0 a 1
- Alcance
- Arquitectura de información y flujos
- El problema
- El precio de entrada y el costo de salida de un mensaje vivían en más de veinte herramientas, archivos y bandejas de entrada. Un solo cambio de precio de un proveedor pasaba por ocho equipos en cinco grupos y doce pasos.
- Mi rol
- Lideré el diseño desde cero: diez sesiones de descubrimiento, trece roles, el sitemap y los flujos de la primera versión. Otra persona diseñadora ayudó con las sesiones y la síntesis, y un equipo de seis personas lo construyó.
- Qué decidí
- Organizar por registro, no por equipo. Empezar por los datos de proveedores y gateways. Reemplazar la captura manual de datos por la revisión de datos.
- Dónde está
- El caso de uso 1, el onboarding de proveedores y el control de gateways, está en producción. La gestión de precios, la tarificación de transacciones y los accruals vienen después.
13
roles mapeados
20+
herramientas y archivos en el proceso anterior
6
recorridos “cómo es hoy” (as-is) documentados
10
sesiones de entrevistas y recorridos guiados
60%
menos tiempo para actualizar datos de proveedores, proyectado en pruebas de usabilidad
Contexto y mi rol
Syniverse opera la mensajería de bancos, aerolíneas y tiendas. Cada mensaje tiene un precio de entrada y un costo de salida, y la plataforma global de precios es el producto interno pensado para concentrar ambos. El margen es la diferencia, y leerlo exige los dos precios, el tráfico y un tipo de cambio del mismo mes.
Abrir imagen completa (se abre en una pestaña nueva)
Tras tres décadas de adquisiciones, varias plataformas operaban en paralelo, cada una con su propia herramienta de precios. Los registros de proveedores, los cambios de precio y la conciliación de fin de mes se hacían a mano.
Dirigí las entrevistas y las sesiones de trabajo, tomé las decisiones de diseño y las presenté a los stakeholders.
El problema
Mapeamos un cambio de precio de un proveedor con cada equipo que lo toca.
Abrir imagen completa (se abre en una pestaña nueva)
En todas las sesiones salieron los mismos patrones:
- El mismo precio se captura varias veces. Llega por correo, se compara en una hoja de cálculo y se vuelve a capturar en cada herramienta de precios.
- Nadie ve el proceso completo. No hay historial de qué cambió, cuándo ni por qué.
- Los registros no coinciden. El ID de proveedor del ERP no es el de las herramientas de precios, así que cada reporte empieza con un mapeo manual.
- La moneda es un trabajo aparte. Tres fuentes de tipo de cambio, convertidas en Excel.
El reporte de accrual de fin de mes tiene seis recetas distintas, según el proveedor, el ciclo de facturación, la entidad legal, la moneda y el modelo de cobro. Todas se resuelven fuera del sistema.
Abrir imagen completa (se abre en una pestaña nueva)
Cómo lo abordé
Abrir imagen completa (se abre en una pestaña nueva)
Descubrimiento: tareas reales, en pantalla. Diez sesiones con precios, facturación, accruals, contabilidad, auditoría, ventas y operaciones de plataforma. Las personas hicieron sus tareas reales en pantalla, lo que mostró dónde había que recapturar datos y dónde la pantalla y la exportación no coincidían. Un requisito marcó todo lo demás: reemplazar la captura manual de datos por la revisión de datos.
Definición: un recorrido por equipo, trece roles. Mapeé el recorrido as-is de cada equipo y documenté trece roles con sus objetivos y herramientas (hasta doce para un solo rol de precios), y luego validé con los stakeholders los recorridos del estado futuro.
Abrir imagen completa (se abre en una pestaña nueva)
Diseño: un caso de uso a la vez. Para el onboarding de proveedores pasé de flujos a wireframes y a alta fidelidad en el design system de Syniverse. Las revisiones en Figma abrían con las preguntas que necesitaba que me respondieran, como «¿Billing ID y Vendor ID se refieren a lo mismo?»
Decisiones clave
Organizar por registro, no por equipo
- Decidido
- El sitemap sigue los registros de los que todos ya hablan (clientes, proveedores, precios, gateways, sender IDs), con los datos de referencia y las reglas de precios en Administración.
- Descartado
- Secciones por equipo, que cada equipo pidió.
- Por qué
- Habrían reconstruido los silos dentro de la herramienta nueva.
Abrir imagen completa (se abre en una pestaña nueva)
Empezar por los datos de proveedores y gateways
- Decidido
- El roadmap empieza con proveedores y gateways.
- Descartado
- Empezar por la gestión de precios, el dolor más fuerte.
- Por qué
- Un precio solo sirve si la plataforma sabe a qué proveedor pertenece y qué gateways llevan su tráfico. Los recorridos respaldaron ese orden: los cambios de precio, la tarificación y los accruals se apoyan en esos registros.
Revisar en lugar de recapturar
- Decidido
- Los proveedores entran por archivo y no se guarda nada hasta que la persona lo haya visto. Un paso de revisión clasifica cada fila como New, Update o Error. Las actualizaciones muestran cada campo antes y después, y los errores indican la línea y el motivo.
- Por qué
- El proceso anterior volvía a capturar cada precio en varias herramientas. En la plataforma los datos entran una sola vez, por archivo, y el trabajo pasa de capturarlos a revisarlos.
Abrir imagen completa (se abre en una pestaña nueva)
Tres caminos al mismo resultado
- Decidido
- Los gateways se pueden asignar uno por uno, en un lote de selección múltiple con un paso de confirmación, o con un archivo masivo con vista previa. Los tres terminan en el mismo estado y la misma confirmación.
- Descartado
- Un solo método.
- Por qué
- A veces se corrige una ruta, a veces un puñado y a veces una hoja completa del proveedor. Un solo método habría estado mal para dos de los tres casos.
Abrir imagen completa (se abre en una pestaña nueva)
La solución
Onboarding de proveedores. Una importación de dos pasos: subir un .xls o .csv (con plantilla) y revisar. Tras confirmar, la lista de proveedores marca lo que se agregó o actualizó.
Abrir imagen completa (se abre en una pestaña nueva)
Gateways y el registro del proveedor. Desde la pestaña de gateways de un proveedor se asignan, editan, quitan o dan de baja gateways. Cada acción destructiva conserva una fecha de vigencia y un comentario. Todas las tablas comparten una misma barra de herramientas para columnas, filtros y exportación.
Abrir imagen completa (se abre en una pestaña nueva)
Lo conocido gana a lo nuevo. Conservé los patrones en los que ya confiaban: tablas densas con búsqueda y filtros, importación desde Excel, side sheets y flujos cortos.
Datos de referencia. Los destinos y los gateways se definen una sola vez: los países se pueden agrupar con fechas de vigencia y cada gateway tiene su propio registro.
Abrir imagen completa (se abre en una pestaña nueva)
Entrega y estado
El equipo de ingeniería construyó el caso de uso 1 a partir de estos diseños. Me quedé durante la construcción para resolver dudas, revisar la implementación y ajustar casos límite.
Abrir imagen completa (se abre en una pestaña nueva)
Impacto
El caso de uso 1 está en producción: el onboarding de proveedores cambió capturar datos por revisarlos, y los gateways tienen tres caminos al mismo resultado. Las pruebas de usabilidad proyectaron una reducción de 60% en el tiempo para actualizar los datos de un proveedor.
Reflexión
En un proyecto como este, la mayor parte del trabajo de diseño ocurre antes de que exista cualquier pantalla. Lo más difícil fue saber si los IDs de dos equipos significaban lo mismo, y los recorridos fueron la forma de responder.
Empezar por el caso de uso menos glamoroso fue lo correcto, porque todas las funciones posteriores leen de los registros de proveedores y gateways. La próxima vez pondría la primera versión frente a sus usuarios, con sus propios datos, más pronto. Ver a alguien de accruals importar un archivo real de proveedores nos habría enseñado más que otra revisión.
Los nombres de clientes en las capturas están difuminados.