Tenés un vuelo el jueves. Pack ya lo sabe — leyó tu Calendario, chequeó el clima en Roma, y armó una lista de equipaje. Vos elegís el tamaño de la valija. Eso es todo.
El problema y la respuesta,
en una vista.
Todas las apps de equipaje que probé me hacían llenar formularios antes de mostrarme un solo item útil. Quise ver qué pasa cuando el teléfono ya sabe a dónde vas.
Todas las apps de equipaje que probé seguían el mismo patrón: completá tu destino, fechas, tipo de viaje y equipaje antes de ver un solo item útil. El esfuerzo de entrada siempre superaba el valor inmediato. Y como las listas genéricas no consideran el contexto, la gente empaca de más — que es la respuesta racional al miedo de olvidarse algo.
Me quedé pensando: tu teléfono ya sabe a dónde vas. ¿Por qué la app te lo vuelve a preguntar?
El teléfono infiere.
El usuario confirma.
Pack lee el evento de Calendar, consulta el clima, y propone una lista. El usuario solo toma dos decisiones que el sistema no puede inferir: tipo de viaje y tamaño de equipaje. Cero formularios. Tres taps. La lista aprende de cada edición — en silencio, sin setup.
El problema no eran las apps.
Era cómo preguntan.
Quería entender algo específico: ¿por qué los viajeros frecuentes siguen usando Notas para empacar cuando hay decenas de apps de equipaje? Seis entrevistas y treinta respuestas de encuesta me dieron una respuesta clara.
"Las apps de equipaje piden tanto antes de darte algo que acabo abriendo Notas y escribiendo a mano."
"Cuando viajo por trabajo no quiero pensar — necesito que esté hecho."
Contexto
1 viaje al mes. 2 días de aviso de media. Mezcla reunión con cliente + cena formal + turismo en el mismo viaje.
Necesidades
Una propuesta inicial que pueda confirmar en menos de 60 segundos. Que entienda la dualidad business + casual.
Frustraciones
Setup que pide aerolínea, hotel, ciudad, fechas → abandona. Volver a introducir datos que ya están en Calendar.
Tres días antes de un viaje a Roma
Cada fila es un momento real reconstruido de las entrevistas. La barra muestra la fricción cognitiva — lo difícil que es cada paso para Sofía hoy. La última fila muestra cómo cambia con Pack.
Tres decisiones que definen el producto.
Y el coste de cada una.
Antes de dibujar una sola pantalla, tuve que responder tres preguntas que iban a definir el producto. Cada una tiene un costo real — y elegí pagarlo.
Inferir desde Calendar antes de preguntar nada
El primer dato que obtiene Pack es el evento del viaje en Calendar — destino, fechas, duración. El usuario nunca rellena un formulario inicial. La pantalla cero ya muestra el viaje detectado.
El tipo de equipaje como único input explícito
El equipaje (mochila / cabina 10kg / maleta 23kg / maleta grande) es la única variable que el sistema no puede inferir y la que más cambia la lista. Se pregunta explícitamente porque el coste cognitivo es bajo y el impacto en la propuesta es alto.
La lista es una propuesta, no una orden
Pack genera, el usuario decide. Los ítems que se borran dejan de aparecer en viajes similares. Los que se añaden se convierten en defaults por sí solos. Aprendizaje on-device, sin setup.
Cuatro integraciones nativas,
cuatro momentos del viaje.
Una app de equipaje que solo funciona cuando la abrís no resuelve el problema real. Diseñé Pack para que aparezca en la lock screen, la home screen y Siri — donde el viajero realmente está.
Live Activity en Lock Screen
el viaje aparece sin abrir la app.
Pack inicia una Live Activity 8 horas antes del vuelo (límite de API) y la mantiene viva con push updates. Muestra ítems pendientes, clima y cuenta regresiva. La actividad se cierra en T+0 cuando el viaje comienza. Para los días previos al límite de 8h, Pack usa un widget de Lock Screen — misma info, diferente superficie.
- API
- ActivityKit · ActivityAttributes
- Trigger
- T-8h antes del evento en Calendar
- Updates
- Push para clima crítico + cada 30 min
- Resuelve
- Aparecer cuando importa
Tres estados,
la misma información persistente.
La Live Activity adopta los tres tamaños de Dynamic Island por contexto: compact mientras navegas, expanded con pulsación larga, minimal cuando otra app ocupa el slot. El usuario ve el estado del viaje sin abrir Pack.
- Compact
- Destino + tiempo restante
- Expanded
- Progreso + ítems pendientes
- Minimal
- Solo identidad de marca
- Tap
- Abre la lista en la pantalla principal
Cuatro tamaños,
un principio: mirar y seguir.
Widgets en small, medium y large + complication para Lock Screen. Todos siguen el mismo principio: la info más relevante del viaje activo, sin abrir la app. Se actualizan vía TimelineProvider cada 15 min. Soporte de rotación de Smart Stack para que Pack suba arriba cuando hay un viaje activo.
- Small
- Progreso + cuenta regresiva
- Medium
- Lista activa con checkboxes
- Large
- Lista + clima + acciones
- Lock screen
- Complication inline
Un comando de voz
arma toda la lista.
Pack expone tres App Intents al sistema: PreparePackingIntent, CheckListIntent, AddItemIntent. Funcionan desde Siri, Spotlight, Shortcuts y el Action Button del iPhone 15 Pro. Las respuestas son audibles, visuales y accionables.
- Intent 01
- Prepara mi maleta
- Intent 02
- ¿Qué me falta?
- Intent 03
- Añade X a la lista
- Superficies
- Siri · Spotlight · Action Button
Por qué iOS primero,
cómo se adapta a Android.
Diseñé iOS primero porque ahí viven CalendarKit y WeatherKit de forma nativa. Android recibe la misma lógica core con superficies de Material You — pero el motor de detección es el mismo.
La decisión cronológica
iOS primero no es preferencia personal — es arquitectura. Cinco APIs nativas hacen el producto: EventKit (Calendar unificado), WeatherKit (clima), ActivityKit (Live Activity), Dynamic Island, App Intents. Android tiene equivalentes pero con diferencias técnicas que justifican validar el modelo en iOS antes de portar.
- Live Activity ↔ Notificación persistente. Android gestiona la presencia ambiental con una notificación en primer plano, menos integrada visualmente.
- Action Button ↔ Quick Settings tile. En Android, el panel de notificaciones sustituye al botón físico.
- Material You. Pack se tematiza dinámicamente desde el fondo de pantalla — refuerza la idea de que el sistema te conoce.
- Wear OS. Tile + complication 1:1 con Apple Watch — paridad cross-device.
Cómo llegué a estas pantallas.
Y el sistema que las sostiene.
Esta sección es la verdad desordenada: cómo evolucionó el proyecto, qué ideas sobrevivieron y cuáles maté. Sin narrativa lineal — solo la línea de tiempo real.
De la entrevista al píxel
Cada etapa produjo decisiones que sobrevivieron a la versión final. No salté de la investigación a una pantalla bonita.
36 citas de 6 entrevistas agrupadas en 8 clusters de pain points. Tres dominantes: contexto ignorado, empaquetado excesivo, fricción de setup.
Probé 12 layouts para la pantalla de detección antes de tocar Figma. La versión que sobrevivió mostraba el clima como dato pasivo, no como input.
Lo-fi en Figma para validar jerarquía y estructura de tabs. Probé 3 variantes — la de un solo CTA ganó frente a las que ofrecían 3 opciones.
Sistema de tokens aplicado. Tipografía editorial + UI nativa iOS. Cada elemento del wireframe sobrevive en su sitio — la jerarquía no cambió, solo el lenguaje visual.
un viaje.
El eyebrow declara la fuente
"Viaje detectado · vía Calendar" genera confianza en menos de un segundo. Esa etiqueta importa: hace explícito por qué la app sabe lo que sabe y reduce la sospecha.
Tarjeta de viaje mínima, una fila por dato
Origen → destino, fecha, duración, vuelo. Todo lo necesario sin sobrecarga visual. Código IATA para precisión.
El clima como contexto, no como input
Información que soporta la propuesta. Sin formularios. El microcopy explica: "parcialmente nublado, sin lluvia" — dato accionable.
Un CTA, una decisión
Preparar la maleta o decir que no es tu viaje. Cero bifurcaciones. Una pantalla, un objetivo: confirmar y avanzar.
Qué pasa cuando algo no pasa
Un sistema que infiere falla con más matiz que uno que pregunta. Cada caso tiene una respuesta predecible, no un error genérico.
Color · paleta
Tipografía · escala
Componentes · core
Accesibilidad
- Contraste WCAG AA en light + dark
- Dynamic Type · 17-53px
- Labels de VoiceOver en iconos custom
- Reduce Motion respetado
- Áreas de tap > 44×44pt
El flujo completo, interactivo.
Tocá y navegá.
Elegí tipo de viaje y equipaje — la lista se adapta. Tocá items para empacarlos, deslizá a la izquierda para sacar y enseñarle a Pack.
Testear poco, medir con precisión.
Hallazgos cualitativos, métricas con fundamento.
Testé con 9 personas en 3 rondas. No alcanza para significancia estadística — más que suficiente para detectar los patrones que cambiaron el diseño. Esto es lo que encontré y lo que hice al respecto.
3 rondas, 3 usuarios cada una
Test moderado en Figma con prototype interactivo. Cada tarea fue grabada y transcrita. Con n=9 no busco significancia estadística — busco patrones cualitativos consistentes.
Limitación · muestra no probabilística. Los hallazgos son indicativos.
Qué aprendimos · qué cambió
F1 · La autodetección impulsa la adopción inmediata
F2 · "Cabina" sin contexto generaba dudas
F3 · Querían previsualizar antes de confirmar
F4 · La Live Activity no se activaba sola
Cómo saber
si Pack funciona.
Una métrica north-star con una definición operativa precisa, métricas leading que la predicen y métricas lagging que la confirman. Los objetivos son aspiracionales y necesitan ajustarse con datos reales del primer mes.
Captura el pipeline completo: detección → configuración → generación → completar. Si sube, el flujo funciona de punta a punta.
"Viaje completado" = viaje con ≥80% de ítems marcados en T-2h antes del vuelo.
Objetivo inicial: 60% (aspiracional, sin baseline real).
Refinar con: primer mes de datos post-lanzamiento.
Mirando hacia adelante,
y algo sobre mí.
Hacia dónde va Pack, y de dónde vengo yo. Si leíste hasta acá, me encantaría saber qué pensás.
Fase 1 · validar.
El producto que estás viendo. Detección Calendar, propuesta, edición, Live Activity, widgets, Siri intent. Hipótesis: los usuarios prefieren una propuesta inferida a un setup manual.
Fase 2 · escalar.
Multi-persona dentro de un viaje (familia). NLP local para destinos ambiguos. Pack+ con suscripción de 2,99€/mes. Inicio del port nativo a Android.
Fase 3 · profundizar.
Integración con armario: Pack pasa de ítems genéricos a recomendar prendas específicas. Requiere un modelo de la ropa del usuario (cámara o entrada manual). Riesgo: el onboarding del armario puede introducir fricción que contradice el ADN del producto.
Herramientas y prácticas
iOS native
Diseño
Sistemas & A11y
Idiomas
Lo que busco
Cómo leer este caso
Cada decisión que ves está construida para defenderla en una entrevista — investigación, sistema, trade-offs y métricas. La estructura está pensada para que un recruiter capte la esencia en menos de 2 minutos y un senior pueda profundizar donde quiera. Trabajo con feedback temprano y prefiero iteración rápida al perfeccionismo silencioso.
¿Hablamos?
Abierto a roles UX/UI.
Si quieres ver el archivo de Figma, profundizar en la investigación o discutir cualquier decisión del caso — escríbeme. Me encantará saber de ti.