Respuesta breve
Un portfolio sólido sin clientes se construye mejor alrededor de restricciones reales, etiquetando con honestidad el estado del proyecto: formativo, voluntario o concepto de rediseño no oficial.
Por qué el trabajo académico por sí solo puede ser una prueba débil
Nielsen Norman Group advierte que un portfolio convincente es más difícil de construir cuando todo lo que un candidato puede mostrar son trabajos de estudiante, porque esos proyectos suelen tener restricciones, usuarios y personas inventados que los debilitan como prueba de trabajar en condiciones reales. NN/g recomienda conseguir al menos un proyecto real mediante unas prácticas y, para los trabajos académicos ya terminados, señalar abiertamente los elementos poco realistas en la descripción del caso, para que el lector entienda los límites de lo que demuestra.
Interaction Design Foundation plantea una práctica parecida de otra manera: un «proyecto hipotético» puede construirse analizando un producto existente o puede ser totalmente inventado; IxDF llama a ambas opciones una buena estrategia justamente para quienes empiezan. Esto no coincide del todo con la advertencia de NN/g: IxDF precisa por separado que los proyectos reales —voluntariado, trabajo académico, comunitario o de hackathon— suelen ser más valiosos que los hipotéticos, pero no prohíbe inventar el propio producto. La diferencia aquí no está en los hechos, sino en el énfasis: NN/g recomienda ante todo buscar un proyecto real y, solo si no lo hay, usar restricciones realistas con una aclaración honesta sobre su carácter ficticio; IxDF también admite un producto totalmente inventado, aunque considera que los proyectos reales suelen ser más valiosos. De ahí se desprende el principio editorial para los tres ejercicios siguientes: no «inventes una marca desde cero», sino «toma un producto real y una restricción real y verificable» —una decisión editorial que se apoya en la advertencia de NN/g y en que la propia IxDF valora más los proyectos reales que los hipotéticos, no en una postura conjunta que formulen ambas fuentes.
Tres ejercicios en lugar de una marca inventada
Cada uno de los tres ejercicios se construye alrededor de una restricción real y verificable —un servicio existente, una petición de voluntariado gen uina o el producto de otra empresa— y no alrededor de una marca ficticia con métricas inventadas. Cada ejercicio tiene su propio tipo de restricción: una plataforma técnica y una navegación ya existentes en el primero, un presupuesto de tiempo y la falta de pago en el segundo, un sistema visual ya establecido por otra empresa en el tercero. El criterio de evaluación también cambia de un ejercicio a otro y nunca se reduce a si la imagen final gusta.
La regla común a los tres: el resultado no es una reseña de cliente ni una cifra de ventas que no existe, sino un artefacto verificable (un mockup, un prototipo, un concepto de rediseño) con el estado del proyecto declarado abiertamente. Tres etiquetas sugeridas para los tres ejercicios: «proyecto formativo, no un encargo de cliente», «proyecto voluntario para (tipo de organización), sin remuneración» y «concepto de rediseño: trabajo no oficial sobre el producto de otra empresa, sin encargo ni aprobación del propietario». Las fuentes no comparan el peso de estas etiquetas con el de un encargo real en una entrevista: NN/g llama al proyecto formativo una prueba poco convincente de la capacidad de trabajar en condiciones reales, e IxDF sitúa los proyectos reales, incluidos los de voluntariado, por encima de los hipotéticos (véase arriba); es decir, el estado formativo por sí solo pesa menos que un encargo cumplido. El principio práctico a partir de aquí ya es editorial: para no dar una falsa impresión de trabajo con cliente, conviene nombrar el estado en el caso antes de describir el resultado, en lugar de dejarlo sin aclarar hasta la entrevista.
Ejercicio uno: auditar un servicio existente y justificar un cambio
Elige un servicio o una interfaz que uses tú mismo —no una «startup» abstracta, sino una app, un sitio o un formulario concretos con pantallas reales que puedas abrir y capturar. Formula una pregunta acotada: qué paso de esa interfaz genera más fricción y por qué. La restricción aquí es técnica y real: trabajas dentro de una navegación, una tipografía y unos tamaños de pantalla ya existentes, no en el vacío, y eso hay que explicarlo antes de proponer cambios. Nielsen Norman Group recomienda registrar el estado inicial —con capturas u otros datos— antes de cualquier rediseño, para tener con qué comparar después la decisión final.
Interaction Design Foundation llama a este formato —analizar un producto existente y proponer una mejora— una estrategia recomendada justamente para principiantes. Estructura el caso según el esquema «contexto y rol del autor → proceso → resultado con reflexión» que describe otro artículo metodológico del mismo recurso: primero, qué pregunta te hiciste y por qué; luego, qué opciones consideraste y descartaste y por qué; al final, qué harías de otro modo si volvieras a la tarea ahora.
Resultado: un prototipo de un paso y al menos una alternativa descartada
El resultado verificable de este ejercicio no es un rediseño completo del servicio, sino un mockup o prototipo de un paso concreto, una captura o registro del estado «antes» de ese paso, y una breve descripción de al menos una alternativa que consideraste y descartaste, con el motivo del rechazo. Un plazo de una a dos semanas no es una norma de las fuentes, sino una referencia editorial: basta para recorrer el camino «pregunta → alternativas → decisión» sin alargar un ejercicio formativo durante meses.
Control: ¿se puede explicar el problema sin ver el mockup?
El criterio de autoevaluación es simple: ¿puede el lector del caso repetir con sus palabras qué problema exacto resolviste, sin mirar el mockup? El estado de este ejercicio es «proyecto formativo, no un encargo de cliente»; conviene indicarlo directamente en la descripción del caso, no en letra pequeña al final de la página, siguiendo el mismo espíritu con el que NN/g recomienda declarar abiertamente los elementos poco realistas de los proyectos formativos.
Ejercicio dos: un proyecto voluntario con una petición real y sin pago
El segundo tipo de restricción real no es una hipótesis, sino una petición viva de una organización que necesita trabajo de diseño y no tiene presupuesto para pagarlo. Interaction Design Foundation señala directamente a organizaciones benéficas y sin ánimo de lucro, proyectos estudiantiles y comunitarios y hackathons como fuentes de este tipo de restricciones no inventadas, y advierte por separado que cambiar trabajo por «experiencia» a menudo se convierte en explotación de diseñadores jóvenes, por lo que conviene elegir precisamente esas opciones éticas de la lista, y no cualquier encargo gratuito de cualquiera.
La diferencia de este ejercicio respecto al primero está en la cantidad de retroalimentación: en una petición de voluntariado hay una persona de la organización que puede confirmar o rechazar la solución, aunque no haya pago. Conviene definir la restricción por escrito y de antemano, en forma de briefing: qué hay que hacer, para cuándo y en qué formato se necesita el resultado. Es la misma habilidad que trabajar con el briefing de un encargo pagado; la diferencia es que aquí redactas el briefing tú mismo junto con la persona de la organización, en lugar de recibirlo ya hecho de un cliente de estudio.
Resultado: un briefing, una solución y la reacción de la organización
El resultado verificable es un briefing escrito con la tarea y el plazo, el propio mockup o prototipo, y una breve reacción documentada de la persona de la organización ante la solución propuesta, aunque sea un rechazo de parte de las ideas: lo importante es el hecho mismo de recibir retroalimentación de una persona real, no solo tu propia valoración. Un plazo de varias semanas es una referencia editorial, no una norma de la fuente.
Control: ¿se tuvieron en cuenta los límites de esa organización en concreto?
El criterio de evaluación del caso: ¿se ve que la solución se tomó teniendo en cuenta las limitaciones de esa organización en concreto —su audiencia, sus recursos para mantener el mockup después de la entrega— y no que se copió de una plantilla abstracta? El estado del proyecto es «proyecto voluntario para (tipo de organización), sin remuneración», indicando para quién se hizo, sin inventar un resultado que la organización nunca confirmó.
Ejercicio tres: un concepto de rediseño de un producto ajeno con el estado a la vista
El tercer formato es el más arriesgado desde el punto de vista ético: consiste en tomar un producto real de otra empresa y rediseñarlo visualmente, y es aquí donde resulta más fácil presentar el resultado como si fuera un encargo cumplido de esa empresa. Ninguna de las fuentes consultadas formula una prohibición directa al respecto; se trata de una posición metodológica editorial que se apoya en el consejo de NN/g de declarar abiertamente los elementos poco realistas de los proyectos formativos en la descripción: el mismo principio se extiende aquí al trabajo con el producto de otra empresa —el estado debe verse de inmediato, y no ser algo que la parte que contrata tenga que adivinar.
Desde el punto de vista de la transparencia editorial, este tipo de caso no se puede presentar como un encargo de la empresa: el producto o la interfaz se toma como objeto de un análisis independiente, y la primera frase debe indicar claramente que el trabajo es no oficial y que no fue encargado ni aprobado por su propietario. Pero una etiqueta honesta por sí sola no resuelve la cuestión legal. Según el art. 1270 del Código Civil ruso, la traducción u otra adaptación de una obra protegida, así como la puesta a disposición del público de una obra, se cuentan entre los usos que abarca el derecho exclusivo. Son normas del derecho ruso: fuera de Rusia el régimen de protección de derechos de autor y marcas puede ser distinto, y conviene comprobarlo por separado. Si esto se aplica a una interfaz, un logotipo o unos elementos concretos, y si existe una excepción legal aplicable, depende del objeto y de las circunstancias. Los derechos de marca se regulan aparte y este artículo no los analiza en profundidad. Por eso este material no da un permiso universal para publicar el logotipo de otra empresa ni su rediseño; el mínimo práctico es no crear una falsa impresión de encargo o aprobación, y revisar por separado los derechos sobre los elementos usados antes de publicar.
Resultado: un concepto de rediseño con el estado indicado con claridad
El resultado verificable es el propio concepto de rediseño (mockup, prototipo o sistema) y una explicación en el primer párrafo de la descripción: qué se rediseñó exactamente, que es un trabajo no oficial y que la empresa no lo encargó ni lo aprobó. Mencionar la empresa en la descripción hay que separarlo de usar su logotipo u otro signo: la legalidad de ese uso depende del contexto concreto y de los derechos sobre ese elemento, y este artículo no sustituye una revisión legal.
Control: ¿el texto insinúa el consentimiento de la empresa?
Autocontrol antes de publicar: vuelve a leer la descripción del caso y marca cada lugar donde un lector ocasional podría pensar que la empresa conoce o aprobó este trabajo, y reescribe esos lugares con claridad. El mismo principio se aplica al logotipo por separado de la interfaz: el derecho a mostrar en el portfolio un logotipo hecho por encargo real y el derecho a mostrar el rediseño de un logotipo ajeno ya existente son cosas distintas con consecuencias legales distintas, y conviene aclarar esa diferencia antes de publicar, no después de una pregunta en una entrevista.
Cómo montar un caso que muestre el razonamiento y no solo la imagen
En los tres casos conviene mantener el mismo conjunto de preguntas —contexto, rol del autor, proceso, alternativas, resultado y reflexión—, sin forzar proyectos distintos dentro de una misma plantilla visual. Interaction Design Foundation describe una secuencia básica de «inicio, proceso y conclusión» en otro artículo metodológico del mismo recurso: primero el contexto de la tarea y el rol del autor, luego el camino hacia la solución y las alternativas, y al final el resultado y la reflexión sobre qué convendría hacer de otro modo. El mockup final, en esa lógica, muestra el resultado del proceso, pero el formato del propio caso se puede adaptar al material.
Un énfasis parecido aparece en una recopilación en vídeo de Interaction Design Foundation con varios responsables de diseño y de contratación, entre los que la página nombra, con su cargo, al responsable creativo (Creative Lead) de Smashing Magazine, Vitaly Friedman, y al responsable de diseño de producto de Netflix, Nival Sheikh; la transcripción del vídeo no está disponible para leer en la página, así que este artículo no les atribuye palabras concretas. La conclusión textual que ofrece IxDF sobre esa recopilación es mostrar en el portfolio el razonamiento y ser concreto en lugar de vago. La comparación con una imagen final pulida la plantean directamente otros artículos metodológicos del mismo recurso: el que describe la estructura del caso y el que enumera los errores habituales del portfolio. La conclusión práctica para el caso: escribe no solo «qué resultó», sino qué alternativas descartaste y por qué; esta parte de la estructura del caso merece atención en cualquier formato, no solo en el formativo.
Cómo etiquetar el estado del proyecto para que no parezca un encargo
Los tres estados usados arriba sirven ante todo para la transparencia: quien lee el caso entiende de inmediato dónde hubo un proyecto formativo, dónde trabajo voluntario y dónde un concepto de rediseño independiente. Nielsen Norman Group recomienda hacer justo esto con los proyectos formativos ya terminados: declarar abiertamente en la descripción sus elementos poco realistas, para que quien contrata no se lleve la impresión de que el autor simplemente no distingue esto de un proyecto real. La recomendación editorial es revelar el estado ya en la primera frase de la descripción del caso, para que la presentación visual no dé la impresión de un encargo real antes de que aparezca la aclaración.
La redacción debe ser tan concreta como el propio caso: no «un proyecto de práctica», sino «proyecto formativo, no un encargo de cliente, hecho para trabajar una solución concreta de interfaz»; no «ayudé a una organización», sino «proyecto voluntario para una iniciativa local sin ánimo de lucro, sin remuneración, con una duración de varias semanas»; no «rediseño de marca», sino «concepto de rediseño para (empresa): iniciativa propia del autor, sin encargo ni aprobación del propietario». Estas fórmulas concretas son una propuesta editorial y no una cita de una fuente: ninguno de los materiales consultados ofrece un lenguaje ya hecho para este tipo de etiquetado, aunque la propia NN/g sí plantea la necesidad de revelar el carácter ficticio de un proyecto formativo.
Qué quitar de un portfolio si ya está montado
Si ya hay varios proyectos formativos en un portfolio, existe un conjunto de comprobaciones aparte para ellos. Interaction Design Foundation enumera errores habituales que devalúan incluso un trabajo sólido: dedicar tiempo a detalles secundarios como un logotipo personal en lugar de a los propios casos; la falta de selección, cuando todo entra en el portfolio en vez de una selección curada de los mejores trabajos; usar una plantilla ya hecha sin adaptarla al contenido; una documentación débil del proceso de decisión; y fallos técnicos habituales como un diseño responsive que no funciona, problemas de accesibilidad o erratas en el texto del caso.
Nielsen Norman Group e Interaction Design Foundation coinciden en un consejo complementario, útil ya durante el propio trabajo y no solo al limpiar un portfolio terminado: documentar el proceso sobre la marcha, antes de que se olviden los detalles. IxDF lo formula como un principio aparte —documentar todo lo posible e incluir en el caso borradores, bocetos, fotos y notas de voz—; NN/g recomienda por separado guardar cualquier material de trabajo para casos futuros. Aun así, los casos no ganan con una prosa extensa: quienes contratan hojean el portfolio rápido, no lo leen de principio a fin. En los ejercicios con una restricción real, documentar sobre la marcha también funciona como prueba: un borrador muestra que la solución no fue la única opción evidente desde el principio.
Cómo describir los proyectos formativos en el currículum, aparte del portfolio
El currículum y el portfolio resuelven tareas distintas. Nielsen Norman Group recomienda no crear en el currículum apartados propios para proyectos concretos: el programa o los cursos realizados conviene describirlos ahí en dos o tres frases, en el lenguaje de las competencias —qué temas se estudiaron, qué herramientas se aprendieron—, mientras que los proyectos, con todos sus detalles, alternativas y estado, se despliegan en un portfolio adaptado a un lector no académico, no en un informe interno del programa.
Esta regla también vale para los tres ejercicios de este artículo: en el currículum, una línea general sobre el programa cursado o la práctica independiente y las competencias clave, y no un punto aparte sobre un caso concreto con un servicio, un logotipo o una organización. La versión completa —con la investigación, las alternativas, el estado del proyecto y la reflexión— permanece en el portfolio; quien contrata y quiera detalles lo abrirá por su cuenta.
Lista práctica
- En la descripción de cada caso, el estado del proyecto aparece en la primera frase, no escondido al final del texto.
- La restricción está formulada de forma concreta: la navegación y el diseño ya existentes de un servicio, el presupuesto de tiempo de un proyecto voluntario o el sistema visual de otra empresa, no una libertad abstracta.
- El texto del caso incluye un párrafo sobre al menos una alternativa descartada y el motivo del rechazo.
- El estado inicial del servicio o producto está registrado con una captura u otros datos antes de que aparezca la solución final en el caso.
- Ningún caso incluye una reseña de cliente, una cifra de ventas o la mención de una relación comercial con una empresa que nunca existió.
- Si el caso es un concepto de rediseño de un producto o logotipo ajeno, el estado está descrito con honestidad en la primera frase y la redacción no insinúa en ningún punto que la empresa lo encargó o aprobó; el riesgo legal de publicar el rediseño de un signo ajeno no desaparece con una sola aclaración.
- En el currículum, el programa formativo y los cursos están descritos en dos o tres frases en el lenguaje de las competencias; no hay un apartado propio para un proyecto concreto: los detalles quedan en el portfolio.
Preguntas frecuentes
¿Puedo mostrar en el portfolio el concepto de rediseño del logotipo de una empresa real sin que lo sepa?
Aquí no hay un «sí» claro. El art. 1270 del Código Civil ruso incluye la adaptación de una obra protegida y la puesta a disposición del público entre los usos que entran en el ámbito del derecho exclusivo. Por eso publicar un rediseño concreto puede requerir el permiso del titular de los derechos o apoyarse en una excepción legal aplicable; depende de qué se haya rediseñado exactamente y de si ese elemento está protegido. Los derechos de marca no se analizan aquí por separado. Son normas del derecho ruso: en otros países las reglas de protección de derechos de autor y de marcas pueden ser distintas, y conviene comprobarlas por separado. En cualquier caso, no se puede presentar el trabajo como si la empresa lo hubiera encargado o aprobado si eso no ocurrió.
¿Cuántos casos hacen falta para enviar el portfolio a la primera vacante?
Las fuentes dan rangos distintos pero cercanos: Nielsen Norman Group recomienda elegir entre 3 y 5 proyectos para casos detallados y subraya que el número en sí importa menos que la variedad de competencias mostradas; Interaction Design Foundation sitúa el rango orientativo entre tres y seis casos. No hay datos sobre un número que garantice una entrevista, ni por parte de la redacción ni en las fuentes consultadas.
¿Hay que decir en el currículum que un proyecto fue sin pagar o académico?
Según el consejo de Nielsen Norman Group, no conviene crear apartados del currículum para proyectos concretos: los cursos y el programa formativo se pueden describir ahí en dos o tres frases en el lenguaje de las competencias, mientras que los proyectos, con su estado, sus detalles y su reflexión, se despliegan en el portfolio. El estado —«formativo», «voluntario», «concepto de rediseño»— se indica ahí, no en el currículum.
¿Qué hacer si el único proyecto voluntario disponible no es de la especialidad en la que se quiere trabajar después?
Interaction Design Foundation recomienda elegir métodos y tipos de caso acordes al puesto objetivo y combinar formatos distintos en un mismo portfolio, en lugar de depender de un único proyecto. Si el proyecto voluntario no encaja con el perfil, la opción editorial es usarlo solo cuando muestre métodos útiles para el puesto objetivo, y reforzar el perfil del portfolio con el primer o el tercer ejercicio, más fáciles de elegir cerca de la especialización deseada.
¿Es mejor hacer un caso muy detallado o tres cortos?
Las fuentes se inclinan por la selección, no por el volumen: NN/g señala que los casos no ganan con una prosa extensa, porque de todos modos se hojean rápido, y recomienda concentrarse en uno o dos proyectos cuando falta tiempo, en vez de dispersarse. Los tres ejercicios de este artículo cubren tres tipos distintos de restricción y están pensados para desarrollar competencias diferentes, no para dispersar el esfuerzo; si de verdad falta tiempo, tiene más sentido terminar uno o dos ejercicios que empezar los tres de forma superficial.