Preguntas de entrevista UX Designer

Mi proceso comienza con entender el problema antes de tocar cualquier herramienta de diseño. Empiezo con una fase de descubrimiento: revisar investigaciones existentes, entrevistar a las partes interesadas para alinear objetivos y restricciones, y hacer análisis competitivo si el tiempo lo permite. Luego paso a la investigación de usuarios para entender para quién diseño y qué necesitan realmente. Defino el problema claramente, a menudo con un enfoque "¿Cómo podríamos?", antes de pasar a la ideación. Bosquejo ampliamente y luego converjo en las direcciones más prometedoras para prototipar. Pruebo prototipos con usuarios reales lo antes posible para no descubrir problemas después de que ingeniería haya invertido. La entrega incluye especificaciones anotadas y casos límite documentados, y permanezco involucrado durante la implementación.

Trato las objeciones como información, no como oposición. Mi primer paso es entender qué impulsa la preocupación: a veces es una restricción legítima que desconocía, a veces es aversión al riesgo, y a veces es preferencia personal disfrazada de lógica de negocio. Distingo entre ellas. Para restricciones reales, adapto el diseño. Para la aversión al riesgo, propongo una prueba ligera. Para conflictos de preferencia personal, llevo la decisión de vuelta a la investigación de usuarios o a los datos. He aprendido a presentar las decisiones de diseño con la justificación desde el principio, lo que reduce la frecuencia de las objeciones. Cuando un stakeholder anula una decisión que creo incorrecta para los usuarios, documento mi preocupación y pido una métrica de seguimiento.

El éxito depende de lo que el diseño debía lograr, así que empiezo acordando métricas antes de comenzar a diseñar. Para flujos basados en tareas, hago seguimiento de la tasa de finalización y la tasa de error, primero mediante pruebas de usabilidad y luego con analytics en producción. Para objetivos de producto más amplios, conecto mi trabajo a métricas de negocio como conversión, retención o reducción de tickets de soporte. También hago seguimiento de señales cualitativas. Soy escéptico de métricas proxy como "tiempo en página" que pueden señalar tanto engagement como confusión. Después del lanzamiento, hago una revisión estructurada a los 30 y 90 días.

En una empresa anterior, me pidieron rediseñar un flujo de onboarding para móvil con dos semanas de plazo y sin presupuesto para investigación adicional. En lugar de empezar desde cero, extraje datos de analytics para identificar los tres pasos con mayor tasa de abandono y comparé el flujo existente con benchmarks competitivos. Realicé cinco pruebas guerrilla en la oficina con compañeros que coincidían con nuestro perfil de usuario. Centré mi rediseño en esas tres áreas problemáticas en lugar de renovar todo, lo que mantuvo el alcance manejable. La tasa de abandono en el paso crítico bajó un 18% en el primer mes. La restricción me obligó a ser más quirúrgico y orientado a datos.

Diseñé una nueva estructura de navegación para una app B2C en la que confiaba después de las pruebas internas. Tras el lanzamiento, los tickets de soporte sobre no poder encontrar funciones clave aumentaron un 30% la primera semana. No había probado suficientemente con usuarios que no conocían la navegación anterior. Alerté al equipo de inmediato. Realizamos una prueba de usabilidad de emergencia con cinco usuarios externos en 48 horas, que confirmó el problema e identificó dos puntos de fallo específicos. Lanzamos una corrección dirigida en una semana. La lección fue incluir siempre usuarios sin exposición previa en las pruebas de navegación, y ahora lo incorporo en mis protocolos por defecto.

Intento entender la preocupación antes de defender el diseño. Las objeciones de ingeniería suelen venir de tres lugares: inviabilidad técnica, esfuerzo que supera el valor percibido, o preferencia por una solución más simple. Los dos primeros son inputs legítimos que incorporo. Para problemas de viabilidad, pregunto qué es posible y rediseño dentro de esa restricción. Para preocupaciones de esfuerzo, pido una estimación y uso eso para decidir. He descubierto que involucrar a los ingenieros antes en el proceso, compartiendo hallazgos de investigación e invitándoles a definir el problema, reduce considerablemente la fricción posterior. Cuando no estamos de acuerdo, prefiero prototipar la interacción disputada y probarla.

Trato la accesibilidad como una restricción de diseño desde el principio, no como una lista de verificación al final. En la práctica, esto significa elegir combinaciones de colores que cumplan los ratios de contraste WCAG AA durante la fase de diseño, dimensionar los objetivos táctiles a al menos 44px y diseñar para la navegación por teclado junto al ratón. Uso estructura semántica en mis especificaciones para que los ingenieros sepan qué elementos corresponden a encabezados, botones o landmarks. En las pruebas de usabilidad, intento incluir al menos una sesión con un usuario que depende de tecnología de asistencia. He descubierto que diseñar de forma accesible generalmente produce una UX más limpia para todos.

Empiezo definiendo qué pregunta necesito que responda la prueba, porque el método sigue a la pregunta. Para pruebas evaluativas de un flujo específico, uso pruebas moderadas basadas en tareas con cinco a ocho participantes. Escribo las tareas en términos de resultados, no instrucciones: "Quieres encontrar el historial de pedidos" en lugar de "haz clic en el menú de cuenta". Uso el protocolo de pensamiento en voz alta para capturar el razonamiento. Noto hesitaciones, errores y caminos inesperados. Analizo agrupando observaciones entre participantes, buscando patrones. Presento hallazgos con niveles de severidad y recomendaciones priorizadas.

La fidelidad debe coincidir con la pregunta que intento responder. Para explorar si un concepto tiene sentido estructuralmente, un boceto rápido es más rápido y elimina el riesgo de que la gente reaccione al pulido visual en lugar de la interacción. Para probar microcopy específico o jerarquía visual, necesito suficiente fidelidad para que el texto y el layout estén cerca del final. Para presentaciones a stakeholders, la alta fidelidad reduce el esfuerzo cognitivo para imaginar el producto terminado. El error más frecuente es invertir en alta fidelidad demasiado pronto, antes de que la estructura esté validada, y luego tener que desechar trabajo pulido.