Tu maleta,
en tres taps
— el resto ya se sabe.
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.
Nadie quiere llenar un formulario para hacer la maleta.
Tu teléfono ya sabe a dónde vas. ¿Por qué la app te lo vuelve a preguntar?
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.
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 y 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 columna de fricción es mi lectura de lo difícil que es cada paso para Sofía hoy. La última fila muestra cómo cambia con Pack.
Tres decisiones, y lo que me costó 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
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.
Dónde aparece Pack cuando la app está cerrada.
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 la Lock Screen, 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, y cómo pasa a Android.
Diseñé iOS primero porque ahí viven EventKit 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 es una decisión de APIs. 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, lo que refuerza la idea de que el sistema te conoce.
- Wear OS. Tile + complication 1:1 con Apple Watch, para 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é, en el orden en que pasaron las cosas y no como un relato prolijo.
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.
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.
Clima para leer, nunca para completar
Información que soporta la propuesta sin pedir un solo campo de formulario. El microcopy se mantiene accionable: "parcialmente nublado, sin lluvia".
Un botón, y una salida
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. 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.
Lo que nueve personas me hicieron cambiar.
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. Nueve personas no dan significancia. Me dieron patrones que se repitieron.
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.
Hacia dónde va Pack, y hacia dónde voy yo.
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
Diseñé para ActivityKit, WidgetKit y App Intents leyendo la HIG de Apple.
Figma con auto-layout, variants y design tokens; SF Symbols donde el sistema ya tiene el icono.
Edge cases como máquina de estados, WCAG AA y Dynamic Type, entrevistas 1:1. Español nativo, inglés C1.
Lo que busco
Cómo leer este caso
Armé el caso para que lo puedas escanear en 2 minutos o meterte en cualquier sección. Cada decisión sale de un hallazgo de investigación o de un trade-off que tuve que pagar. Si algo no te convence, prefiero que me lo digas antes que suponer que funciona.
¿Hablamos?
Abierto a roles UX/UI.
El archivo de Figma existe, la investigación está documentada, y puedo defender cada decisión de este caso. Si algo te interesa —o no te convence— quiero saberlo.