Preguntas de entrevista para Diseñador UX

Respuesta modelo

En una entidad financiera con unos 2,3 millones de clientes digitales, el alta de cuenta online tenía una tasa de finalización del 51 %, y negocio lo atribuía al precio. Empecé por los datos que ya existían: en el embudo de GA4 vi que el 60 % de las caídas se concentraban en el paso de verificación de identidad, y en las grabaciones de sesión de Hotjar se veía a gente repitiendo la foto del DNI tres y cuatro veces. Con esa hipótesis planteé un estudio mixto: 21 entrevistas en profundidad con personas que habían abandonado en los últimos treinta días, reclutadas con un cuestionario de cribado para cubrir tres perfiles de edad y dos niveles de familiaridad digital, y cuatro rondas de test moderado con 32 participantes en total sobre el flujo real. El hallazgo central no era el precio: era que nadie entendía por qué se rechazaba la foto ni qué debía corregir, porque el mensaje de error era genérico. Rediseñé el proceso en tres pasos con guardado automático, una guía visual de encuadre en vivo y errores específicos por causa; el equipo de UI se encargó de los estados y de los componentes definitivos del sistema de diseño y yo entregué los flujos, los criterios de accesibilidad y el guion de validación. Ocho semanas después de publicar, la finalización subió al 74 % y las llamadas al centro de soporte relacionadas con la verificación cayeron un 38 %. Lo que más me gustó del proyecto no fue el resultado, sino que sirvió para dejar de discutir sobre opiniones: a partir de ahí, cada trimestre se reserva presupuesto para investigar antes de decidir.

Respuesta modelo

Parto de la pregunta que hay que responder y del tipo de incertidumbre. Si la incertidumbre es sobre el problema o sobre el contexto —qué necesita la gente, cómo lo resuelve hoy, qué le frena—, uso métodos cualitativos y generativos: entrevistas en profundidad, contextual inquiry cuando puedo observar el trabajo real, diarios de uso si el fenómeno se reparte en el tiempo. Si la incertidumbre es sobre una solución concreta que ya existe o está prototipada, uso métodos evaluativos: test de usabilidad moderado cuando necesito entender el porqué y ver dónde se bloquean, y test no moderado en Maze o Lyssna cuando necesito volumen y una comparación entre dos alternativas. Si la incertidumbre es sobre la estructura y la nomenclatura, card sorting para construir la taxonomía y tree testing para validar que la estructura propuesta se puede recorrer. Y si lo que hay que medir es magnitud —cuánta gente, cuánto porcentaje, qué diferencia—, entonces analítica, encuesta con muestra suficiente o test A/B, nunca cinco entrevistas. También pesa mucho la restricción real: presupuesto, plazo y acceso a usuarios. Si no puedo reclutar clientes reales por una restricción legal, lo digo y propongo la alternativa más cercana, por ejemplo empleados de atención al cliente que hablan con esos usuarios cada día, dejando claro qué validez tiene y qué no.

Respuesta modelo

Defino la métrica antes de diseñar, no después, y siempre uso al menos una de comportamiento y una de percepción. En el rediseño del onboarding de un SaaS para pymes, la métrica principal era la activación a los siete días —la definimos como haber creado la primera nómina— y las secundarias eran el tiempo hasta esa primera acción, la tasa de éxito de tarea en el test y la puntuación SUS del producto. Antes de tocar nada tomé la línea base: 34 % de activación y un SUS de 62 con 40 respuestas. Después de publicar, medí a las cuatro y a las ocho semanas para no leer el pico de novedad: 52 % de activación y SUS de 81. También vigilo las métricas de guardarraíl, las que no deben empeorar: en ese caso, los tickets de soporte y la tasa de cancelación en el primer mes. Y cuando el volumen no da para significación estadística, algo habitual en productos B2B, lo digo con honestidad y me apoyo en indicadores de usabilidad medidos en test con tareas idénticas antes y después, que es una comparación válida aunque la muestra sea pequeña.

Respuesta modelo

En una plataforma de viajes, dirección quería un mapa 3D de la zona en la ficha de alojamiento; la hipótesis era que ayudaría a decidir y estaba estimado en unos cuatro meses de equipo. Yo tenía mis dudas, pero también mi propio sesgo, así que planteé una prueba barata antes de que se aprobara: un prototipo de baja fidelidad con el mapa simulado, 18 entrevistas y una tarea concreta —elegir entre dos alojamientos en una ciudad que no conocían—. Nadie usó el mapa espontáneamente; los que lo abrieron a petición mía lo cerraron en menos de veinte segundos. Lo que sí aparecía una y otra vez era la distancia a un punto de interés concreto y el tiempo real de transporte, que ya teníamos pero enterrado en una pestaña. Presenté los resultados con tres vídeos de treinta segundos, sin comentarios míos por encima, y una tabla de qué pidió cada participante. No dije «el mapa es mala idea»; dije «esto es lo que hemos observado, y esta es la alternativa que cuesta dos semanas». Se paró el mapa, se subió la información de distancia y transporte a la parte alta de la ficha y la conversión de búsqueda a ficha subió un 12 %. Aprendí que la forma de presentar importa tanto como el hallazgo: los clips de usuarios reales convencen donde un informe de veinte páginas solo genera discusión.

Respuesta modelo

Yo respondo de qué problema se resuelve y de si la solución funciona; el perfil UI responde de cómo se ve y de que la interfaz sea coherente. En la práctica eso significa que yo aporto la investigación, los flujos, la arquitectura de la información, los prototipos con los que valido y los criterios de éxito y de accesibilidad, y el equipo de UI aporta la jerarquía visual, los componentes, los tokens, los estados y la integración en el sistema de diseño. Trabajamos juntos desde el principio: llevo a mi compañero de UI a las sesiones de test, porque ver a un usuario bloquearse ahorra tres reuniones de discusión. Con el Product Manager la frontera es distinta: él decide la prioridad y yo aporto la evidencia con la que se decide. Le llevo hallazgos y opciones con su coste aproximado; la decisión final sobre la hoja de ruta es suya y me parece correcto que así sea, siempre que la conversación se tenga con datos encima de la mesa. En equipos pequeños, que en España son muchos, asumo también parte del trabajo de interfaz apoyándome en el sistema de diseño existente, pero lo digo con claridad en lugar de aparentar que soy especialista visual.

Respuesta modelo

Reduzco el alcance, no el rigor. Lo primero es preguntar qué decisión concreta depende de la respuesta y qué pasa si nos equivocamos: si el coste del error es bajo y reversible, muchas veces la respuesta honesta es que no hace falta investigar y se lanza detrás de una bandera de funcionalidad para medir. Si el coste es alto, busco la versión mínima del estudio. Suelo tener a mano tres formatos: cinco tests moderados de treinta minutos, que se organizan en dos días y detectan la mayoría de los problemas graves de usabilidad; un test no moderado en Maze con cincuenta participantes, que en 48 horas da tasas de éxito y tiempos sobre dos alternativas; y una hora de escucha de llamadas grabadas de atención al cliente, que no cuesta nada y suele ser la fuente de hallazgos más infravalorada de cualquier empresa. También aprovecho lo que ya existe antes de generar nada nuevo: analítica, buscador interno, tickets de soporte, reseñas de las tiendas de aplicaciones. Y si aun así no hay margen, dejo escrito el riesgo asumido y la hipótesis que no se ha comprobado, para poder volver a ella cuando aparezcan los datos de uso.

Respuesta modelo

Rediseñé la arquitectura del área privada de un producto financiero apoyándome en un card sorting con 84 participantes bien reclutados y un tree testing con resultados muy buenos: el acierto de localización pasó del 58 % al 89 % en la prueba. Al publicar, las quejas se dispararon durante tres semanas. El error fue mío: había optimizado la estructura para alguien que llega por primera vez y no había estudiado a los clientes veteranos, que tenían automatizado el recorrido y no querían encontrar nada, querían repetirlo. No hicimos ninguna prueba con usuarios de más de dos años de antigüedad y no preparamos ninguna transición. Lo corregimos con una capa de accesos recientes y un aviso de una sola vez que señalaba dónde estaba ahora cada cosa, y a las seis semanas las quejas volvieron a la línea base y el acierto se mantuvo alto. Desde entonces incluyo siempre el segmento de usuarios expertos en el reclutamiento cuando toco una estructura existente, y trato el cambio como parte del diseño y no como un asunto de comunicación posterior.

Depende de para qué. Para un test cualitativo y moderado, cinco participantes por perfil detectan la gran mayoría de los problemas graves de usabilidad y por eso prefiero hacer tres rondas de cinco a lo largo del proyecto en lugar de una sola de quince: cada ronda corrige y vuelve a probar. Lo importante es «por perfil»: si el producto tiene dos segmentos que se comportan distinto, por ejemplo el cliente nuevo y el cliente veterano, necesito cinco de cada uno, y ese fue el error que cometí una vez y no repito. Cuando lo que busco no son problemas sino medición —comparar dos alternativas, dar una tasa de éxito con intervalo de confianza, establecer una línea base—, cinco personas no valen: ahí necesito un test no moderado con entre 40 y 60 participantes por variante, o directamente un test A/B con tráfico real si el volumen lo permite. La regla que aplico es simple: descubrir problemas es cualitativo y necesita pocos participantes bien elegidos; afirmar cuánto es cuantitativo y necesita muestra.

El card sorting es generativo y sirve para construir: doy al participante los contenidos y le pido que los agrupe y les ponga nombre. En la modalidad abierta las categorías las crea el usuario, lo que va bien para descubrir modelos mentales y vocabulario; en la cerrada las categorías las doy yo y sirve para validar una taxonomía candidata. El tree testing es evaluativo y sirve para comprobar: presento la estructura en texto, sin diseño ni buscador, y pido que localicen algo concreto; obtengo tasa de acierto, ruta seguida y en qué nivel se produce el abandono. Los uso en ese orden y con esa lógica: primero card sorting para diseñar la estructura y la nomenclatura, después tree testing para verificar que se recorre, y solo entonces paso a wireframes. Lo hago normalmente en Optimal Workshop, con entre 30 y 50 participantes en el card sorting y 60 o más en el tree testing, que al ser cuantitativo agradece muestra. La ventaja del tree testing es que aísla la estructura del diseño visual: si falla ahí, ningún acabado de interfaz lo va a salvar.

El SUS es un cuestionario estandarizado de diez afirmaciones con escala de acuerdo de cinco puntos que devuelve una puntuación de 0 a 100. No es un porcentaje: es una puntuación relativa a una base de referencia amplia en la que la media se sitúa alrededor de 68. Por debajo de 51 hablamos de un producto con problemas serios de usabilidad percibida; por encima de 80 estamos en un rango claramente bueno. Su valor real no está en la cifra aislada, sino en la comparación: el mismo producto antes y después de un rediseño, o dos alternativas medidas con las mismas tareas previas. Lo aplico siempre al final de una sesión de test, después de que la persona haya intentado tareas reales, nunca como encuesta suelta enviada por correo, porque entonces mide recuerdo y simpatía en lugar de experiencia. Y no lo confundo con el NPS, que mide disposición a recomendar y depende de precio, marca y atención al cliente: un NPS alto puede convivir perfectamente con un flujo de alta que la gente no consigue completar.

Escribo las tareas en el lenguaje del usuario y no en el de la interfaz. Nunca digo «pulse el botón de transferencias y envíe 50 euros»; digo «tiene que devolverle 50 euros a un amigo que le adelantó la cena; hágalo como lo haría normalmente». Ahí está la clave: si la tarea contiene la palabra que aparece en el menú, ya he resuelto el problema que quería medir. Evito las preguntas hipotéticas del tipo «¿usaría esta funcionalidad?», porque la gente predice fatal su propio comportamiento, y las sustituyo por preguntas sobre hechos: «¿cuándo fue la última vez que necesitó hacer esto y qué hizo?». Durante la sesión mantengo silencio mientras la persona trabaja, respondo a sus preguntas con otra pregunta neutra —«¿qué esperaría que pasara?»— y no rescato a nadie antes de que lo pida explícitamente, porque el momento de bloqueo es justo el dato que busco. Al final agradezco tanto lo negativo como lo positivo, y en las entrevistas dejo el guion abierto: preparo entre seis y ocho preguntas y me permito seguir lo que aparezca, que suele ser lo más valioso.

Un test A/B me dice qué alternativa gana, pero no por qué; un test de usabilidad me dice por qué falla algo, pero no cuánto afecta al conjunto. Uso A/B cuando tengo dos soluciones razonables, una métrica clara y suficiente tráfico para alcanzar significación en un plazo asumible; en productos B2B con pocos miles de usuarios muchas veces no es viable y forzarlo produce conclusiones falsas. Uso test de usabilidad cuando quiero entender el mecanismo del problema o cuando la solución todavía no existe y la estoy probando en prototipo, antes de gastar desarrollo. En la práctica los combino: primero investigo y testo para llegar a una alternativa que merezca la pena construir, y después mido en producción con A/B o con un despliegue progresivo. Lo que nunca hago es lanzar un A/B entre dos ideas que nadie ha probado con usuarios: sale caro y, gane la que gane, sigo sin saber qué mejorar en la siguiente iteración.

Es una revisión experta de una interfaz contrastada con un conjunto de principios, normalmente las diez heurísticas de Nielsen —visibilidad del estado del sistema, correspondencia con el mundo real, control y libertad, consistencia, prevención de errores, reconocer antes que recordar, flexibilidad, diseño minimalista, ayuda para reconocer y recuperarse de errores, y documentación—. La hago con dos o tres evaluadores por separado y después consolidamos, porque una sola persona detecta bastante menos y arrastra sus propios sesgos; cada incidencia se documenta con captura, heurística incumplida y severidad. Es rápida y barata, y sirve muy bien como diagnóstico inicial cuando entro en un producto que no conozco o cuando no hay presupuesto inmediato para reclutar. Su límite es evidente y conviene decirlo en voz alta: es la opinión informada de un experto, no evidencia de usuario. Detecta infracciones de principio que a lo mejor a nadie le molestan y no detecta problemas de vocabulario, de modelo mental o de contexto de uso, que solo aparecen observando a personas reales. Por eso la presento siempre como una lista de hipótesis priorizadas que hay que verificar, nunca como conclusiones.

Con cuatro cosas que ya tengo sistematizadas. Primero, consentimiento informado por escrito antes de la sesión, en el que se explica la finalidad, quién verá la grabación, cuánto tiempo se conserva y cómo se ejercen los derechos; si va a haber grabación de pantalla o de imagen, se dice explícitamente y se pide de forma separada. Segundo, minimización: no pido datos personales que no necesito para el estudio y no grabo pantallas con datos reales de terceros; en banca trabajo con entornos de pruebas o con datos enmascarados. Tercero, conservación limitada y almacenamiento en las herramientas aprobadas por la empresa, con acceso restringido al equipo del estudio y transcripciones anonimizadas en el repositorio de Dovetail, que es lo que después consulta el resto de la organización. Y cuarto, coordinación con el delegado de protección de datos antes de arrancar cualquier estudio nuevo, sobre todo si intervienen menores, datos de salud o clientes de sectores regulados. También aplico la parte que no es legal sino ética: derecho a parar la sesión en cualquier momento sin dar explicaciones y compensación proporcionada al tiempo del participante.

Significa cosas muy concretas que se deciden en el diseño y no se pueden parchear al final. Cada campo lleva una etiqueta visible y asociada de forma programática, no un texto de marcador de posición que desaparece al escribir. El contraste del texto llega al menos a 4,5:1 y el de los elementos de interfaz y del foco a 3:1. El foco del teclado siempre es visible y no queda tapado por cabeceras fijas ni por barras de cookies, que es el fallo que más veo. Los errores se identifican en texto, no solo con color, se describen en concreto —«el IBAN debe tener 24 caracteres»— y se anuncian a los lectores de pantalla. El objetivo táctil tiene un tamaño suficiente y no depende de gestos complejos, y no se pide reintroducir información que el usuario ya ha dado en el mismo proceso. El recorrido completo tiene que poder hacerse con teclado y sin límite de tiempo arbitrario. Yo entrego estos criterios junto al flujo y los valido con axe y con recorridos por teclado, además de pruebas con NVDA; en España esto ha dejado de ser opcional en muchos sectores desde que la Ley 11/2023 aplica al comercio electrónico, la banca y el transporte, y con la UNE-EN 301 549 y el Real Decreto 1112/2018 ya vigentes en el sector público.

El flujo de usuario es la secuencia de pantallas y decisiones dentro del producto: sirve para diseñar y para hablar con desarrollo, y es el que entrego junto a los criterios de interacción. El journey map es más ancho y más humano: recorre la experiencia completa desde antes de entrar en el producto hasta después de salir, incluye canales que no controlo —el anuncio, la llamada al centro de atención, el correo de confirmación, la oficina física— y añade capas de acciones, pensamientos, emociones y puntos de dolor, siempre construidas con datos de investigación y no en una sala con post-its. El service blueprint añade lo que hay por debajo de la línea de visibilidad: los procesos internos, los sistemas y las personas que hacen posible cada momento del recorrido; es la herramienta que uso cuando el problema no está en la interfaz sino en la operación, por ejemplo cuando un plazo de verificación de tres días arruina una experiencia que en pantalla es impecable. Como regla, el flujo lo hago siempre, el journey map cuando hay varios canales implicados y el blueprint cuando la solución exige cambiar procesos internos y necesito alinear a áreas que no son producto.

No planteo la conversación como investigar o no investigar, sino como qué riesgo estamos asumiendo. Lo primero es acotar: de todo el flujo, cuál es el paso donde un error sería más caro y menos reversible; normalmente es uno solo. Con eso propongo la versión mínima que cabe en el plazo: cinco tests moderados de treinta minutos sobre ese paso, organizados en dos días con participantes reclutados entre clientes que ya tenemos identificados o, si no da tiempo, un test no moderado en Maze que en 48 horas devuelve tasas de éxito con cincuenta personas. Es un coste de dos o tres días de mi tiempo, no del plazo del equipo. En paralelo preparo la medición para después del lanzamiento: eventos en analítica para ese paso concreto, un umbral de alerta y un plan de reversión. Y dejo escrito en el ticket qué hipótesis no se ha validado. Si aun así no hay margen, lanzamos con un despliegue progresivo al 10 % del tráfico durante los primeros días, que es la forma más barata de convertir una apuesta en un experimento controlado.

No la rechazo en la reunión ni la acepto sin más. Lo que hago es convertir la petición en una pregunta que se pueda responder: le pregunto qué problema cree que resuelve y qué esperaría que mejorara si la tuviéramos, y así la conversación pasa de la solución al objetivo. Después miro lo que ya sabemos: si tenemos investigación, analítica o tickets de soporte que hablen de ese problema, lo llevo a la siguiente reunión. Si no tenemos nada, propongo la comprobación más barata posible con plazo cerrado —un prototipo simulado en cinco tests, o una prueba de humo con una tarjeta de acceso que mide si alguien la pulsa— y me comprometo a una fecha. Casi siempre funciona, porque nadie se opone a un experimento de dos semanas y en cambio todo el mundo se atrinchera si le dicen que su idea es mala. Y si la evidencia acaba dándole la razón, lo digo con la misma claridad con la que diría lo contrario: eso es lo que hace que la próxima vez me dejen investigar antes.

Lo primero, no promedio. Con cinco personas no hay estadística, así que lo que hago es buscar el patrón detrás de las diferencias: reviso las características de reclutamiento de cada uno, si es la primera vez que usan el producto, su nivel de familiaridad con el dominio, el dispositivo y si venían con un objetivo propio o con el mío. Muchas veces la ambigüedad desaparece en cuanto se cruza con el segmento: los dos que completaron eran usuarios veteranos y los tres que se bloquearon eran nuevos, y entonces el problema está claro y además he descubierto que necesito segmentar el estudio. Si el patrón no aparece, la conclusión honesta es que no tengo respuesta y lo digo así, sin adornarlo: añado dos o tres sesiones más dirigidas al perfil que menos cubierto está, o cambio a un método cuantitativo si lo que necesito es saber cuánta gente se ve afectada. Lo que nunca hago es presentar «tres de cinco tuvieron problemas» como si fuera un 60 % de los usuarios: esa cifra no existe y quien la escucha la va a repetir en un comité.

El primer mes lo dedico a recoger lo que ya existe sin pedir presupuesto a nadie. Uso el producto a fondo y documento una evaluación heurística con severidades; leo tickets de soporte de los últimos seis meses y las reseñas de las tiendas de aplicaciones; escucho llamadas grabadas de atención al cliente y me siento con el equipo comercial y con soporte, que son quienes hablan con los usuarios todos los días y a quienes casi nadie pregunta; reviso el buscador interno, que suele ser la lista de necesidades no cubiertas mejor ordenada de la empresa. Con eso construyo un mapa de problemas priorizado por frecuencia e impacto. El segundo mes lo dedico a demostrar el valor con algo pequeño y visible: elijo un problema acotado, hago cinco tests, propongo un cambio, lo publicamos y lo medimos. Un resultado modesto pero medido a las seis semanas abre más puertas que cualquier presentación sobre la importancia de la investigación. El tercer mes lo dedico a dejar infraestructura: un panel de participantes con consentimiento, un repositorio de hallazgos, eventos mínimos en analítica y una cadencia quincenal de sesiones con usuarios en el calendario del equipo, para que investigar deje de ser un proyecto y pase a ser una rutina.

Voy a verlo con la pantalla delante y le pido que me explique dónde está el coste, porque casi nunca es todo el diseño: suele ser un detalle concreto, una animación, una validación en tiempo real o una llamada a un sistema antiguo. Una vez identificado, la pregunta que hago es qué parte del beneficio se pierde si eso no está, y ahí es donde sirve haber definido antes el criterio de éxito: si el objetivo era reducir el error en el campo del IBAN, la validación en tiempo real es el corazón de la solución y merece pelear por el plazo; si era estético, se cae sin discusión. Normalmente salimos con una versión intermedia que conserva el mecanismo y simplifica la ejecución. Y lo que intento siempre es que esto ocurra antes: llevo a alguien de desarrollo a las sesiones de test y comparto los flujos en cuanto son legibles, no cuando están perfectos, porque las sorpresas a mitad de sprint casi siempre son un fallo mío de comunicación temprana.