UX Research Intern en banca digital: triangular métodos para decidir a ritmo semanal en ING España

Entré como Intern al área especializada de UX Research de ING España y me integré a un programa que ya operaba con cadencia semanal: 5 tests no moderados por semana, análisis y recomendaciones al backlog cada viernes. Durante 3 meses ejecuté ~60 tests de usabilidad de la app Twyp, el análisis heurístico del sitio de inversión y un card sorting guerrilla con perfiles internos. La triangulación de esos métodos —experto, cualitativo presencial, cuantitativo remoto— fue lo que convirtió hallazgos sueltos en argumentos accionables: el card sorting con internos dio 100% de acierto, el ampliado del equipo bajó a 40%. Esa brecha desbloqueó la decisión de rediseñar el naming de productos de inversión desde la lógica del cliente, no del banco.
ING Bank España
UX Research Intern
2019 · 3 meses
Madrid, España
Banca digital / Fintech

Tres equipos de producto, una unidad de research, evidencia que no podía esperar al trimestre

ING España necesitaba alimentar tres equipos de producto en paralelo con evidencia de usuarios accionable: Twyp (app de pagos y cashback), Inversión Naranja (sitio comercial de productos de inversión) y la web comercial principal, que estaba evaluando una reestructuración de navegación. El UX Research Team operaba como unidad de servicio interna y había abandonado el modelo de estudios trimestrales: el ritmo de los sprints de producto exigía evidencia cada semana.

En Twyp, los flujos de pago tenían fricción estructural recurrente y el concepto de cashback no se estaba traduciendo a un beneficio comprensible para usuarios no bancarizados. En Inversión Naranja, la arquitectura de información y el naming de fondos —categorías, niveles de riesgo, nombres de productos— habían sido definidos desde la lógica interna del banco, sin validación con clientes reales. En la web comercial, una propuesta de reestructuración estaba sobre la mesa y necesitaba evidencia cuantitativa antes de implementarse.

Mi entrada al equipo coincidió con esa demanda múltiple. No diseñé el programa: me integré a una infraestructura de research que ya funcionaba y ejecuté los estudios que se me asignaron. La pregunta operativa, dentro del rol Intern, era cómo aportar evidencia rigurosa a ese ritmo sin comprometer la calidad de los hallazgos.

Cómo se hizo el discovery: qué fue mío, qué fue del equipo

El programa combinó cuatro métodos en paralelo. Marco explícitamente qué ejecuté yo y dónde contribuí al análisis dentro de estudios mayores del equipo.

  • Análisis heurístico de Inversión Naranja (mi ejecución). Evaluación experta del sitio de productos de inversión: problemas de naming, jerarquía visual y consistencia en la arquitectura de información. Entregable: informe de hallazgos priorizados.
  • Card sorting guerrilla de Inversión Naranja (mi ejecución). 5 sesiones presenciales con empleados del área de inversión, tarjetas físicas, observación del razonamiento en voz alta. Pre-test del estudio formal del equipo.
  • Tests de usabilidad de Twyp (mi ejecución). ~60 tests no moderados en 12 semanas (5/semana), distribuidos en 4 sprints temáticos: Enviar dinero, TC-SMS-PIN, Descuentos 1, Descuentos 2. Cada sprint cerraba con informe y recomendaciones al equipo de producto.
  • Card sorting ampliado, tree testing web comercial, programa SUS (equipo, contribución al análisis). El card sorting ampliado a 15 participantes incluyó perfiles externos sin productos de inversión. El tree testing comparó arquitectura actual vs. propuesta con 120 participantes. El programa SUS continuo acumuló 5.709 respuestas como baseline cuantitativa de la salud UX del banco.

El valor de esta combinación no estaba en cada método por separado: estaba en cómo se ordenaban entre sí. El heurístico señalaba qué validar; el card sorting verificaba comprensión; el tree testing confirmaba navegación. Ninguno por separado era suficiente.

Validar solo con perfiles internos no es un atajo: es un punto ciego

El card sorting guerrilla con 5 empleados del área de inversión arrojó 100% de acierto al asociar categorías de fondos con sus descripciones. Leído en aislamiento, el dato decía «el sistema funciona». Cuando el equipo amplió el estudio a 15 participantes incluyendo perfiles sin productos de inversión, la tasa cayó al 40%.

La brecha no era ruido estadístico ni mala muestra: era la materialización exacta de lo que el análisis heurístico ya había anticipado. El naming de Inversión Naranja había sido diseñado desde la lógica interna del banco —terminología financiera asumida, jerarquía construida sobre el catálogo— no desde la comprensión del cliente que lo iba a usar. La triangulación experto + cualitativo interno + cuantitativo externo es lo que dio peso al argumento. Cualquiera de los tres sin los otros dos habría sido descartable.

Tres decisiones metodológicas dentro de un rol Intern

01

Análisis heurístico antes de los estudios con usuarios

El equipo iba a ejecutar card sorting y tree testing sobre Inversión Naranja. Propuse hacer primero la evaluación experta. La alternativa era saltar al research de usuarios directamente, en exploración abierta. Elegí evaluación experta primero.

Tradeoff: sacrificar parte de la exploración a cambio de poder diseñar los estudios posteriores con preguntas específicas, no abiertas. Lo que hizo robusto el hallazgo final del naming fue precisamente esa secuencia: heurístico → card sorting → tree testing, cada uno validando hipótesis del anterior.

02

Card sorting guerrilla con muestra interna como pre-test

Antes del card sorting formal del equipo, propuse una versión guerrilla con 5 empleados del área de inversión y tarjetas físicas. La alternativa era esperar al estudio formal con muestra externa. Elegí ejecutar el guerrilla primero.

Tradeoff: muestra sesgada (solo internos) a cambio de observación cualitativa que la versión remota no iba a capturar: el razonamiento en voz alta mientras agrupaban. Sin esa baseline interna del 100%, el dato externo del 40% habría sido menos contundente. La brecha entre ambas muestras fue lo que convirtió el hallazgo en evidencia accionable.

03

Operar dentro del modelo semanal heredado, no rediseñarlo

El ritmo de 5 tests por semana no fue decisión mía: era cómo el banco ya trabajaba research operativo. La decisión propia, dentro de ese modelo, fue cómo estructurar el informe semanal para que el equipo de producto pudiera accionar sin moderación adicional —síntesis breve, hallazgos accionables (no descriptivos), recomendaciones priorizadas por sprint.

Tradeoff: profundidad analítica por ronda a cambio de frecuencia continua. El valor no estaba en la robustez de cada estudio aislado: estaba en que el backlog de Twyp se actualizara cada viernes con evidencia fresca durante 12 semanas seguidas.

De la evaluación experta al ciclo semanal accionable

  1. 01

    Onboarding al UX Research Team

    Semanas 1–2. Formación en herramientas (UserZoom, formato de informes), shadowing de tests existentes.

    Entregable: integración operativa al programa de research.

  2. 02

    Análisis heurístico de Inversión Naranja

    Semanas 2–3. Evaluación experta sobre naming, jerarquía visual y arquitectura de información.

    Entregable: informe heurístico con hallazgos priorizados.

  3. 03

    Card sorting guerrilla de Inversión Naranja

    Semanas 3–4. 5 sesiones presenciales con perfiles internos, tarjetas físicas.

    Entregable: informe de card sorting (pre-test del estudio ampliado del equipo).

  4. 04

    Programa de tests semanales de Twyp

    Semanas 3–14, en paralelo. 4 sprints temáticos, ~60 tests no moderados, 4 informes de cierre de sprint.

    Entregables: Sprint Enviar dinero, Sprint TC-SMS-PIN, Sprint Descuentos 1, Sprint Descuentos 2.

  5. 05

    Contribución a estudios ampliados del equipo

    Semanas 6–12. Apoyo al card sorting con 15 participantes, tree testing con 120, recolección y análisis del programa SUS.

    Entregables (del equipo, con mi contribución): datos de tree testing, análisis SUS continuo.

  6. 06

    Síntesis y handoff

    Últimas semanas. Consolidación de recomendaciones al backlog y transferencia al UX Lead para continuidad post-pasantía.

Lo que el research entregó

01

Decisión de naming desbloqueada

La triangulación heurístico (mi ejecución) + card sorting guerrilla con 100% de acierto interno (mi ejecución) + card sorting ampliado con 40% en perfiles externos (equipo) construyó el argumento que llevó al equipo a rediseñar el naming de fondos desde la perspectiva del cliente.

02

Implementación selectiva en web comercial

El tree testing con 120 participantes evitó un rediseño en bloque. Mostró mejoras donde implementar (Seguros 31%→92%, Shopping 62%→93%) y una regresión que dejar intacta (Twyp 94%→80%). El equipo recomendó implementar solo las mejoras validadas.

03

Riesgo evitado en Twyp

Los tests semanales identificaron fricción estructural en el flujo de pago (tasa de éxito del 39%) y problemas de comprensión del cashback en usuarios no bancarizados, antes de llegar a producción a escala. Sin ese ritmo continuo, los patrones habrían pasado invisibles entre estudios trimestrales.

04

Recomendaciones adoptadas al backlog

El análisis heurístico de Inversión Naranja y los informes de los 4 sprints de Twyp se incorporaron al backlog de los equipos de producto correspondientes.

No tengo acceso a métricas de implementación post-pasantía. Las recomendaciones llegaron al backlog, pero no puedo reportar honestamente qué se implementó, cuándo ni con qué impacto medible en producción. Tampoco fui lead del tree testing de 120 participantes ni del think-out-loud A/B: fueron estudios del equipo en los que contribuí al análisis. La diferencia entre ejecución directa y contribución la mantengo explícita porque inflarla sería deshonesto y porque, en un caso de pasantía, la honestidad sobre el alcance es parte del valor.

Lo que aprendí entrando a research operativo desde fuera

Esta práctica fue mi entrada al research a escala empresarial, dentro de un área especializada que ya operaba con su propio modelo. La lección estructural fue entender cómo se triangula evidencia: el análisis heurístico señala qué validar; el card sorting verifica si los usuarios comprenden el sistema; el tree testing confirma si pueden navegar con éxito. Los tres juntos construyen un argumento que producto puede actuar con confianza. Ninguno por separado es suficiente.

El hallazgo del naming fue la lección más concreta. El 100% de los internos acertaba las categorías de fondos —dato que en aislamiento decía «el sistema funciona»—. Fue la comparación con el 40% de externos lo que reveló que el naming había sido diseñado desde la lógica del banco, no desde el cliente. Hoy nunca consideraría una muestra interna como evidencia: solo como hipótesis previa que necesita contraste externo para volverse argumento.

El research operativo es una disciplina distinta del research académico: cadencia, síntesis accionable y adopción al backlog importan más que el rigor por estudio aislado. Aprenderlo desde dentro de un equipo especializado en banca digital es lo que convierte estos 3 meses en experiencia real, no en un ejercicio de máster.


Siguiente caso de estudio

De un BMS legacy a un SaaS B2B: decisiones de diseño en un proyecto que no llegó a producción

Leer caso de estudio →