Para diseñadores y desarrolladores front-end, el portafolio suele importar más que el currículum. Es la prueba. Un currículum afirma que puedes hacer el trabajo; un portafolio muestra el trabajo y, sobre todo, cómo piensas sobre él.
La mayoría de los portafolios fallan de una de dos formas: demasiados proyectos mediocres, o capturas bonitas sin explicación del problema, tu rol o el resultado. Esta guía corrige ambas.
Puntos clave
- Tres a cinco proyectos sólidos superan a una docena mediocres: los revisores dedican entre dos y tres minutos en total.
- Cada proyecto necesita el mismo esqueleto: problema, tu rol, proceso, solución, impacto.
- Muestra la parte intermedia desordenada — bocetos, iteraciones, compromisos — no solo la pantalla final pulida.
- Desarrolladores: un enlace en vivo más un README limpio más código legible pesan más que una web vistosa.
Elegir qué incluir
- 1Lista todos los proyectos que podrías mostrar: trabajo, freelance, proyectos personales, trabajos de clase, hackatones, código abierto.
- 2Puntúa cada uno según: relevancia para los puestos que quieres, qué parte del resultado puedes atribuirte y si puedes explicar tu aportación concreta.
- 3Quédate con los 3-5 mejores. Descarta lo que tendrías que matizar mucho o de lo que no puedas hablar por un acuerdo de confidencialidad.
- 4Asegúrate de que el conjunto muestre variedad: distintos tipos de problema, no cinco versiones de la misma pantalla.
Un proyecto propio del que puedas hablar en profundidad supera a un proyecto real que apenas tocaste. Rediseña un producto que uses, crea una herramienta que necesitabas o contribuye a un repositorio de código abierto.
La estructura del caso práctico
Un caso práctico es una historia corta con una forma fija. Apunta a algo que un lector pueda revisar en dos minutos y leer entero en cinco.
1. Resumen (2-3 frases) Qué es el producto, para quién es, cuál era el proyecto. 2. Mi rol Tu título, el equipo, el plazo, qué eras responsable de frente a qué contribuiste. 3. El problema El problema de usuario o de negocio, y cómo supiste que era real (datos, investigación, quejas). 4. Proceso Los 3-4 movimientos clave que hiciste. Muestra artefactos: bocetos, flujos, prototipos, experimentos, PR. Incluye al menos un compromiso o un callejón sin salida y por qué cambiaste de rumbo. 5. La solución El resultado final, con imágenes o un enlace en vivo. Anota las decisiones que importan. 6. Impacto Cifras si las tienes (conversión, tiempo de carga, éxito de tarea, adopción). Si no, resultados cualitativos y qué medirías a continuación. 7. Qué aprendí Una o dos reflexiones honestas.
En lugar de
«Rediseñé el flujo de compra para mejorar la experiencia de usuario.» + 4 capturas pulidas.
Escribe
«El abandono del carrito era del 68 % en móvil. Hice 5 sesiones con usuarios, detecté que el formulario de dirección era el punto de abandono, probé un autocompletado de 2 campos frente al original de 9 y lancé el ganador. El abandono bajó al 51 % en 6 semanas.» + antes/después + los dos prototipos probados.
Si eres desarrollador
- Cada proyecto: un enlace de demo en vivo y un enlace al repositorio, ambos funcionando. Una demo rota es peor que ninguna demo.
- Escribe un README de verdad: qué hace, captura o GIF, stack tecnológico, cómo ejecutarlo en local, qué harías a continuación.
- Fija tus 4-6 mejores repositorios en tu perfil de GitHub y añade un README de perfil.
- Destaca señales de calidad de código: pruebas, CI, commits claros, estructura sensata. Los revisores sí abren el código.
- Las contribuciones a código abierto cuentan: enlaza los PR fusionados y di brevemente qué hizo cada uno.
- Para puestos de back-end o de datos donde no hay nada visual, un diagrama de arquitectura claro y una explicación escrita sustituyen a las capturas.
# Nombre del proyecto Una frase sobre qué hace y para quién es.  ## Por qué lo construí 2-3 frases. ## Stack Lenguajes, frameworks, librerías notables, alojamiento. ## Ejecutarlo en local Pasos. ## Decisiones destacadas - Decisión y el motivo - Un compromiso que hiciste ## Qué sigue Lista corta.
Si eres diseñador
- Muestra artefactos del proceso, no solo las comps finales: notas de investigación, flujos de usuario, wireframes, iteraciones.
- Incluye las versiones que no se lanzaron y di por qué: demuestra criterio.
- Mantén alto el nivel visual en la propia web del portafolio; es una muestra de trabajo lo pretendas o no.
- Vincula cada decisión a una necesidad de usuario o un objetivo de negocio, no al gusto personal.
- Para puestos de UX, encabeza con el pensamiento; para puestos visuales o de marca, encabeza con el oficio, pero ambos necesitan ambos.
Dónde alojarlo
- Una web personal en tu propio dominio es la opción más fuerte: control total, transmite compromiso.
- Rápido de publicar: una plantilla en un creador de webs, o una web estática sencilla en GitHub Pages, Vercel o Netlify.
- Los diseñadores pueden complementar con Behance o Dribbble para alcance, pero manten los casos prácticos reales en tu propia web.
- Desarrolladores: GitHub no es negociable; una web de portafolio es un plus.
- Ten siempre una versión en PDF o diapositivas de uno o dos casos prácticos para cuando alguien pregunte por correo.
Un portafolio con animaciones a medida que lleva semanas y aún tiene un solo proyecto no ayuda a nadie. Publica primero una web sencilla y rápida con tres casos prácticos reales y luego mejórala.
Errores comunes
- Demasiados proyectos, ninguno explicado en profundidad.
- Capturas sin planteamiento del problema, rol ni resultado.
- Atribuirse resultados de equipo sin decir qué hiciste personalmente.
- Ninguna información de contacto ni una forma obvia de ponerse en contacto.
- Enlaces protegidos con contraseña o rotos en la versión que envías a reclutadores.
- Enterrar el mejor proyecto en la tercera página.
Ponlo en práctica
Crea gratis un currículum compatible con ATS: ayuda de escritura con IA, descargas ilimitadas y sin marca de agua.
Empezar mi currículumPreguntas frecuentes
¿Cuántos proyectos debe tener un portafolio?
De tres a cinco. Los revisores rara vez pasan del tercero. La profundidad en unos pocos supera a la amplitud en muchos.
¿Puedo incluir trabajo bajo acuerdo de confidencialidad?
Habla primero con tu empresa. A menudo puedes mostrar el proceso y los resultados a alto nivel sin exponer detalles confidenciales ni pantallas no lanzadas. Ante la duda, descríbelo con palabras en lugar de mostrarlo.
¿Necesito un portafolio si soy desarrollador back-end?
Una web de portafolio es opcional, pero un perfil de GitHub sólido con repositorios fijados, buenos README y contribuciones visibles hace el mismo trabajo.
¿Qué va primero, el portafolio o el currículum?
Pon el enlace al portafolio arriba en tu currículum y en LinkedIn. Para puestos de diseño y front-end, cuenta con que revisarán el portafolio antes de leer el currículum con atención.