Resumen ejecutivo

• Un case study UX que un recruiter entiende en dos minutos cuenta historia: problema → usuarios → tu rol → proceso → decisiones difíciles → resultado medible → aprendizajes.

• Nielsen Norman Group recomienda case studies escaneables con el “proceso sucio”, no solo pantallas finales: hipótesis, colaboración, iteraciones y lo que descartaste.

• Plantilla lista para copiar (web o PDF) y errores que hacen que te descarten aunque el diseño sea lindo.

• Si todavía estás armando el portafolio desde cero, enlazá este artículo con la guía de portafolio UX/UI sin experiencia laboral.

Tu portafolio no se lee como una novela: se escanea en el celular entre entrevistas. Si cada proyecto es un dump de mockups sin contexto, el recruiter no entiende qué hiciste vos ni qué valor generaste. Acá vas a armar un case study con la estructura que buscan quienes contratan UX, basada en lo que Nielsen Norman Group resume en su guía de portfolios y en la estructura de How to Write a UX Case Study: mostrar cómo partiste de una oportunidad y produciste valor real para usuarios y negocio, incluyendo lo que no quedó en el diseño final. ¿Por qué ahora? Porque ya hay guías de cómo armar el portafolio, pero falta la pieza de documentar cada caso con el nivel de detalle que pasa el filtro de un hiring manager. Si todavía no tenés el contenedor, arrancá por cómo armar un portafolio de UX/UI sin experiencia laboral.

Qué mira un recruiter en 120 segundos

En la investigación de NN/G con profesionales de UX a cargo de hiring, aparecen pedidos muy concretos: “mostrame cómo empezaste con una oportunidad y generaste valor”, “quiero saber qué no está en el diseño y por qué”, “no me muestres solo el producto terminado: el proceso, las restricciones, el timeline y cómo la research informó el diseño”. Traducción práctica: tu case study es un producto para un usuario llamado hiring manager. Tiene que ser escaneable, con jerarquía clara y sin relleno.

Antes de escribir, definí las tres cosas que esa persona debería recordar de vos (por ejemplo: research + prototipado + impacto en métricas). Después chequeá que el case study las entregue en el primer pantallazo.

Estructura del case study: problema, proceso, decisión y resultado

1. Problema o hipótesis (arriba de todo)

Una o dos frases: qué dolor había, para quién y por qué importaba al negocio. Ejemplo al estilo NN/G: “La app recibía reviews negativas porque la gente no recibía alertas de ofertas; hipotetizamos que no sabían que podían ajustar notificaciones”.

2. Rol, equipo y restricciones

Decí qué hiciste vos (sole UX, research + UI, etc.), con quién colaboraste y bajo qué límites (deadline, NDA, stack, marca). Sin esto, el recruiter no puede proyectarte en su equipo.

3. Usuarios e insights

Quiénes son, cómo los investigaste (entrevistas, tests, analytics) y qué aprendiste que cambió el diseño. Acá ayuda linkear conceptos de research; si querés tools, mirá UX Research con IA: herramientas para investigar más rápido.

4. Proceso e iteraciones (el “messy middle”)

Flujos, wireframes, prototipos, tests. Mostrá 2–3 iteraciones con caption: qué probaste, qué falló, qué cambió. NN/G insiste: las pantallas finales solo cuentan parte de la historia.

5. Decisiones difíciles y alternativas descartadas

Esta sección te diferencia. Contá un concepto que prototipaste y descartaste (por ejemplo, un modal de settings al login que frustraba porque interrumpía la tarea) y por qué. Demuestra criterio bajo constraints, no solo “gusto visual”.

6. Resultado medible

Métrica de producto o negocio cuando exista: findability, conversión, tickets de soporte, CSAT, tiempo de tarea. Si el proyecto no se shippeó, medí el aprendizaje del test (“en el segundo round X% más de usuarios completó la tarea”) y sé honesto.

7. Aprendizajes

Cerrá con 2–3 bullets de qué harías distinto. Los hiring managers buscan gente que reflexiona, no solo que entrega pantallas.

Plantilla lista para copiar

1. Título del proyecto + una línea de resultado (“+15% findability en settings”).

2. Contexto: producto, industria, timeline.

3. Problema / hipótesis.

4. Mi rol y colaboración.

5. Research: método + 3 insights.

6. Diseño: 3 artefactos con captions (sketch → wire → UI).

7. Decisión difícil: qué descarté y por qué.

8. Resultado (usuario + negocio).

9. Aprendizajes.

Formato: web o PDF/slide deck. NN/G sugiere 3–5 case studies fuertes, no veinte proyectos flojos. Si hay NDA, mostrá proceso (sketches, wireframes en B/N), redactá datos sensibles o recreá el layout sin branding.

Errores que te descartan (aunque el UI sea lindo)

• Solo screenshots finales sin problema ni rol.

• Wall of text imposible de escanear en el celular.

• Hablar en “nosotros” sin aclarar tu aporte en proyectos de equipo.

• Proyectos de facultad sin constraints reales presentados como si fueran producto en producción (mejor explicitá las limitaciones).

• Confundir UX, UI y gráfico en el mismo case study sin foco; si necesitás ordenar conceptos, leé 5 diferencias entre Diseño UX, UI y Diseño Gráfico.

Curso recomendado de Coderhouse

Si tu objetivo es conectar diseño con decisiones de producto y métricas, el Curso de Product Manager te ayuda a hablar el idioma de negocio que los recruiters esperan ver en un case study (problema, hipótesis, resultado).

CTA: elegí un solo proyecto esta semana y reescribilo con la plantilla de arriba. Pedile feedback a alguien que no sea diseñador: si en dos minutos entiende el problema y tu rol, vas bien.

Preguntas frecuentes

¿Cuántos case studies necesito? Calidad sobre cantidad: 3 a 5 proyectos alineados al tipo de rol que buscás suelen alcanzar.

¿Qué hago si el proyecto tiene NDA? Mostrá proceso, anonimizá, blur de datos o recreá el diseño sin marca. El hiring manager valora el criterio aún con restricciones.

¿Sirve un proyecto académico? Sí, si explicitás constraints y, idealmente, sumás research con usuarios reales. Evitá presentarlo como si fuera un producto shippeado.

¿Web o PDF? Ambos funcionan. Web es fácil de compartir; PDF/slide deck permite armar versiones a medida por postulación.