Ignacio Morisson
Estos son los proyectos de product design y UI/UX en los que he trabajado.
Proyectos
Ignacio Morisson
Postgrado en UX Product Design y tres años de experiencia en producción gráfica para museos de todo el mundo: una combinación que me da visión de sistemas y comprensión real de los constraints de fabricación. Portfolio centrado en AI-UX — research propio, patrones de interacción documentados y sistemas de diseño completos.
Experiencia
- Maquetación y producción de materiales gráficos para museos de todo el mundo.
- Diseño de piezas manteniendo coherencia visual entre versiones impresa y digital.
- Gestión de artes finales: márgenes, sangrados, perfiles de color y verificación preimpresión.
- Clases de programación para niños de 6 a 12 años (HTML, CSS, lógica).
- Adaptación de contenidos según grupo y nivel.
- Diseño para rotulación, branding y preparación de artes finales para clientes.
Habilidades
Idiomas
Formación
Munch
Un compañero de IA para los momentos del viaje que no salen como se planearon. Diseñé para los pocos minutos que cambian todo, no para el uso diario.
La historia con la que empieza este proyecto
Mery Caldass dice esa frase llorando en un aeropuerto. Acababa de ser denegada en un embarque a Puerto Rico junto a su pareja. Había preguntado a ChatGPT si necesitaba visa. ChatGPT le dijo que no. Era técnicamente cierto — los españoles no necesitan visa para entrar en territorio estadounidense — pero ChatGPT omitió que el Visa Waiver Program requiere haber tramitado un ESTA antes de viajar. El viaje se les arruinó por una respuesta confiada pero incompleta.
El vídeo se hizo viral. Y la frase es un resumen perfecto de un problema más grande: durante un viaje, millones de personas confían cosas importantes a un sistema que está diseñado para sonar siempre seguro, falle o no.
Empecé este proyecto preguntándome qué pasaría si una persona como Mery hubiera tenido al lado, durante ese momento, un agente diseñado para ser honesto cuando no sabe.
Cómo la research me obligó a cambiar de producto
La hipótesis con la que entré
Después del análisis competitivo, entré con esta hipótesis: los viajeros urbanos que viajan 2-5 veces al año por placer experimentan un agujero estructural entre "todo está reservado" y "el viaje sale bien". Lo cubren manualmente con un patchwork de ChatGPT + Google Maps + Reddit + apps de safety + recepción del hotel, perdiendo tiempo y presencia en el proceso.
Era una hipótesis razonable. El análisis competitivo la respaldaba: 11 productos del espacio, ninguno fusiona contexto del viajero + tiempo real + síntesis local + proactividad calibrada. Los AI travel agents (Layla, Mindtrip, Wonderplan) mueren después de la reserva. Las apps de safety (Sitata, GeoSure) son rules-based y ruidosas. ChatGPT alucina con consecuencias reales — el caso de Mery es un ejemplo entre muchos.
El criterio que fijé para validar la hipótesis: si al menos la mitad de los respondentes de la encuesta reportaba "ojalá hubiera tenido mejor información durante el viaje", el problema era real.
Lo que dijeron los datos
26 respuestas. La gente describió sus viajes con palabras como genial, espectacular, perfecto, increíble. Y a la pregunta "¿qué te gustaría que fuera distinto en tu próximo viaje?", la respuesta dominante fue "Nada".
Pero los datos contaban otra historia
Cuando miré las respuestas con más detenimiento, el panorama cambió:
Las disrupciones son reales y serias. Vuelos cancelados sin aviso. Robos con rotura de coche. Un tifón en Sri Lanka donde "Google Maps no mostraba la situación de las ciudades". Tours "sin colas" que tenían colas kilométricas. Un amigo con la rodilla rota en un hospital de Japón con barrera idiomática y el seguro a gestionar en paralelo.
Las únicas historias de viaje que la gente cuenta espontáneamente son de disrupciones. Nadie cuenta los momentos buenos con detalle; todos recuerdan vívidamente cuando algo se torció.
El problema no era crónico. Era agudo. La gente no siente un déficit diario de información durante el viaje. Pero cuando algo se rompe, la resolución es solitaria, mediocre y a veces cara. Y como acaba resolviéndose, el viaje se recuerda como bueno: la molestia se olvida bajo el "al final salió bien".
El reframe
El producto pasó de ser "compañero conversacional 24/7" a ser el recurso que te alegra haber tenido cuando el viaje se rompe — y que el resto del tiempo está callado. Lo llamé internamente "emergency room, not gym".
Lo que esto me enseñó
Que las hipótesis bien escritas se construyen para poder romperse. La mía se rompió tal cual estaba formulada, y eso me llevó a una pregunta mejor: si la gente no percibe un problema cotidiano, ¿en qué se justifica este producto? La respuesta — momentos agudos, mal resueltos, recordados — me dio un producto más concreto que el que tenía antes.
Un proyecto donde la research sólo confirma lo que ya pensabas aporta poco. Este es el contrario: la research me obligó a cambiar el planteamiento, y el producto quedó mejor por ello.
Munch — un agente que sólo aparece cuando importa
El momento hero
Marta cena en una terraza en Príncipe Real, Lisboa. Su vuelo de vuelta a Madrid es mañana a las 13:00. A las 21:18, su móvil vibra:
Lee. Decide. Vuelve a la conversación. Sin abrir cinco apps. Sin pánico. Sin perder el momento.
Si el producto no puede producir ese tipo de momento de forma consistente, no hay producto. Esa escena es la referencia que guía el resto de decisiones.
Los seis patrones AI-UX que construí
Cada uno resuelve un fallo concreto de cómo los productos de IA actuales manejan información y autoridad.
La pantalla más usada del producto
El 90% del tiempo, el producto está callado. La pantalla de Home no es un dashboard de información — es Munch en estado de reposo y un input conversacional, esperando. La calma es un componente diseñado, no la ausencia de diseño. Si esta pantalla no transmite "estoy aquí pero no te molesto", el producto se siente otra app más de viajes.
Las cuatro tensiones que el proyecto contiene
Todo proyecto tiene tensiones. Lo que importa es nombrarlas y decidir con la vista puesta en ellas, en vez de fingir que no existen. Estas son las cuatro que marcaron las decisiones del producto.
Tensión 1 — "Emergency room" vs "daily companion"
La research dice que la gente sólo necesita el producto raramente. Pero un producto que vive sólo en los momentos de crisis tiene un problema fundamental: el usuario no sabe que está ahí hasta que lo necesita. Para entonces, aprenderlo es demasiado tarde.
Diseñé una interfaz conversacional cotidiana — la capa Foundation — para resolver esto: el usuario abre el producto cuando todo va bien, para preguntas pequeñas, y construye familiaridad con Munch. Cuando llega la disrupción, el agente ya no es un desconocido. La confianza que se necesita en el momento agudo se construye en los momentos tranquilos.
Es una apuesta. La research no la valida. En una v2 mediría si los usuarios abren el chat fuera de crisis. Si no lo hacen, esa capa se reduciría a un mecanismo de descubrimiento al inicio del viaje.
Tensión 2 — Munch vs distribución B2B2C
La research mostró que 25 de 26 nunca pagaron por una app de viajes premium. Pero sí pagan por tours, eSIM, seguro de viaje y transfers — por "tranquilidad" y "seguridad". El modelo de negocio recomendado pivotó de suscripción directa a partnership con seguros de viaje (Allianz, AXA, Mapfre).
Distribuirse como servicio incluido dentro de un seguro suele implicar neutralizar la marca. Munch, con una identidad fuerte, va en dirección contraria a ese patrón.
Dejé el planteamiento abierto a dos lecturas: o Munch es el activo licenciable que humaniza un servicio de seguros frío ("Allianz Travel Assistance, powered by Munch"), o se mantiene una estrategia de marca dual con una versión white-label para B2B2C. Cualquiera de las dos necesita conversaciones reales con aseguradoras para confirmarse.
Tensión 3 — Diseñar en detalle con una muestra pequeña
La muestra fue de 26 personas, todas en España, con sesgo hacia familia y pareja y sólo 3 viajeros solos. La persona de diseño que definí (32-38 años, solo o en pareja, viajero internacional con experiencia de disrupciones) no está representada en la muestra.
Producir cientos de líneas de wireframe con copy exacto sobre esa base se puede leer como afirmar demasiado. Lo asumo y lo defiendo: las specs detalladas no son una afirmación de que el producto es correcto; son una propuesta coherente que se puede testear. Sin specs concretas, no hay nada que probar. Diseñar vago para "no comprometerse" acaba en un caso de estudio que no dice nada.
Tensión 4 — Portfolio scope vs product scope
Para un portfolio Senior, 12 pantallas con detalle pueden ser excesivas. Los estudios que están contratando ahora muestran menos pantallas con más profundidad. Para un producto, 12 pantallas son razonables.
Resolví con curaduría: este case study lidera con 4 pantallas hero (D3 Action card, E3 Dry-run, C3 "no lo sé" honesto, B1 Home tranquilo) más un flujo completo. El resto del material está a un click, para quien quiera bucear.
El portfolio no es el archivo del proyecto. Es la versión curada del proyecto para una audiencia concreta.
Munch — diseñar un mascot que NO es Duolingo
El agente conversacional necesitaba una identidad. Decidí que fuera un personaje — un oso. La motivación: el oso funciona como figura de protección y guardián, no sólo de ternura. La idea de "alguien que te cubre las espaldas" encaja con la promesa del producto después del reenfoque.
Por qué no era obvio que tener un mascot fuera correcto
Los productos AI actuales no tienen cara: ChatGPT es anónimo, Google Gemini es neutro, Sitata es clínico. Se puede leer como una norma del sector que conviene respetar. Otra lectura: precisamente porque ninguno tiene cara, un personaje fiable es diferenciación real, no decoración.
El riesgo y su resolución
El producto aparece en los peores momentos del viaje. Un oso demasiado mono en ese momento no encaja — rompe la confianza justo cuando más se necesita. Ese era el fallo que tenía que evitar.
La resolución fue diseñar a Munch como la traducción visual del principio "Calibrate, don't alarm". Su rango expresivo es estrecho a propósito — sólo 5 estados. Y cuando la escala de urgencia del producto sube en intensidad (Info → Heads-up → Action), Munch baja en agitación. En una alerta Action, cuando el problema es serio, Munch aparece en su estado más sereno: firme, presente, sin gesto añadido.
El personaje transmite, sin necesidad de texto, que la situación está bajo control.
La referencia a Duolingo y por qué hay que matizarla
El primer impulso fue "como el búho de Duolingo". Pero esa referencia hay que separarla en dos.
De Duolingo se toma la gramática de construcción: primitivas geométricas simples, flat, bold, mínimo, silueta reconocible a cualquier tamaño, pensado para animarse desde el día uno. Encaja perfecto con el sistema visual.
De Duolingo se deja fuera la personalidad: caótica, pasivo-agresiva, culpabilizadora, sin freno. Eso funciona para hábitos y rachas. No funcionaría para un compañero de confianza y seguridad. Si Munch actuara como el búho de Duolingo, se rompería la idea del protector sereno.
La síntesis: construcción tipo Duolingo, temperamento opuesto. Mismo rigor de sistema, alma contraria.
El nombre
Munch. Sonido calmado y contenido — un oso munching bayas es la imagen de un oso satisfecho, no ansioso. Corto, fácil de recordar, funciona en español e inglés. Como referencia interna: Edvard Munch (El Grito). El personaje del cuadro que grita pasa a ser el oso que nunca se altera. Es una ironía intencional.
Lo que no resolví — y lo que validaría en v2
Estas son las cosas que no llegué a resolver. Prefiero declararlas sin maquillar.
El sample de research no representa a la persona de diseño. 100% España, sesgado a familia/pareja, sólo 3 viajeros solos. Mis decisiones sobre el viajero solo internacional están construidas sobre nada empírico. La primera tarea de un v2 es una ola de research dirigida específicamente a ese perfil.
El modelo de negocio (partnership con aseguradoras) está sin validar. Tres conversaciones con product partnerships de Chapka, IATI y AXA darían la respuesta sobre si el producto puede vivir bajo su distribución, y bajo qué condiciones de marca. Hasta entonces, "Munch como activo licenciable" es una apuesta razonada, no una decisión validada.
La personalización demográfica es la parte más débil del MVP. Sólo 5 de 26 reportaron preocupación de seguridad, y ninguno era del perfil para el que este patrón está pensado (mujer sola, LGBTQ+ en destino conservador, persona vulnerable). El patrón "Context cards" se diseña, pero su demanda no está probada.
La hipótesis "emergency room" valida a través de comportamiento real es lo que más importa medir post-lanzamiento. La métrica norte ya no es engagement diario — es "estuvo ahí cuando se le necesitó" + "vuelve en el siguiente viaje".
El propio acto de diseñar 12 pantallas para un producto que se usa raramente es una tensión que sólo se resuelve con datos de uso. Si los usuarios reales nunca abren el chat fuera de crisis, hay material para podar.
Qué me llevo de este proyecto
Tres cosas, en orden creciente de importancia.
Si este proyecto se desarrollara más allá del case study
Realizaría las siguientes cuatro cosas, en orden:
- Una segunda ola de research dirigida a la persona de diseño faltante.
- Tres conversaciones con product partnerships de aseguradoras.
- Un prototipo funcional en Figma Make con el flujo de disrupción jugable end-to-end.
- Una pieza de animación en Rive de los 5 estados de Munch.
