design businessApril 22, 202613 min read

Plantilla de caso de estudio de diseño: cómo escribir casos que de verdad consiguen trabajo

Una plantilla práctica para casos de estudio de diseño que convierten. Las ocho secciones que leen los responsables de contratación, los números que debes mostrar y cómo presentar el proceso sin dormir al lector.

By Boone
XLinkedIn
case study template designers

Ahora mismo, cada responsable de contratación tiene una pila de portfolios de diseño abiertos en pestañas del navegador. Dedica treinta segundos a cada uno. Quizá sesenta si el hero cumple su trabajo. El caso de estudio que gana es el que responde la pregunta real del responsable en esa ventana, no el que tiene los mockups más bonitos.

Esta es la plantilla de trabajo. Ocho secciones en un orden fijo, los números que importan y las fotos de proceso que de verdad aportan. Si tu portfolio actual parece un trabajo de la escuela, este es el patrón de reescritura.

Lo que los responsables de contratación realmente leen

El responsable de contratación busca evidencia de que lanzaste algo que movió un número. Todo lo demás es contexto. Los diagramas de proceso, los moodboards y los párrafos de "mi recorrido" van después, no primero. El caso de estudio que fracasa abre con el recorrido. El que gana abre con el resultado.

Los diseñadores que intuyen esto publican portfolios que convierten. Los que no, publican portfolios que "reciben buenos comentarios" y cero entrevistas. La diferencia es estructural, no artística.

La plantilla de ocho secciones

Estas ocho secciones, en este orden, cubren cualquier caso de estudio que un diseñador necesite escribir. Los proyectos pilar reciben el tratamiento completo. Los más pequeños, una versión comprimida. Las secciones se mantienen.

Pila vertical de vóxeles con ocho bloques numerados etiquetados resultado, problema, restricciones, proceso, decisiones, números, rol, reflexión, atravesados de arriba abajo por una fina línea naranja
Pila vertical de vóxeles con ocho bloques numerados etiquetados resultado, problema, restricciones, proceso, decisiones, números, rol, reflexión, atravesados de arriba abajo por una fina línea naranja

Sección 1: El resultado en una línea

Abre con el resultado, no con el contexto. Una frase. Qué lanzó el diseño y qué cambió.

"Rediseñé el checkout de un SaaS B2B y subí la conversión un 32% en el primer trimestre." Eso es una apertura de caso de estudio. "Me emocionó asumir este proyecto para una startup en modo stealth del sector fintech" es un caso que se cierra en cinco segundos.

Los responsables de contratación contrastan esta apertura con el resto de la página. Si el resto la respalda, siguen leyendo. Si la apertura es vaga (transformé la experiencia, reimaginé el recorrido, creé una nueva forma de pensar), asumen que faltan los números porque son malos. Escribe el resultado tan llano como un titular de periódico de negocios.

Sección 2: El problema en un párrafo

La sección del problema es donde la mayoría de los portfolios pierden al lector. Se lee como una revisión bibliográfica del negocio. Los responsables no necesitan la historia de la empresa, necesitan la restricción que creó el reto de diseño.

De dos a cuatro frases, máximo. Qué estaba roto. A quién perjudicaba. Por qué seguía roto. Ese es el problema.

Un buen párrafo de problema:

El flujo de checkout tenía un 63% de abandono en el nivel enterprise porque los equipos de compras no podían compartir una cotización con finanzas sin capturas de pantalla. El flujo existente asumía un único comprador con tarjeta de crédito. Arreglarlo implicaba rediseñar para una compra por comité con factura a 60 días.

Sin historia previa. Sin "el cliente se acercó a nosotros". Directo a la restricción. El artículo sobre principios de diseño de landing pages cubre la misma disciplina para el copy de marketing. Misma regla para los casos de estudio.

Sección 3: Las restricciones

Los casos de estudio sin restricciones parecen ficción. Todo proyecto real las tiene (plazo, equipo, plataforma, cumplimiento normativo, presupuesto, sistema existente). Enumerarlas genera confianza porque demuestran que el diseñador trabajó en el mundo real, no en un rebrand personal de una marca de Fortune 500.

De cinco a siete viñetas. Mantenlas concretas.

  • Equipo de dos diseñadores, un ingeniero, un PM
  • Plazo de seis semanas desde el arranque hasta el lanzamiento
  • Sistema de diseño existente bloqueado, solo adiciones, sin sobrescribir
  • Solo nivel enterprise, checkout de consumo intacto
  • Debía integrarse con el flujo de compras SAP existente
  • Objetivo de accesibilidad WCAG AA desde el primer día
  • Sin trabajo nuevo de backend, solo front-end e integración

Las restricciones no son quejas. Son la prueba de que el diseñador entendió la caja antes de dibujar dentro de ella.

Sección 4: El proceso, comprimido

La mayoría de los casos de estudio invierten demasiado en proceso. Incluyen cada boceto divergente, cada artefacto de taller, cada moodboard. Los responsables no los leen. Buscan tres cosas: si el diseñador enmarcó el problema, si validó la solución y si lanzó lo que diseñó.

Muestra evidencia de cada una, una sola vez.

Evidencia de enmarcado: un diagrama, flujo o matriz de decisión que muestre cómo se definió el alcance. Un mapa de recorrido, un service blueprint, un resumen de análisis competitivo, una captura de un registro de decisiones. Un artefacto, etiquetado con lo que respondió.

Evidencia de validación: un artefacto de investigación o pruebas. Resumen de test de usabilidad con dos citas, resultado de un test A/B, captura de analítica del estado anterior, una iteración de prototipo con cambios anotados. Un artefacto, etiquetado con lo que cambió.

Evidencia de lanzamiento: el diseño realmente desplegado. No el comp final en Figma. La URL en producción, la captura de la App Store, el flujo grabado. Los casos que muestran comps de Figma y jamás el producto lanzado parecen diseños de papel.

Vista dividida en vóxeles. A la izquierda, el comp de Figma de un diseñador con sombras. A la derecha, el mismo diseño en vivo en un dispositivo real. La flecha entre ambos dice que lo lanzado gana al comp
Vista dividida en vóxeles. A la izquierda, el comp de Figma de un diseñador con sombras. A la derecha, el mismo diseño en vivo en un dispositivo real. La flecha entre ambos dice que lo lanzado gana al comp

Sección 5: El registro de decisiones

Esta es la sección que la mayoría de los diseñadores se salta. Es la que los responsables de contratación leen dos veces.

Un registro de decisiones es una lista corta de decisiones no obvias tomadas durante el proyecto, con su compromiso y su resultado. Demuestra que el diseñador tenía opiniones contrastadas con la realidad, que es la señal más contratable que puede llevar un portfolio.

De tres a cinco entradas. Plantilla para cada una:

  • Decisión: lo que se eligió
  • Alternativa: lo que se descartó
  • Razón: la restricción o el insight que motivó la decisión
  • Resultado: lo que pasó tras el lanzamiento

Ejemplo:

  • Decisión: Compartir cotizaciones se reconstruyó como un enlace público de solo lectura en lugar de un flujo nativo de copia a finanzas.
  • Alternativa: Copia a finanzas dentro del producto con creación de cuenta obligatoria.
  • Razón: Los equipos de compras y finanzas a menudo pertenecen a sistemas distintos y compras no esperaría a un flujo de creación de cuenta.
  • Resultado: El 71% de las cotizaciones enterprise se compartieron en las 24 horas posteriores a su generación, frente al 12% antes del rediseño.

Los registros de decisiones son lo más parecido a una entrevista de trabajo que tiene un portfolio. Escríbelos primero y luego escribe el resto del caso a su alrededor.

Tabla de vóxeles con cuatro columnas etiquetadas decisión, alternativa, razón, resultado, con tres filas numeradas y una lupa flotando sobre ella
Tabla de vóxeles con cuatro columnas etiquetadas decisión, alternativa, razón, resultado, con tres filas numeradas y una lupa flotando sobre ella

Sección 6: El resultado, con números

La sección de resultados es el cheque del caso de estudio. Todo lo anterior fue la preparación. Los números aquí tienen que ser reales, específicos y atribuibles.

Funcionan tres tipos de números.

Números de negocio. Ingresos, conversión, retención, activación, tiempo hasta el valor, CAC, LTV. Son los números que los responsables quieren primero porque se conectan directamente con la razón de existir del equipo de diseño.

Números de producto. Finalización de tareas, tasa de error, volumen de tickets de soporte, tiempo en tarea, adopción de funciones. Prueban que el diseño cambió el comportamiento del usuario, lo que prueba que el diseño era bueno.

Números de calidad. Puntuación de auditoría de accesibilidad, mejora de core web vitals, adopción del sistema de diseño, tiempo de handoff ahorrado. Son los números de segundo nivel, útiles cuando los de negocio y producto no están disponibles (bajo NDA, demasiado pronto para medir).

Uno de cada grupo basta. Tres números por caso superan a diez, porque tres números específicos suenan honestos y diez suenan a relleno.

Si el proyecto está bajo NDA, dilo sin rodeos. Sustituye los números exactos por rangos verificables ("un aumento de conversión de dos dígitos bajos", "activación duplicada"). No inventes. Los responsables de contratación tienen amigos en todas las empresas, y preguntan.

Sección 7: Tu rol, sin rodeos

Todo caso de estudio necesita una respuesta clara a la pregunta que el responsable realmente tiene en la cabeza: qué hizo personalmente este diseñador.

Dos o tres frases. Usa "yo" cuando el trabajo fue en solitario, "nuestro equipo de cuatro" cuando no, y enumera la contribución concreta en ambos casos.

Bien:

Lideré el diseño de interacción y fui responsable del registro de decisiones. Trabajé en pareja con un ingeniero en el flujo de checkout y con un PM en el alcance. Otra diseñadora del equipo se encargó del sistema visual, que apliqué pero no diseñé.

Vago:

Lideré el proceso de diseño de principio a fin y colaboré estrechamente con socios multifuncionales para ofrecer una experiencia de usuario deliciosa.

La versión vaga parece una cortina de humo. Siempre provoca más preguntas en la entrevista, no menos. Escribe la versión clara y reserva la entrevista para las conversaciones que sí quieres tener.

Sección 8: La reflexión

Un párrafo corto. Qué harías distinto si repitieras el proyecto.

Esto delata la seniority. Los diseñadores junior reflexionan en generalidades ("iteraría más con usuarios desde antes"). Los senior reflexionan con especificidad ("subestimé en cuatro semanas el plazo de la integración con compras y lo habría planteado como un flujo de trabajo separado desde el primer día en lugar de meterlo dentro del proyecto de checkout").

Una reflexión demasiado positiva ("todo salió genial") parece una alerta de credibilidad. Una demasiado negativa ("fracasé") parece poco profesional. Una específica y táctica parece de alguien que aprendió del proyecto y aprenderá del siguiente.


Qué recortar de la mayoría de los casos de estudio

La mayoría de los casos son más largos de lo necesario, por eso los responsables los leen en diagonal. Recorta lo siguiente:

El párrafo "sobre el cliente". Si el cliente es conocido, el responsable ya lo sabe. Si no, el contexto va en el planteamiento del problema, no en un bloque aparte.

El moodboard. Casi nunca es relevante para una decisión de contratación. Guarda los moodboards para archivos de trabajo internos y presentaciones a clientes, donde sí sirven.

La cuadrícula de ideación divergente. Nueve conceptos en una página, ocho de ellos descartados, es un artefacto de taller, no de portfolio. Muestra la dirección final y la única alternativa que fue una contendiente real.

El carrete de comps sin lanzar. Comps preciosos de cosas que nunca salieron le dicen al responsable que quizá el diseñador no lanza. Es la señal equivocada. Lidera siempre con trabajo lanzado.

El ensayo de estilo personal. Las secciones de "mi filosofía de diseño" se saltan. Si la filosofía es real, los casos la demostrarán sin anunciarla.

Diagrama de vóxeles. A la izquierda, etiquetado relleno: moodboard, cuadrícula de ideación, ensayo personal, historia del cliente, carrete de comps. A la derecha, etiquetado señal: problema, restricciones, registro de decisiones, números, rol
Diagrama de vóxeles. A la izquierda, etiquetado relleno: moodboard, cuadrícula de ideación, ensayo personal, historia del cliente, carrete de comps. A la derecha, etiquetado señal: problema, restricciones, registro de decisiones, números, rol

Longitud del caso de estudio según seniority

La longitud de un caso cambia con la seniority, pero la estructura no. Las ocho secciones se quedan. Lo que cambia es la profundidad dentro de ellas.

SeniorityProblemaRestriccionesProcesoDecisionesResultadoRolReflexiónLongitud total
Junior3 frases5 viñetas3 artefactos3 decisiones2 números3 frases3 frases800 a 1200 palabras
Mid1 párrafo6 viñetas3 artefactos4 decisiones3 números3 frases1 párrafo1200 a 1800 palabras
Senior1 párrafo7 viñetas3 artefactos5 decisiones3 a 5 números3 frases1 párrafo1500 a 2200 palabras
Staff2 párrafos7 viñetas3 artefactos5 decisiones con compromisos organizativos5 números con atribución3 frases1 párrafo1800 a 2500 palabras

Cualquier cosa por encima de 2500 palabras es un caso que nadie termina. La regla para roles senior y staff es densidad, no longitud. Más criterio por párrafo, no más párrafos.

Cómo escribir el primer borrador

La forma más rápida de llegar a un caso publicable es escribir en este orden, que no es el orden que ve el lector.

  1. Escribe primero el registro de decisiones. De tres a cinco entradas. Es la parte más difícil y sobre la que gira todo lo demás.
  2. Escribe en segundo lugar la sección de resultados. Saca los números antes de escribir alrededor de ellos.
  3. Escribe en tercer lugar el problema y las restricciones. Ahora sabes qué restricciones importaron porque sabes qué decisiones impulsaron.
  4. Escribe en cuarto lugar la sección de proceso. Elige los tres artefactos que se ganan su lugar.
  5. Escribe al final las secciones de rol y reflexión. Cortas, honestas, listas.
  6. Reescribe al final el resultado en una línea de arriba, cuando todo lo demás esté escrito. Es la última frase que se redacta y la primera que se lee.

Este orden obliga a hacer el pensamiento difícil desde el principio. Los diseñadores que escriben en orden de lectura suelen acabar con prosa bonita y sin sustancia.

Cómo presentar el proceso sin aburrir al lector

Las secciones de proceso son donde la mayoría de los portfolios se leen en diagonal hasta la muerte. La solución es densidad, no eliminación.

Una captura anotada por artefacto. No una galería de todo el archivo de trabajo. Una sola captura con tres llamadas que expliquen qué respondió el artefacto.

Un único video de prototipo, de no más de 30 segundos. Olvida la grabación de pantalla sin editar. Corta el video del prototipo en un bucle compacto que muestre la interacción clave, con etiqueta.

Antes y después, siempre. Cualquier comparación que incluya un "antes" es más fuerte que una que no. Incluso un boceto a lápiz junto al producto lanzado se lee como progreso. El glosario de wireframe cubre qué tipo de artefactos tempranos tienen peso.

Un vóxel, boceto o frame de baja fidelidad en lugar de otro comp pulido. El contraste entre el pensamiento de baja fidelidad y el lanzamiento de alta fidelidad prueba que el diseñador trabajó el problema en lugar de maquillar una solución.

Si quieres un equipo que audite portfolios y reescriba casos de estudio con responsables de contratación en el circuito, contrata a Brainy. Las revisiones de portfolio son una de nuestras ofertas de más rápido movimiento para diseñadores senior y staff en búsqueda de empleo.

La prueba de aprobado o suspenso del caso de estudio

Pasa cada caso de estudio por cinco comprobaciones antes de publicarlo en tu portfolio.

Prueba de escaneo. ¿Puede un lector sacar el problema, el enfoque y el resultado solo de los titulares y las primeras frases? Si no, la escaneabilidad está rota. El artículo de diseño de jerarquía visual cubre la solución estructural.

Prueba de números. ¿Hay al menos dos números reales en la página? Si no, el caso es una historia sin remate.

Prueba de rol. ¿Puede un lector responder "qué hizo personalmente este diseñador" en menos de 10 segundos de lectura? Si no, la sección de rol es demasiado vaga.

Prueba de decisiones. ¿Muestra el caso al menos tres decisiones no obvias con sus compromisos nombrados? Si no, el diseñador parece un ejecutor, no un pensador.

Prueba de lanzamiento. ¿Hay evidencia de que el trabajo realmente se lanzó? Una URL, una captura en un dispositivo real, un enlace a la App Store, una captura de código en producción. Si no, el caso es una pieza especulativa, no profesional.

Cinco comprobaciones. Cinco minutos. Cada caso, cada vez.


FAQ

¿Qué longitud debe tener un caso de estudio de diseño?

Entre 800 y 2500 palabras, según la seniority. Los casos junior van de 800 a 1200, los de nivel mid de 1200 a 1800.

Los senior de 1500 a 2200. Los casos staff y principal pueden llegar a 2500 si las decisiones y los números lo justifican. Más que eso pierde al lector.

¿Qué debe incluir todo caso de estudio de diseño?

Ocho secciones en orden: un resultado en una línea, un párrafo de problema, restricciones, una sección de proceso comprimida, un registro de decisiones, resultados medibles, una declaración clara de tu rol personal y una reflexión breve. Todo caso necesita las ocho aunque algunas sean solo dos frases.

¿Cómo se escribe un caso de estudio sin romper un NDA?

Sustituye los números específicos por rangos verificables ("un aumento de conversión de dos dígitos bajos") y las marcas con nombre por el sector ("una fintech con más de 100 clientes enterprise"). Indica el NDA con claridad al principio del caso. No inventes números ni marcas. Los responsables de contratación comprueban, y los casos fabricados acaban con carreras.

¿Cómo mostrar el proceso sin dormir al lector?

Limítate a tres artefactos (uno para el enmarcado, uno para la validación, uno para el lanzamiento). Anota cada artefacto con lo que respondió. Sustituye los videos largos de prototipo por cortes de 30 segundos de la interacción clave. Incluye siempre una comparación de antes y después. La densidad supera al volumen en toda revisión de portfolio.

¿Cuál es el mayor error que cometen los diseñadores en los casos de estudio?

Abrir con el contexto en lugar de con el resultado. La primera línea de un caso debe ser el resultado del proyecto, no la emoción de empezarlo. Los responsables de contratación escanean de arriba abajo. Si el resultado está enterrado en la página dos, el caso ya está perdido.

¿Cómo escribo un caso de estudio si todavía no he lanzado el proyecto?

Lanza algo primero. Los casos sin lanzar parecen especulativos y los responsables los descuentan. Si el proyecto tiene que aparecer antes del lanzamiento, etiquétalo claramente como "en desarrollo" y céntrate en el registro de decisiones y en la investigación. Nunca muestres comps sin lanzar como si fueran reales.

El portfolio es una página de ventas

Todo caso de estudio es una página de ventas para el diseñador que lo escribió. El producto es el diseñador. El comprador es el responsable de contratación. El precio es una entrevista de cuarenta minutos.

Las páginas de ventas que ganan son directas, específicas y honestas. Abren con el resultado, lo prueban con restricciones y decisiones, lo respaldan con números y cierran con una declaración clara de quién es el vendedor. Las que pierden esconden el resultado detrás del proceso, rellenan la historia con contexto y dejan al lector preguntándose qué compró realmente.

Escribe las ocho secciones. Recorta el relleno. Publica el caso. Luego hazlo otra vez con el siguiente proyecto, y con el siguiente, hasta que el portfolio se lea como un conjunto de apuestas lanzadas que salieron bien, no como un conjunto de recorridos que disfrutaste.

Si quieres un equipo que audite, reescriba y publique portfolios que se conviertan en entrevistas, contrata a Brainy. Hemos aplicado esta plantilla a portfolios de producto, marca y UX y la estructura aguanta siempre.

Lecturas relacionadas

Need a portfolio that lands interviews instead of silence? Brainy runs portfolio audits and rewrites with hiring managers in the loop.

Get Started

More from Brainy Papers

Keep reading