Un portafolio que vale la pena no es una galería de pantallas bonitas. Es una prueba de que entiendes un problema, eliges una meta realista, diseñar un flujo claro y compruebas si la gente puede completar la tarea en poco tiempo y con pocos errores. Antes de pensar en colores, define el contexto: quién es el usuario, qué intenta lograr y qué le estorba hoy. Luego fija una métrica simple que puedas mover en días, no en meses: tiempo de tarea, tasa de finalización, fricción en un paso concreto. Con ese marco, cada artefacto tiene un porqué: mapa de contenidos que reduce dudas, wireframes que ordenan decisiones, prototipo que se puede tocar y guion de prueba que evita opiniones sueltas. Cuando un revisor ve ese orden, entiende que sabrás trabajar con negocio y con desarrollo, y que no dependes de la inspiración del día.
Si vienes de cero, puedes construir dos casos completos en 30 días si usas un ritmo constante y mides lo que haces. Elige retos cercanos a tu vida, porque podrás observar a personas reales sin pedir permisos complejos. Por ejemplo, un servicio local con colas y dudas en su web, o una app con registro torpe. Divide tu mes en cuatro semanas y dales foco: descubrimiento, estructura, pruebas, mejora y empaquetado. Si quieres una guía que te ayude a convertir esa rutina en hábitos claros, es útil adoptar prácticas de un curso ui ux que baja a tierra el proceso con ejercicios de investigación, wireframes y micro tests, y que te obliga a contar lo que cambió, no solo a mostrar el “después”. El enlace entre método y entrega concreta es lo que transforma trabajo suelto en una historia que alguien quiere leer hasta el final.
Caso 1 – Rebuild de un servicio local con colas y confusión
Elige un servicio que uses cada mes: pedir turno en un centro de salud, pagar un recibo, reservar cancha. Observa a cinco personas intentarlo: cuánto tardan, dónde dudan, qué textos generan preguntas. Con eso, escribe un problema específico y una meta corta, por ejemplo: “Reducir el tiempo para pedir turno de 4 a 2 minutos, en móvil, sin soporte externo”. Mapear la ruta mínima: llegada, elección del servicio, confirmación, comprobante. Pasa a wireframes de baja fidelidad y evita adornos. Tu objetivo es que una persona que nunca vio el flujo llegue al final con el menor número de pasos. Construye un prototipo clicable y prepara un guion simple: “Reserva un turno para la próxima semana y guarda el comprobante”. Mide tiempo, errores y frases de duda en voz alta. Ajusta textos, tamaño de objetivos táctiles y orden de campos; repite con dos personas nuevas para validar.
- Entregables del caso 1: definición del problema y métrica, flujo en 4–5 pasos, wireframes de baja fidelidad, prototipo clicable, resultados de 5 pruebas con cambios aplicados.
En el empaquetado, no te limites a poner capturas. Muestra el “antes y después” con números sencillos: tiempo medio, tasa de finalización y dónde bajó la fricción. Explica por qué rechazaste opciones bonitas que sumaban ruido y cómo priorizaste claridad sobre efectos. Si usaste textos más directos, di qué versión funcionó mejor y por qué. Si moviste un botón, cuenta qué gesto buscaba la gente por intuición. Esa manera de hablar de decisiones convence más que cualquier maqueta con sombras perfectas, porque muestra criterio y respeto por el tiempo de las personas que usan el servicio.
Caso 2 – Registro en una app: de tres pantallas confusas a un paso claro
Busca una app que pida demasiados datos al inicio o que esconda errores. De nuevo, observa a cinco personas crear una cuenta. Señala dónde se pierden: etiquetas vagas, validación tardía, campos que no se ven en pantalla. Redacta el objetivo: “Aumentar la tasa de finalización del registro del 60% al 85% en móviles de gama media”. Simplifica la entrada de datos: cuestionario en pasos, progreso visible, teclado acorde a cada campo y ayudas en contexto para errores, cerca del lugar donde ocurren. Usa un tono humano en los mensajes y evita frases técnicas. Mantén una acción primaria por pantalla y un camino de vuelta seguro si algo falla. La idea es que la persona siempre sepa qué pasa y qué sigue, sin acertijos.
Al testear, pide la tarea “Crea tu cuenta y llega al panel” y guarda silencio. Si alguien tarda más de lo esperado, anota dónde miró y qué tocó. Cambia lo que frena: eleva contraste, agranda objetivos táctiles, ordena el foco del teclado y hace visibles los requisitos antes de enviar. Vuelve a medir con dos o tres personas nuevas, en distintas luces y con datos reales. Presenta tu caso con una secuencia clara: problema, hipótesis, prototipo, evidencia y mejora. Incluye un cuadro simple con tiempos y tasa de éxito antes y después, y añade dos citas reales de usuarios (breves, sin adornos). Ese cierre deja claro que no “pintaste” pantallas: resolviste un bloqueo concreto que impacta a negocio y a personas.
Cómo contar los dos casos para que te llamen
Un revisor tarda pocos minutos en decidir si sigue leyendo. Ayúdale con estructura. Empieza cada caso con una frase de negocio, una meta medible y un límite de tiempo. Sigue con el flujo en cinco pasos como máximo, con dos o tres pantallas clave por fase. Después, enseña el test: a quién viste, qué tarea y qué mediste. Cierra con cambios y números. Evita textos largos que repiten obviedades; usa frases cortas y verbos claros. Si incluyes vídeo corto del prototipo en uso (sin música, sin filtros), mejor. Y si algo importante salió mal y lo arreglaste, cuéntalo: muestra cómo reaccionas ante problemas reales. La honestidad pesa más que el brillo.
En la portada del portafolio, no pongas slogans. Di quién eres, qué problemas te gusta resolver y qué haces bien: ordenar flujos, escribir microcopias que eliminan dudas, probar con usuarios y ajustar rápido. Añade un enlace a tu proceso, no solo a resultados. Deja claro que puedes trabajar con límites: tiempo, dispositivos baratos, redes lentas. Muchos equipos necesitan eso, no un “todo es posible”. Da acceso al archivo del prototipo y al guión de prueba; permite que quien evalúa reproduzca tu ruta. Esa transparencia te da confianza y te distingue de quien muestra “mockups” sin contexto.
Lo que haces esta semana para tener dos casos listos
Elige un servicio cercano y una app con registro. Bloquea cuatro sesiones de trabajo entre semana y dos más el fin de semana. Día 1: observación y definición del problema con una métrica. Día 2: mapa de contenidos y flujo corto. Día 3: wireframes y primer prototipo. Día 4: pruebas con cinco personas y lista de fricciones. Día 5: ajustes y segunda mini-validación. Día 6: empaquetado del caso 1 con números y capturas. Día 7: repite el ciclo con el caso 2, pero más rápido porque ya dominas la rutina. Cierra el domingo con una portada sencilla que explique en qué aportas valor y con enlaces a los prototipos. Con orden y constancia verás que no necesitas permisos especiales ni clientes reales para demostrar nivel: necesitas proceso, respeto por el tiempo de las personas y la disciplina de medir lo que cambia cuando mejoras una interfaz. Esa es la señal que un equipo busca cuando decide a quién escribir primero.