El portafolio como bitácora

Autor: Adrian Solca · 2026-08-31

Ayer estuve en una sesión grupal revisando portafolios de Diseñadores. Llevo años haciendo esto — en comunidad, en mentorías, en procesos de contratación reales — y la sesión de ayer me confirmó algo que vengo notando hace tiempo: casi todos los portafolios que reviso tienen exactamente los mismos p

El portafolio como bitácora

Ayer estuve en una sesión grupal revisando portafolios de Diseñadores. Llevo años haciendo esto — en comunidad, en mentorías, en procesos de contratación reales — y la sesión de ayer me confirmó algo que vengo notando hace tiempo: casi todos los portafolios que reviso tienen exactamente los mismos problemas. No problemas de talento. Problemas de entender qué está comprando la persona del otro lado.

Porque eso es lo primero que hay que aceptar, aunque duela un poquito: nadie está comprando tus pantallas. Con las herramientas de IA actuales, generar una interfaz decente pasó de tomar una semana a tomar quince minutos — en la sesión de ayer uno de los participantes lo dijo con todas sus letras, y con algo de angustia, porque si cualquiera puede producir pantallas, ¿qué estás vendiendo tú?

La respuesta corta: tu forma de decidir. Quien te contrata quiere entender cómo piensas cuando el problema no viene con instrucciones. Y aquí está la trampa: la mayoría de los portafolios están armados específicamente para ocultar eso.

Me explico con los patrones que vi ayer, que son los mismos de siempre.

El portafolio receta.

El que abre con “apliqué Design Thinking” y te lleva de la mano por Empatizar → Definir → Idear → Prototipar como si fuera la letanía del rosario. El problema con este portafolio es que demuestra que sabes seguir instrucciones, que es precisamente la habilidad que la IA ya hace gratis. Uno de los revisores de la sesión lo dijo bien: muchos de estos casos saltan de la definición a la ideación sin haber definido nada — el framework está completo, el problema nunca apareció.

El portafolio bootcamp.

El rediseño de Spotify, el rediseño de Rappi, el rediseño de la app del banco. Yo entiendo de dónde viene: es el ejercicio que te dejaron en el curso. Pero un rediseño sin acceso al negocio, a los datos ni a los usuarios reales es una opinión decorada. No hay ninguna decisión real adentro, porque nunca tuviste que negociar con la realidad.

El portafolio con investigación fantasma.

Dice “hice entrevistas con usuarios” y ya. ¿Cuántas personas? ¿Qué encontraste? ¿Qué hipótesis validaste o tiraste a la basura? ¿Cómo conecta ese hallazgo con la decisión de diseño que tomaste tres slides después? Si mencionas investigación sin reportar hallazgos, el lector experimentado asume lo peor: que la investigación fue un trámite para que el caso se viera completo. Un mapa de empatía sin justificación no suma puntos — resta, porque revela que llenas plantillas.

¿Qué sí funciona?

En la sesión, uno de los revisores mostró un caso propio de banca y el gancho no era una pantalla. Era un número: la solución redujo 32% las llamadas al centro de atención. Todo lo demás — el proceso, los wireframes, las iteraciones — venía después, como evidencia de cómo se llegó a ese número. Quien contrata lee eso y entiende de inmediato qué compra: alguien que mueve métricas de negocio, no alguien que entrega archivos de Figma bien organizados.

Mi recomendación concreta, la que doy en cada revisión: arma cada caso como bitácora, no como receta. Una bitácora dice: este era el problema de negocio, esta era mi hipótesis, esto encontré al investigar (con números), esta decisión tomé y por qué, esto cambié a la mitad del camino cuando la evidencia me contradijo, y este fue el resultado. Fíjate que la bitácora incluye lo que la receta esconde: los cambios de dirección, las propuestas que te rebotaron, la negociación con el stakeholder que no estaba de acuerdo. Eso que te da pena mostrar es exactamente lo que demuestra madurez profesional. Cualquiera diseña bien cuando todo sale según el plan; el criterio se ve cuando el plan truena.

Un matiz importante antes de que salgas a redocumentar todo: el nivel al que aspiras cambia lo que muestras. Si buscas un rol de Product Designer — que es un perfil estratégico, al nivel de un Product Manager, responsable de propuesta de valor y modelos de conversión — tu caso tiene que arrancar desde antes del diseño: cómo identificaste el nicho, cómo validaste que el problema existía, qué requerimientos estratégicos definiste. Si buscas un rol de ejecución, la profundidad técnica documentada pesa más: cómo estructuraste el sistema, cómo documentaste decisiones para que el equipo pudiera trabajar. Los dos son valiosos. Lo que descalifica es aspirar a lo primero mostrando solo lo segundo.

Sobre el CV.

Porque siempre me lo preguntan junto. El CV es otro animal: lo va a leer primero un algoritmo y después un humano con treinta segundos. Ahí sí hay estándar y conviene seguirlo sin creatividad: cronología inversa, y cada puesto descrito como problema que resolviste, método que usaste y resultado con número. “Diseñador UI” no dice nada; “rediseñé el checkout y la conversión subió 15%” dice todo. Lista tus herramientas de forma explícita en su propia sección — los sistemas de tracking de candidatos buscan palabras exactas, no interpretan. Y si no tienes título universitario, pon tus certificaciones al frente sin complejo: quien recluta busca qué sabes hacer.

La implicación práctica de todo esto: agarra tu mejor caso y hazle una sola pregunta — ¿alguien que lo lea puede reconstruir las decisiones que tomé y por qué? Si la respuesta es no, no necesitas más pantallas ni mejor tipografía. Necesitas escribir la bitácora que ya viviste.

Felices trazos.