CX + UX + UI · Mobile App · Banca digital · 2026

Mi solicitud.
Que el cliente sepa
en qué va su trámite

Rediseño de la experiencia de seguimiento de una solicitud digital de tarjeta de crédito, de principio a fin: investigación, análisis, experiencia de servicio, prototipo navegable y plan de validación. Lo desarrollé en 5 días porque prioricé la agilidad: entender bien el problema y llegar rápido a algo que se pudiera probar.

CX · UX/UI Designer
App móvil + correo, teléfono y agencia
Figma · Figma Make · Notion
5 días · 2026
Dos teléfonos con la pantalla Documentos para tu solicitud de la app de banca digital
01: El problema

El cliente envía su solicitud…
y después no sabe qué está pasando.

Un banco en plena transformación digital quiere que sus clientes resuelvan más trámites por su cuenta, sin dejarlos solos. Pero aparecen señales de que algo falla: solicitudes que no se completan, visitas a la agencia para preguntar por el estado de un trámite y asesores respondiendo una y otra vez las mismas dudas.

Me enfoqué en un trámite concreto: la solicitud digital de tarjeta de crédito.

Tramo estudiado: desde que el cliente envía la solicitud hasta que entiende el resultado de la revisión de sus documentos y sabe que la evaluación continúa. La decisión de crédito quedó fuera de alcance.

El caso parte de un escenario simulado, sin datos reales de clientes. Por eso hablo de hipótesis y hallazgos preliminares, no de resultados.

02: Investigación

Investigar como detective,
antes de dibujar una sola pantalla.

01
Investigar
Hipótesis · Plan · Instrumentos
02
Analizar
Afinidad · Hallazgos · HMW
03
Diseñar la experiencia
Journey · Priorización · Blueprint
04
Construir
Pantallas · Prototipo
05
Validar
Protocolo · Criterios

Planteamiento del problema

Qué sabemos

Hay consultas repetidas sobre el avance de los trámites y clientes que no tienen claro el siguiente paso.

Qué no sabemos

Qué cree el cliente que consiguió al enviar (¿la registró, está en evaluación o ya fue aprobada?), cómo reconoce si le toca esperar o actuar, y qué ocurre justo antes de que decida llamar.

Qué necesitamos descubrir

Dónde empieza la confusión, qué información necesita para continuar y qué convierte una duda en una consulta.

Qué decidiríamos con la investigación

Cuál es el problema principal, en qué momento concentrar el rediseño, qué necesita entender el cliente y qué puede resolver solo.

Plan de investigación

  • Objetivo: comprender cómo las personas interpretan la información y el acompañamiento durante su solicitud, para saber qué les facilita o dificulta entender qué pasa y quién debe actuar.
  • Perfiles: personas asalariadas e independientes, porque acreditan ingresos con documentos distintos. Es un criterio para observar variación, no una hipótesis.
  • Métodos: entrevistas semiestructuradas a clientes (cualitativo), entrevistas breves a asesores (cualitativo) y análisis de registros de avance de las solicitudes (cuantitativo).
  • Muestra: 8 clientes (4 asalariados y 4 independientes) que hayan enviado una solicitud digital de tarjeta en los últimos 3 meses; 4 asesores que atiendan consultas sobre esas solicitudes; y los registros de avance de las solicitudes digitales de tarjeta de 3 meses completos. Es un muestreo intencional para una primera ronda exploratoria, que se ampliaría si sigue apareciendo información nueva.
  • Limitaciones: no se observa el uso real de la app; 8 personas no cubren toda la diversidad; no permite estimar frecuencias.

Instrumentos

  • Guion de entrevista a clientes (30–40 min): 9 preguntas que reconstruyen una solicitud real: qué recibió la persona, qué entendió y qué hizo.
  • Guion de entrevista a asesores: qué ve el asesor sobre una solicitud, qué puede confirmar y qué preguntas se repiten.
  • Guía de análisis de registros: cómo avanzaron realmente las solicitudes: en qué paso quedó cada una, cuánto tardó, cuándo se pidió un documento adicional y qué quedó pendiente.
Por qué importan los registros

Las entrevistas cuentan lo que la persona recuerda y siente; los registros, lo que de verdad pasó con su trámite. Al cruzarlos se ve si la duda nace de un retraso real o de un mensaje que no se entendió. También evitan un error común: llamar «abandonada» a una solicitud que simplemente sigue en evaluación. Por eso, las solicitudes todavía en curso no se cuentan como abandonadas.

«No pregunto "¿te confundió el mensaje?". Pregunto "¿qué significó ese mensaje para ti?". Una pregunta que sugiere la respuesta solo confirma lo que ya creías.»

03: Análisis

De información suelta
a un problema bien definido.

Agrupé la información en un mapa de afinidad y la separé en hechos, interpretaciones e hipótesis. De ahí salieron cuatro hallazgos preliminares.

Hallazgo 1

Iniciar no garantiza saber qué sigue.

El cliente necesita distinguir esperar de actuar.

Oportunidad: aclarar los siguientes pasos y a quién le corresponden.

Hallazgo 2

El avance del trámite es motivo de consulta en la agencia.

La atención ya forma parte del seguimiento.

Oportunidad: que la atención explique la situación y si toca esperar o actuar.

Hallazgo 3

Parte de las solicitudes no se completa y no sabemos por qué.

No lo atribuí a la confusión sin evidencia.

Oportunidad: entenderlo antes de actuar.

Hallazgo 4

Ser autónomo es entender, no solo tener un canal.

Reducir visitas no equivale a mejorar la experiencia.

Oportunidad: diseñar el seguimiento junto con el acompañamiento humano.

Problema principal

Después de enviar una solicitud digital de tarjeta de crédito, algunos clientes tienen dificultades para comprender qué está ocurriendo con su trámite y reconocer si deben esperar una respuesta del banco o realizar alguna acción para continuar.

Pregunta de diseño

¿Cómo podríamos ayudar a quienes enviaron una solicitud digital de tarjeta a comprender su situación y el siguiente paso, para que sepan cuándo esperar, cuándo actuar y cómo obtener orientación si la necesitan?

Por qué una pregunta y no una solución: elegir desde el inicio «una pantalla de seguimiento» habría sido asumir la respuesta. Mostrar un estado puede dejar sin aclarar qué significa y qué hacer después. La pregunta deja abiertas varias salidas y da un criterio para evaluar cualquier solución: que el cliente entienda cómo continuar.

04: Experiencia de servicio

Diseñar la experiencia,
no solo la interfaz.

El momento crítico

«Archivo cargado correctamente»

Es verdad, pero no le dice a Carolina (32 años, persona ilustrativa) si el documento sirve ni si le falta algo. Así que espera, revisa el correo, llama y termina yendo a la agencia.

Qué resolver primero

Prioricé las oportunidades con una matriz de impacto y esfuerzo. Tres quedaron arriba:

P1

Aclarar el siguiente paso · ganancia rápida

Alto impacto y bajo esfuerzo: responde directamente a «¿tengo que hacer algo?». Depende de que los pasos y sus responsables estén definidos.

P2

Hacer comprensible la situación · ganancia rápida

Favorece la autogestión. Su riesgo es mostrar información desactualizada, por eso depende de que los estados sean fiables.

P3

Que la ayuda permita continuar · oportunidad estratégica

Alto impacto, pero mayor esfuerzo: hace más útil el tiempo de atención. Depende de que el asesor vea la misma información que el cliente y de que haya responsables de seguimiento.

Implementación por fases

Fase 1

Los mensajes

Requisito visible, confirmación de envío y correos. Puede arrancar ya.

Fase 2

El estado en vivo

«Mi solicitud» mostrando en qué va el trámite, con estados fiables.

Fase 3

La vista del asesor

Que el asesor vea lo mismo que el cliente. Es la que más esfuerzo requiere.

Service blueprint

El blueprint conecta lo que el cliente hace y ve con lo que pasa dentro del banco: procesos, sistemas y dependencias. Lo apliqué al tramo más crítico, desde que Carolina envía el comprobante hasta que entiende que sus documentos están completos. Así se ve qué tiene que existir detrás para que cada mensaje sea cierto: por ejemplo, la app solo puede decir «Recibimos tu nuevo comprobante» si el archivo ya quedó guardado.

Service blueprint: acciones del cliente, lo que ve, qué pasa detrás, sistemas y dependencias en los cuatro pasos, desde enviar el comprobante hasta entender el resultado
05: Solución

Del problema a una solución
que se puede tocar.

Cinco decisiones de diseño

Cada decisión responde una duda concreta del cliente y se apoya en lo que mostró el análisis.

Decisión 1: separar recibimos de aprobamos. Responde a la duda ¿Envié la solicitud… ya me aprobaron?
Decisión 2: cada estado responde qué pasa, a quién le toca y cuándo habrá novedades. Responde a la duda ¿Mi trámite avanzó? ¿Tengo que hacer algo?
Decisión 3: guiar la acción pendiente de principio a fin. Responde a la duda ¿Qué me falta? ¿Y si se envió mal?
Decisión 4: información consultable siempre. Responde a la duda ¿Dónde veo cómo va? ¿Y si no carga?
Decisión 5: ayuda humana visible y con contexto. Responde a la duda ¿Y si igual no entiendo?

Estados y situaciones especiales

Criterio común

Ningún estado deja al cliente sin saber qué pasó ni qué puede hacer.

  • Carga: indica que está trabajando y bloquea el botón para evitar un doble envío.
  • Errores: si la información no carga, muestra el último estado con su fecha; si el envío no se confirma, permite comprobarlo sin volver a elegir el archivo.
  • Validaciones: los errores se explican junto al campo, antes de enviar.
  • Confirmaciones: nunca prometen más de lo que ocurrió.
  • Sin plazo: si no hay fecha estimada, no se inventa una.

Prototipo navegable

El prototipo navegable en alta fidelidad recorre dos escenarios:

  • Con corrección: recibe el aviso de que un documento no se puede leer, lo corrige, pasa por errores en el camino y termina con sus documentos completos.
  • Sin incidencias: envía, consulta y recibe el aviso de documentos completos.

UI en alta fidelidad

06: Validación

Un prototipo no demuestra
que una solución funciona.

La validación con usuarios todavía no se ha aplicado, así que no muestro participantes, citas ni resultados. Lo que sí está listo es el protocolo.

Plan: 5 o 6 personas de 25 a 60 años, mitad asalariadas y mitad independientes. Unas ya solicitaron productos en línea y otras nunca. Sesiones moderadas de 25 a 30 minutos, pensando en voz alta.

Tres tareas neutrales

Sin nombrar botones ni pantallas.

  • Tarea 1: «Sube tu comprobante y termina tu solicitud. Después, quieres saber en qué va.»
  • Tarea 2: «Revisa qué ocurre y resuelve lo que corresponda.»
  • Tarea 3: «Imagina que te queda una duda que la app no resuelve. Muéstrame qué harías.»
Criterio de éxito

La solución funciona si al menos 5 de 6 personas entienden que recibido no es aprobado, saben a quién le toca actuar y completan la corrección sin ayuda. Fijé estos criterios antes de probar, para no interpretar los resultados a conveniencia.

¿Es rentable para el banco?

Lo que todavía no se sabe: el valor para el negocio está por validar. No se ha medido qué consultas son evitables ni cuánto tiempo de atención representan. Tampoco se asume que toda consulta sobre, ni se atribuyen a la propuesta aumentos de solicitudes completadas, ventas, ingresos o ahorros.

La hipótesis

Si parte de las consultas se debe a que el cliente no entiende en qué va su trámite, mejorar esa comprensión podría reducir aclaraciones evitables y liberar tiempo de atención.

Cómo lo comprobaría: un piloto A/B

1

Medir la situación actual

Con datos reales del banco, para tener un punto de partida.

2

Lanzar un piloto

Un grupo de clientes usa la nueva experiencia y otro, el grupo de control, sigue con la actual.

3

Comparar ambos grupos

Consultas por estado en agencias y llamadas, documentos aprobados al primer envío, correcciones por solicitud, motivos de corrección y envíos duplicados.

  • Si no funciona: si el piloto no muestra diferencias frente al grupo de control, la propuesta no se escala tal como está; se revisa en qué punto no cambió el comportamiento antes de seguir invirtiendo. La vista del asesor (fase 3) solo se construye si la prueba demuestra que la ayuda humana es necesaria.
  • Límites: son indicadores propuestos, no medidos. Dependen de que la revisión documental registre el resultado y el motivo de cada documento, y de que los dos grupos sean comparables en volumen y tipo de solicitudes.
07: Si tuviera una semana más

Verificar que el banco puede cumplir
lo que la pantalla promete.

Toda la propuesta depende de que los estados existan y estén al día. Un estado incorrecto es peor que no mostrar ninguno: una pantalla confusa se arregla, pero una promesa que el sistema no puede cumplir destruye la confianza.

Antes de probar con usuarios, revisaría con otras áreas, como operaciones y tecnología, para saber qué estados atraviesa una solicitud, quién los actualiza, con qué demora y qué ve el asesor.

08: Lo que aprendí

Tres lecciones
de este proyecto.

1

Aprender a priorizar con criterio.

Tenía mucha información y poco tiempo, y no podía hacerlo todo perfecto. Tuve que decidir qué era lo más importante y enfocarme en eso. En el trabajo diario pasa lo mismo: casi nunca hay tiempo para todo, y saber elegir con criterio dónde poner el esfuerzo vale más que intentar abarcarlo todo a medias.

2

Elegir el tramo donde se cruzan el cliente y el banco.

Acoté el estudio al tramo que va desde que el cliente envía la solicitud hasta que entiende el resultado de la revisión de sus documentos. Lo elegí porque ahí se ven las dos partes al mismo tiempo: el cliente que espera o tiene que actuar, y el banco que revisa, pide documentos y responde.

3

Formular la pregunta antes de diseñar la solución.

Todavía no conocía las causas del problema. Empezar por una pantalla de seguimiento habría sido asumir qué necesitaba el cliente antes de comprobarlo. Formulé primero la pregunta de diseño para dejar abierta la forma de resolverlo, ya fuera con comunicación, interacción o acompañamiento, y poder comparar alternativas.

¿Quieres recorrer el flujo completo, con sus errores y estados?

Ver prototipo navegable → ← Volver al portafolio

Siguiente proyecto

Pawly · Asistente de nutrición para mascotas →

Ver caso de estudio