Talently
Talently
Diseñador UX

Diseñador UX

Diseña experiencias digitales que resuelven problemas reales de usuarios con criterio, evidencia y claridad.

Un UX Designer es responsable de comprender las necesidades, comportamientos y motivaciones de los usuarios para diseñar experiencias digitales que sean útiles, usables y significativas. Su trabajo abarca desde la investigación de usuarios y el mapeo de journeys hasta la creación de wireframes, prototipos y la validación con usuarios reales. Colabora estrechamente con Product Managers, UI Designers y equipos de desarrollo para garantizar que las decisiones de diseño estén fundamentadas en evidencia y sean técnicamente implementables. Su impacto se mide en la experiencia real del usuario, no en la estética de las pantallas.

FigmaDesign ThinkingInvestigación de usuariosPrototipadoUsabilidadAccesibilidad

Recluta al mejor Diseñador UX aquí

Empieza ahora

Responsabilidades Principales

  • •Planificar y ejecutar investigaciones de usuarios (entrevistas, tests de usabilidad, surveys) para fundamentar decisiones de diseño con evidencia.
  • •Definir y comunicar el problema de diseño antes de proponer soluciones, asegurando que el equipo resuelva el problema correcto.
  • •Crear flujos de usuario, wireframes y prototipos de distintos niveles de fidelidad según la fase del proyecto.
  • •Validar hipótesis de diseño con usuarios reales mediante tests de usabilidad y análisis de comportamiento.
  • •Colaborar con UI Designers y desarrolladores para garantizar que la implementación preserve la intención del diseño.
  • •Mantener y evolucionar el sistema de diseño y las guías de experiencia de usuario del producto.

Habilidades Clave

Technical Skills

  • Dominio de Figma para wireframing, prototipado interactivo y colaboración con equipos de producto y desarrollo
  • Métodos de investigación cualitativa: entrevistas en profundidad, tests de usabilidad moderados y no moderados, card sorting
  • Métodos de investigación cuantitativa: surveys, análisis de métricas de comportamiento, pruebas A/B en colaboración con Data
  • Diseño de flujos de usuario, arquitectura de información y mapas de experiencia del cliente (journey maps)
  • Principios de accesibilidad WCAG y técnicas de diseño inclusivo aplicadas desde la fase de wireframing
  • Herramientas de análisis de comportamiento: Hotjar, FullStory, Mixpanel o equivalentes para complementar la investigación cualitativa

Soft Skills

  • Empatía genuina con el usuario para distinguir entre lo que dicen que quieren y lo que realmente necesitan
  • Capacidad de defender decisiones de diseño con evidencia de usuario frente a opiniones no fundamentadas de stakeholders
  • Comunicación visual clara para presentar hallazgos de investigación e ideas de diseño a audiencias no diseñadoras
  • Apertura a la crítica y capacidad de separar el ego del trabajo para iterar basándose en feedback y evidencia
  • Pensamiento sistémico para diseñar soluciones coherentes a través de múltiples flujos y puntos de contacto del producto
  • Criterio para saber cuándo una investigación formal es necesaria y cuándo una validación rápida es suficiente para avanzar

Casos de uso reales

Contexto

El mayor desperdicio en el diseño de productos es construir la solución correcta para el problema equivocado. La investigación de usuarios temprana reduce ese riesgo.

Ejemplos reales

  • Entrevistas de descubrimiento para entender los jobs-to-be-done de los usuarios objetivo
  • Análisis competitivo y benchmarking de experiencias de referencia en el sector
  • Mapas de empatía y personas basados en investigación real, no en suposiciones del equipo
  • Definición del problema con How Might We statements derivados de los hallazgos de investigación

Contexto

Los flujos de alta consecuencia como onboarding, checkout o activación de features determinan las métricas clave del producto. Un diseño mal validado en estos flujos tiene impacto directo en conversión y retención.

Ejemplos reales

  • Diseño iterativo del flujo de onboarding con validación en cada etapa
  • Tests de usabilidad moderados en el flujo de pago con usuarios representativos
  • Análisis de drop-off en embudos con herramientas de analytics para identificar fricciones
  • Rediseño de flujos de recuperación de errores que frustran a los usuarios

Contexto

Productos con muchas features o contenido extenso requieren una estructura de información que permita a los usuarios encontrar lo que buscan sin esfuerzo cognitivo excesivo.

Ejemplos reales

  • Card sorting para validar modelos mentales de los usuarios sobre la organización del contenido
  • Tree testing para evaluar si la estructura de navegación propuesta es comprensible
  • Diseño de sistemas de navegación para productos con múltiples roles de usuario
  • Rediseño de la arquitectura de información de un producto con problemas de findability detectados en investigación

Contexto

El diseño accesible no es un checklist al final del proceso; es una mentalidad que amplía el alcance del producto y mejora la experiencia para todos los usuarios.

Ejemplos reales

  • Revisión de wireframes con lentes de accesibilidad antes de que lleguen a diseño visual
  • Diseño de alternativas textuales y flujos de navegación por teclado para componentes complejos
  • Tests de usabilidad con usuarios con discapacidades visuales, motoras o cognitivas
  • Definición de criterios de accesibilidad como parte de los criterios de aceptación de cada feature

Contexto

Un design system bien diseñado desde UX garantiza que los patrones de interacción sean consistentes y que las decisiones de usabilidad escalen a través de todo el producto.

Ejemplos reales

  • Definición de patrones de interacción reutilizables con documentación de cuándo y cómo usarlos
  • Auditorías de consistencia de experiencia para identificar patrones contradictorios en el producto
  • Colaboración con UI y desarrollo en la definición de componentes que equilibran flexibilidad y consistencia
  • Guías de escritura UX (UX writing) integradas al design system para mensajes de error, vacíos de estado y confirmaciones

Preguntas básicas

Investigación generativa al inicio: entrevistas y observación para entender el problema y los usuarios antes de diseñar. Investigación evaluativa en fases de diseño: tests de usabilidad para validar si la solución funciona. Métodos cualitativos para el 'por qué' (entrevistas, usability tests); cuantitativos para el 'qué tanto' (surveys, analytics). La elección también depende del tiempo y presupuesto disponibles: una guerrilla usability session de 2 horas puede ser más valiosa que semanas de análisis de datos.
Presentar con citas directas y videos de usuarios reales en lugar de resúmenes abstractos: ver a un usuario frustrado tiene más impacto que un porcentaje en una diapositiva. Conectar cada hallazgo con una métrica de negocio afectada. Incluir al equipo en la investigación cuando sea posible (observar las entrevistas) para que los hallazgos sean de todos, no solo del UX. Proponer hipótesis accionables junto a los hallazgos, no solo problemas sin solución propuesta.
Cruzar la frecuencia con la que el problema ocurre con el impacto que tiene en el usuario y en las métricas del negocio. Un problema que afecta al 80% de los usuarios en el flujo de checkout tiene prioridad sobre uno que afecta al 5% en una feature secundaria. Involucrar al product manager en la priorización para alinear el impacto de usuario con los objetivos del producto. Evitar priorizar problemas porque son los más visualmente notorios o los favoritos del equipo.
No confrontar opiniones con opiniones. Responder con evidencia: citas de entrevistas de usuarios, resultados de tests de usabilidad, benchmarks de industria o principios de usabilidad establecidos. Si no hay evidencia suficiente, proponer un test rápido que resuelva la duda antes de implementar. El argumento más efectivo no es 'tengo razón', sino 'aquí está la evidencia que fundamenta esta decisión; podemos testear la alternativa si hay duda'.
Baja fidelidad (wireframes, bocetos en papel) para explorar y comunicar flujos y estructuras de forma rápida cuando el concepto aún está en discusión. El bajo detalle visual focaliza el feedback en la estructura y el flujo, no en el color o la tipografía. Alta fidelidad cuando se necesita validar con usuarios cómo interactúan con el producto real, cuando se presenta a stakeholders para aprobación, o cuando sirve como especificación para el equipo de desarrollo.
Definir las métricas de éxito antes de implementar el rediseño, no después. Combinar métricas cuantitativas (tasa de completitud del flujo, tiempo en tarea, tasa de error) con cualitativas (satisfaction score, comentarios en tests post-lanzamiento). Comparar con la baseline del flujo anterior. Un A/B test en el lanzamiento permite atribuir el cambio en métricas al rediseño con mayor certeza que comparar períodos distintos con otras variables cambiando.
Primero hacer explícita la tensión para que el equipo la reconozca: no ignorarla ni resolverla unilateralmente. Explorar si existe un diseño que satisfaga ambos objetivos con algún compromiso aceptable. Si la tensión es real, presentar las opciones con las consecuencias de cada una: un patrón oscuro puede aumentar una conversión a corto plazo pero dañar la confianza y retención a largo plazo. La decisión final la toma el product manager con esa información, no el UX designer.
Preguntas sobre el contexto y los comportamientos actuales, no sobre el producto que se va a construir: ¿qué haces hoy cuando tienes este problema? ¿qué herramientas usas? ¿cuáles son las partes más frustrantes de ese proceso? ¿qué has intentado que no funcionó? Evitar preguntas hipotéticas ('¿usarías una app que hiciera X?') porque las respuestas no predicen el comportamiento real. El objetivo es entender el problema profundamente, no validar la solución que ya se tiene en mente.

Preguntas técnicas

Definir las tareas específicas que el usuario debe completar, alineadas con los pasos críticos del flujo. Reclutar participantes que representen al usuario objetivo real. Moderar sin guiar: dar el contexto mínimo y observar sin intervenir hasta que el participante se bloquee completamente. Medir: tasa de completitud por tarea, tiempo por tarea, número de errores y satisfaction post-test. Cinco participantes detectan el 85% de los problemas de usabilidad según Nielsen. Presentar los hallazgos con vídeo de las sesiones para maximizar el impacto en el equipo.
Proximidad: agrupar elementos relacionados espacialmente para que el usuario los perciba como unidades. Similitud: usar el mismo estilo visual para elementos con la misma función. Figura-fondo: garantizar suficiente contraste para que el contenido principal se distinga del fondo sin esfuerzo. Continuidad: alinear elementos en líneas o curvas para guiar la atención. Cierre: los usuarios completan formas incompletas; útil para indicadores de progreso o íconos simplificados. Aplicar estos principios sistemáticamente reduce la carga cognitiva sin necesidad de añadir texto explicativo.
Mapear por separado los flujos y necesidades de información de cada rol antes de diseñar la navegación. Identificar qué funcionalidades son comunes y cuáles son exclusivas por rol. Evaluar si la solución es una navegación adaptiva (misma estructura con contenido filtrado por rol) o experiencias separadas por rol. Validar con card sorting y tree testing por segmento de usuario, no con un solo test general. La arquitectura de información correcta para un administrador puede ser completamente incorrecta para un usuario final.
Especificaciones claras en Figma con anotaciones de comportamiento, no solo de apariencia: qué pasa al hacer hover, al hacer focus, al haber un error, con datos vacíos, con textos muy largos. Entregar los flujos completos incluyendo los estados edge (empty state, error state, loading state) que frecuentemente se omiten. Participar en la revisión de la implementación antes del merge con una checklist de criterios de experiencia. Reportar discrepancias como bugs de UX con el mismo peso que los bugs funcionales.
Los datos cuantitativos (funnels, heatmaps, session recordings, eventos de click) muestran dónde ocurren los problemas y con qué frecuencia. Los cualitativos (entrevistas, tests de usabilidad) explican por qué ocurren. El flujo de trabajo más efectivo: analytics identifica que hay un drop-off alto en un paso del funnel; la investigación cualitativa explica si es por confusión en el diseño, por un problema de carga de datos, o por una expectativa no satisfecha. Los dos métodos se necesitan mutuamente para diagnósticos accionables.
Validar inline en tiempo real (no solo al submit) para que el usuario corrija mientras escribe, no después de perder todo el progreso. Mostrar el error junto al campo que lo contiene, nunca solo al principio del formulario. El mensaje de error debe explicar qué pasó y cómo corregirlo, nunca solo 'campo inválido'. Preservar todos los valores válidos cuando hay errores; nunca limpiar el formulario completo. Para formularios largos, mostrar un resumen de errores al inicio y links a cada campo con problema.
Hacer un recorrido de los flujos principales como usuario nuevo sin ayuda del equipo, anotando fricciones y confusiones. Revisar la consistencia: ¿los mismos patrones de interacción se usan para las mismas acciones en todo el producto? ¿El lenguaje es consistente? Verificar los estados edge: empty states, error states, estados de carga. Contrastar el diseño con los principios heurísticos de Nielsen. Si existen, revisar los resultados de investigación y métricas anteriores. Este diagnóstico debe generar un mapa de deuda de UX priorizado, no una lista de preferencias estéticas.
No adaptar el desktop al mobile como afterthought: diseñar primero el mobile considerando las restricciones de pantalla, el contexto de uso en movimiento y la interacción táctil. En desktop, aprovechar el espacio adicional para densidad de información y acciones adicionales que en mobile serían ruido. Los flujos pueden ser distintos entre plataformas si los contextos de uso lo justifican: un usuario que completa una tarea larga en desktop puede hacer una consulta rápida en mobile del mismo producto. Validar ambas experiencias con usuarios reales en cada plataforma.

Preguntas avanzadas

Separar la investigación de descubrimiento (trimestral, más profunda) de la investigación evaluativa continua (semanal, más ligera). Mantener un panel de usuarios disponibles para tests rápidos no moderados (Maze, UserTesting) que pueden ejecutarse en días. Integrar micro-investigación en el flujo de diseño: 5 tests de usabilidad de 30 minutos cada dos semanas son más sostenibles que un estudio masivo cada seis meses. Compartir los hallazgos en un repositorio centralizado (Dovetail, Notion) para que todo el equipo acumule conocimiento sobre los usuarios sin repetir investigación.
Conectar cada iniciativa de UX con una métrica de negocio: reducción del tiempo de onboarding, aumento de la tasa de activación, reducción de tickets de soporte por confusión en la interfaz. Documentar el estado antes y después de cada rediseño con datos. Para justificar investigación preventiva: calcular el costo de un bug de UX en producción (tiempo de desarrollo para corregirlo multiplicado por el número de usuarios afectados) versus el costo de un test de usabilidad que lo detecta antes de implementar. La investigación temprana es sistemáticamente más barata que el rediseño tardío.
Diseñar capas de revelación progresiva: la interfaz muestra las acciones más comunes por defecto y revela complejidad adicional a medida que el usuario la necesita o la busca. Separar los flujos de onboarding del flujo habitual del usuario experto para no infantilizar la experiencia de quienes ya conocen el producto. Proveer atajos de teclado, comandos avanzados y customización para usuarios expertos que coexisten con la interfaz guiada para nuevos. Validar con usuarios de ambos perfiles por separado: lo que es obvio para un experto es opaco para un nuevo usuario.
No rediseñar todo a la vez: identificar las áreas con mayor deuda de UX y mayor impacto en métricas. Involucrar a usuarios actuales en el proceso de diseño: no como validadores pasivos sino como co-diseñadores que aporten su conocimiento del producto. Comunicar los cambios con anticipación y ofrecer períodos de transición donde ambas versiones coexisten. Medir el impacto en métricas de adopción y satisfacción en cada fase para poder ajustar. Los usuarios resisten los cambios no por irracionalidad sino porque han invertido tiempo en aprender el sistema actual; ese conocimiento debe respetarse en el diseño de la transición.
No confrontar la intuición directamente: en las etapas tempranas de un producto, la intuición del fundador frecuentemente tiene más contexto de negocio que el UX designer recién llegado. Construir credibilidad gradualmente: ejecutar investigaciones pequeñas que generen insights sorprendentes que el equipo no tenía. Hacer visible la voz del usuario en reuniones con citas directas y clips de video. Proponer incluir al fundador en una sesión de investigación como observador: ver directamente a usuarios confundidos es más persuasivo que cualquier presentación. La cultura de diseño centrado en el usuario se construye con victorias concretas, no con frameworks.
Auditar el producto sistemáticamente con heurísticas de Nielsen y tests de usabilidad con usuarios reales para obtener una imagen objetiva del estado actual. Clasificar la deuda en: crítica (bloquea tareas importantes), significativa (genera fricción frecuente), cosmética (inconsistencias que no afectan la usabilidad). Construir un backlog de deuda de UX priorizado con impacto estimado y costo de resolución. Negociar con el product manager que un porcentaje del capacity de cada sprint se dedique a reducir deuda, como se haría con deuda técnica. Sin esa negociación explícita, la deuda de UX siempre perderá frente a nuevas features.

Errores comunes en entrevistas

Los entrevistadores de UX evalúan cómo piensa el candidato, no cómo dibuja. Un portfolio que muestra pantallas bonitas sin explicar qué problema resolvían, qué investigación las fundamentó, qué alternativas se consideraron y cómo se validaron demuestra que el candidato es un pixel pusher, no un UX designer.
Cada decisión de diseño debe poder justificarse con evidencia de usuario, principios de usabilidad o datos de comportamiento. Las opiniones estéticas no son fundamentos de diseño. Los entrevistadores técnicamente sólidos en UX siempre preguntan 'por qué' hasta encontrar el fundamento real de cada decisión.
Los happy paths son la parte fácil del diseño. Los estados edge (¿qué pasa cuando no hay datos? ¿cuándo falla una acción? ¿cuándo el texto es demasiado largo?) son donde la mayoría de los problemas de usabilidad real se esconden. Un candidato que presenta solo el flujo ideal demuestra que no ha pensado en el producto como un sistema completo.
La opinión del CEO sobre el diseño no es investigación de usuarios, incluso si el CEO también es usuario del producto. Los stakeholders tienen sesgos, conocimiento del producto y objetivos que los usuarios reales no tienen. Mezclar ambas fuentes de feedback produce decisiones de diseño que satisfacen al equipo interno pero no a los usuarios.
Un rediseño completo es costoso, riesgoso y raramente necesario. Proponer rediseños extensos ante problemas específicos demuestra falta de criterio para calibrar la solución al tamaño del problema. Frecuentemente, cambios quirúrgicos en los puntos de mayor fricción generan más impacto con menor riesgo y menor costo.
Un diseño que no tiene métricas de éxito definidas es un diseño que nunca sabrá si funcionó. Los entrevistadores de empresas orientadas a datos preguntan siempre qué pasó con el producto después del rediseño. No poder responder con datos concretos, aunque sean cualitativos, genera dudas sobre si el candidato trabaja con una mentalidad de impacto o solo de entrega.

Las mejores oportunidades de trabajo para Diseñador UX

Todas las ofertas de internet en un solo lugar

Aunahace 3 semanas

Service Designer

¡Gran oportunidad como UX Designer! Se requiere conocimientos en User Research, Prototipado, Problem solving, Comunicación asertiva.

$3,000 - $3,100/mes Hibrido Inglés intermedio