¿Sos diseñador junior y no conseguís laburo? Seguro te dijeron: “necesitás más experiencia” o “hacé más freelance”.

Pero todas las ofertas piden lo mismo: años de experiencia, casos reales, métricas.

Es un loop imposible. No podés tener experiencia sin trabajo. Y no podés tener trabajo sin experiencia.

Acá va algo que nadie te dice: no necesitás experiencia real. Necesitás pensar como alguien que la tiene. Y eso se demuestra con un proyecto propio, hecho en serio.

TL;DR

Un recruiter no puede chequear si tu cliente fue real. Solo puede ver cómo pensás. Un proyecto propio, bien investigado, puede sonar más profesional que un caso real mal contado. No hace falta esconder que es tuyo. Hace falta tratarlo en serio.

En este artículo

• Qué mira en verdad un recruiter

• Por qué fallan los portfolios junior

• La fórmula: problema + límites + decisiones

• Cómo investigar sin tener datos propios

• Por qué mostrar los errores suma

• La ventaja que ni los seniors tienen

Un recruiter no mira si sabés usar Figma

Cuando alguien abre tu portfolio, no busca años de experiencia. Busca saber si contratarte es un riesgo.

Se pregunta: ¿le voy a tener que explicar todo? ¿Puede defender una decisión en una reunión? ¿Entiende el negocio, o solo hace pantallas lindas?

La mayoría de los portfolios junior no responden eso. No porque el diseño esté mal. Falta contexto. Faltan argumentos. Parece un trabajo de facultad. Y eso los hace invisibles.

El error no es no tener un cliente real

El error es pensar que sin cliente, sin métricas y sin equipo, no tenés nada para mostrar.

Un recruiter no puede llamar a tu “cliente”. No puede pedir tu Google Analytics. Solo puede leer cómo contás tu proceso. Si tus decisiones tienen lógica, o si son solo estética.

Eso lo podés demostrar con el rediseño de una app que usás todos los días. Lo que importa no es el cliente. Es cómo pensás.

La fórmula: problema, límites, decisiones

Hay algo simple que separa a los juniors que consiguen entrevistas:

Problema investigado + límites reales + decisiones justificadas = portfolio profesional.

No hace falta un cliente. Hace falta pensarlo como si lo hubiera.

Paso 1: Empezá con un problema investigado

No digas “diseñé una app de fitness”. Decí: “el 73% abandona apps de fitness en la primera semana, porque piden mucho esfuerzo antes de dar un primer resultado”.

La diferencia no es el diseño. Es el dato, el insight. Y para eso no necesitás cliente, necesitás investigar.

Dónde buscar problemas sin datos propios:

• Estudios de UX públicos (Baymard, Nielsen Norman Group, Pew)

• Comentarios en la App Store, Reddit, G2

• Apps que usás y te frustran

No inventes el problema. Investigalo. Citar una fuente real ya te saca del molde de ejercicio.

Paso 2: Los límites hacen que suene profesional

En el mundo real siempre hay límites: tiempo, plata, tecnología. Mostrar que diseñaste con esos límites prueba que entendés cómo funciona una empresa.

Ejemplos:

• “Descarté la IA porque su costo no cerraba para un producto chico.”

• “Diseñé pensando en dos semanas de trabajo con dos programadores.”

• “Simplifiqué el registro para que fuera rápido, porque apps parecidas perdían usuarios cuando tardaba más.”

Esto funciona porque muestra lo que ganaste y lo que sacrificaste. Y eso prueba que no solo diseñás: decidís.

Paso 3: Cambiá métricas propias por argumentos sólidos

La duda más común: “¿cómo muestro impacto si nunca medí nada?”.

No hace falta tu propia métrica. Hace falta un buen argumento con datos externos.

No digas “mejoré la conversión”. Decí: “bajé el pago de cinco pasos a dos. Según Baymard, cada paso extra baja la conversión un 15%. Sacar tres pasos podría subirla un 35%”. No es tu dato. Es un argumento con research detrás.

También podés generar datos reales gratis: buscá cinco personas, hacelas probar tu diseño y anotá qué pasó. “Cuatro de cinco no entendían el botón ‘Continuar’. Cambié el texto y el problema desapareció.” Eso es research real, sin cliente.

Paso 4: Mostrá lo que no funcionó

Casi nadie hace esto. Y es un error, porque diseñar nunca es un camino recto.

“Probé usar medallas de logros. A la mayoría le pareció infantil. Cambié a una barra simple de progreso.” Eso muestra que probaste, escuchaste y ajustaste. Es justo lo que un líder de diseño quiere ver.

Paso 5: Contalo como una historia

Un buen case study tiene tensión y resolución. No es una lista de tareas.

Orden que funciona: el problema con datos, tu hipótesis sobre la causa, lo que probaste y lo que falló, la solución final con sus límites, el impacto esperado.

Los títulos también importan. No pongas “Research”. Poné “Por qué el 67% abandonaba en el paso 3”. Eso genera intriga.

No hace falta esconder que el proyecto es tuyo

Este es el punto clave: no se trata de disimular que no hubo cliente. Se trata de decirlo con seguridad.

La mayoría de los diseñadores con experiencia real tampoco tiene buenas métricas. Trabajaron en equipos que no medían nada. O le atribuyen a su diseño un resultado que tuvo mil causas. Cuando alguien dice “mi rediseño subió la conversión 40%”, muchas veces esa cifra no prueba nada.

Vos, con un proyecto propio bien pensado, podés sonar más serio que alguien con años de experiencia. No porque parezca real. Porque el pensamiento sí lo es.

Qué hacer ahora

1. Elegí una app que uses y te frustre.

2. Investigá el problema en reviews, estudios y foros.

3. Definí dos o tres límites reales.

4. Diseñá con esos límites.

5. Testeá con cinco personas.

6. Anotá todo, incluido lo que falló.

7. Contalo como lo que es: un proyecto propio, hecho en serio.

Con eso vas a tener un case study que demuestra que pensás como diseñador profesional, aunque nunca hayas pisado una oficina.