Your suitcase,
in three taps
— the rest is known.
You have a flight on Thursday. Pack already knows — it read your Calendar, checked the weather in Rome, and built a packing list. You pick your luggage size. That's it.
Nobody wants to fill a form to pack.
Your phone already knows where you're going. Why is the app asking again?
Every packing app I tried followed the same pattern: fill in your destination, dates, trip type, and luggage before seeing a single useful item. The input always exceeded the immediate value. And because generic lists don't consider context, people overpack, which is a rational response to the fear of forgetting.
The phone infers.
The user confirms.
Pack reads the Calendar event, checks the weather, and proposes a list. The user only makes two decisions the system can't infer: trip type and luggage size. Zero forms. Three taps. The list learns from every edit, silently and without setup.
The problem wasn't the apps.
It was how they ask.
I wanted to understand something specific: why do frequent travelers keep using Notes to pack when there are dozens of packing apps? Six interviews and thirty survey responses gave me a clear answer.
"Packing apps ask for so much before giving you anything, that I end up opening Notes and writing by hand instead."
"When I travel for work I don't want to think — I need it to just be done."
Context
1 trip per month. 2 days' notice on average. Mixes client meeting + formal dinner + tourism on the same trip.
Needs
An initial proposal she can confirm in less than 60 seconds. That understands the business + casual duality.
Frustrations
Setup that asks for airline, hotel, city, dates → drops off. Re-entering data that's already in Calendar.
Three days before a trip to Rome
Each row is a real moment reconstructed from the interviews. The friction column is my reading of how hard each step is for Sofía today. The last row shows how it changes with Pack.
Three decisions, and what each one cost me.
Before drawing a single screen, I had to answer three questions that would define the product. Each one has a real cost, and I chose to pay it.
Infer from Calendar before asking anything
The first data Pack gets is the trip event in Calendar: destination, dates, duration. The user never fills out an initial form. The zero screen already shows the detected trip.
Luggage type as the only explicit input
Luggage (backpack / 10kg cabin / 23kg suitcase / large suitcase) is the only variable the system can't infer and that most changes the list. It's asked explicitly because the cognitive cost is low and the impact on the proposal is high.
The list is a proposal, not an order
Items that get deleted stop appearing in similar trips. Items that get added become defaults on their own. On-device learning, no setup required.
Where Pack shows up when the app is closed.
A packing app that only works when you open it isn't solving the real problem. I designed Pack to show up in the lock screen, the home screen, and Siri — where the traveler actually is.
Live Activity on the Lock Screen, without opening the app.
Pack starts a Live Activity 8 hours before the flight (API limit) and keeps it alive with push updates. Shows pending items, weather, and countdown. The activity closes at T+0 when the trip begins. For the days prior to the 8h cap, Pack uses a Lock Screen Widget: same info, different surface.
- API
- ActivityKit · ActivityAttributes
- Trigger
- T-8h before the Calendar event
- Updates
- Push for critical weather + every 30 min
- Covers
- Show up when it matters
Three states,
the same persistent information.
The Live Activity adopts the three Dynamic Island sizes by context: compact while navigating, expanded on long-press, minimal when another app claims the slot. The user sees the trip status without opening Pack.
- Compact
- Destination + time remaining
- Expanded
- Progress + pending items
- Minimal
- Brand identity only
- Tap
- Opens the list on the main screen
Four sizes,
one principle: glance and go.
Widgets in small, medium, and large + complication for Lock Screen. Each one follows the same principle: the most relevant info about the active trip, without opening the app. Updates via TimelineProvider every 15 min. Smart Stack rotation support so Pack rises to the top when there's an active trip.
- Small
- Progress + countdown
- Medium
- Active list with checkboxes
- Large
- List + weather + actions
- Lock screen
- Inline complication
One voice command
builds the whole list.
Pack exposes three App Intents to the system: PreparePackingIntent, CheckListIntent, AddItemIntent. They work from Siri, Spotlight, Shortcuts, and the iPhone 15 Pro Action Button. Responses are audible, visual, and actionable.
- Intent 01
- Pack my suitcase
- Intent 02
- What am I missing?
- Intent 03
- Add X to the list
- Surfaces
- Siri · Spotlight · Action Button
Why iOS first, and how it moves to Android.
I designed iOS first because that's where EventKit and WeatherKit live natively. Android gets the same core logic with Material You surfaces — but the detection engine is the same.
The chronological decision
iOS first is an API decision. Five native APIs make the product: EventKit (unified Calendar), WeatherKit (weather), ActivityKit (Live Activity), Dynamic Island, App Intents. Android has equivalents but with technical differences that justify validating the model on iOS before porting.
- Live Activity ↔ Persistent notification. Android handles ambient presence with a foreground notification, less visually integrated.
- Action Button ↔ Quick Settings tile. On Android, the notification panel replaces the physical button.
- Material You. Pack themes dynamically from the wallpaper, which reinforces the idea that the system knows you.
- Wear OS. Tile + complication 1:1 with Apple Watch, for cross-device parity.
How I got to these screens.
And the system that holds them up.
This section is the messy truth: how the project actually evolved, which ideas survived, and which ones I killed, in the order it happened rather than as a tidy narrative.
From interview to pixel
Each stage produced decisions that survived to the final version. I didn't jump from research to a pretty screen.
36 quotes from 6 interviews grouped into 8 pain-point clusters. Three dominant ones: ignored context, overpacking, setup friction.
I tried 12 layouts for the detection screen before touching Figma. The version that survived showed weather as passive data, not as input.
Lo-fi in Figma to validate hierarchy and tab structure. Tested 3 variants; the single-CTA one won against the ones offering 3 options.
Token system applied. Editorial typography + native-iOS UI. Every wireframe element survives in place: hierarchy didn't change, only the visual language.
The eyebrow declares the source
"Trip detected · via Calendar" earns trust in less than a second. That label matters: it makes explicit why the app knows what it knows and reduces suspicion.
Minimal trip card, one row per data point
Origin → destination, date, duration, flight. Everything needed without visual overload. IATA code for precision.
Weather you read, never fill in
Information that supports the proposal without asking for a single form field. The microcopy stays actionable: "partly cloudy, no rain."
One button, and a way out
Pack the suitcase or say it's not your trip. Zero branches. One screen, one goal: confirm and move forward.
What happens when something doesn't happen
A system that infers fails with more nuance than one that asks. Each case has a predictable response, not a generic error.
Color · palette
Typography · scale
Components · core
Accessibility
- WCAG AA contrast in light + dark
- Dynamic Type · 17-53px
- VoiceOver labels on custom icons
- Reduce Motion respected
- Tap targets > 44×44pt
The full flow. Tap through it.
Pick a trip type and luggage size — the list adapts. Tap items to pack them, swipe left to remove and teach Pack. Add custom items to any category.
What nine people made me change.
I tested with 9 people in 3 rounds. Not enough for statistical significance — more than enough to catch the patterns that changed the design. Here's what I found and what I did about it.
3 rounds, 3 users each
Moderated test in Figma with an interactive prototype. Each task was recorded and transcribed. Nine people don't give significance. They gave me patterns that repeated.
Limitation · non-probabilistic sample. Findings are indicative.
What we learned · what changed
F1 · Auto-detection drives instant adoption
F2 · "Cabin" without context caused doubt
F3 · They wanted to preview before confirming
F4 · Live Activity didn't activate on its own
How to tell
if Pack is working.
A north-star metric with a precise operational definition, leading metrics that predict it, and lagging metrics that confirm it. Targets are aspirational and need to be tuned with real data from the first month.
Captures the full pipeline: detection → configuration → generation → completion. If this rises, the flow works end-to-end.
"Completed trip" = trip with ≥80% of items checked off at T-2h before the flight.
Initial target: 60% (aspirational, no real baseline).
Refine with: first month of post-launch data.
Where Pack goes, and where I'm going.
Where Pack goes from here, and where I come from. If you read this far, I'd love to hear what you think.
Phase 1 · validate.
The product you're seeing. Calendar detection, proposal, edit, Live Activity, widgets, Siri intent. Hypothesis: users prefer an inferred proposal over a manual setup.
Phase 2 · scale.
Multi-persona within a trip (family). Local NLP for ambiguous destinations. Pack+ with €2.99/mo subscription. Start of the native Android port.
Phase 3 · go deeper.
Wardrobe integration: Pack moves from generic items to recommending specific garments. Requires a model of the user's clothes (camera or manual entry). Risk: closet onboarding can introduce friction that contradicts the product DNA.
Tools and practices
I designed for ActivityKit, WidgetKit and App Intents reading the Apple HIG.
Figma with auto-layout, variants and design tokens; SF Symbols where the system already has the icon.
Edge cases as a state machine, WCAG AA and Dynamic Type, 1:1 interviews. Spanish native, English C1.
What I'm looking for
How to read this case
I structured this case so you can skim it in 2 minutes or dig into any section. Every decision traces back to a research finding or a trade-off I had to make. If something doesn't convince you, I'd rather hear about it than assume it works.
Want to talk?
Open to UX/UI roles.
The Figma file is real, the research is documented, and I can defend every decision in this case. If any of it interests you — or doesn't convince you — I'd like to hear about it.