03 / Human-centered product design
JourneyCraft
A journey is more than an itinerary.
Co-designer & co-engineer · two-person team
How can a travel system preserve experience without overstating what it knows?
Saved ideas, itineraries, and memories can lose their connection to the same trip. JourneyCraft explores one continuous Journey record, with different interfaces for planning, traveling, and remembering.
Independent collaborative HCI project
Summer 2025–Fall 2026 · React Native / Expo / TypeScript
Completed cross-platform research prototype · not publicly released
My contribution: I co-led user research, interaction design, information architecture, implementation, and evaluation. The central design decision was to keep planned destinations, recorded experiences, and verified presence distinct.
Implemented prototype, iOS Simulator. Portfolio captures use real travel content with selected dates and identifying details adjusted for privacy and presentation.


01 / Research → design
Different moments need different kinds of attention.
Small-scale formative testing with friends and acquaintances, mainly university students and frequent travelers, used informal, task-based walkthroughs. These qualitative observations informed or reinforced design directions; they are not controlled-study findings.
When a shared travel guide becomes unreliable data.
During a formative walkthrough, a participant pasted a social-platform travel guide: a title, descriptive text, a shortened URL, and copy/share instructions. Our early Capture flow expected a clean URL and rejected it. After isolating the link, extraction sometimes mistook navigation, footer, or company text for travel items and missed day-based itinerary structure.
We redesigned and implemented Capture to extract URLs from shared text, preserve useful context, filter webpage noise, and recognize Chinese and English day-based itineraries. People can review extracted candidates before import; parser regression tests cover shared text, noisy pages, and itinerary structure.
Ambiguous place references remain an ongoing challenge. Reliable disambiguation and a complete workflow for matched places, unresolved references, and requests for confirmation are not finished; an extracted candidate must not be presented as a verified location.
ObservationIt was not always clear where a saved idea belonged.
Design decisionKeep its source and assignment visible.
Interface consequencePocket shows Journey/day context; unassigned ideas stay reusable.
ObservationRich planning information felt less useful while moving.
Design decisionGive Travel Day a lighter hierarchy.
Interface consequenceNext item, rest of today, and quick recording replace the full Planner view.
Observation“Visited” could imply more certainty than the record supported.
Design decisionSeparate different kinds of evidence.
Interface consequenceMemory distinguishes planned places, recorded Moments, and destination presence.
02 / My contribution
Make the record—and its limits—inspectable.
Structure that carries forward
We built Planner, Journey Memory, and Travel History around canonical local Journey data. I co-designed and co-engineered this continuity rather than treating each screen as an isolated artifact.
Evidence before inference
Memory keeps planned places separate from places named in Moments. History reports counts with denominators and suppresses ambiguous patterns. Presence verification concerns the destination; it does not prove every planned stop was visited.
Ownership with visible consequences
Walkthroughs also reinforced clearer Delete and Restore consequences. Previewing changes and requiring typed confirmation makes ownership an interaction decision. The archive needs no mandatory account; optional maps and search use network services.
Verify what the prototype does
Engineering evaluation combined unit/source-contract tests with release-candidate QA on the iOS Simulator and an Android emulator, including backup → delete → restore and large-text behavior. These checks establish prototype behavior, not adoption or representative usability outcomes.
This two-person prototype does not use a language model or generate prose. The screen selector shows actual captures, not a live app.
Implemented prototype screens / Memory · History · Pocket



03 / Outcome & reflection
Trust depends on what the interface declines to claim.
Recheck a plausible explanation
Large-text clipping initially looked like a text-selection defect. A clean re-run rejected that explanation: stale layout measurements and fixed containers were responsible. Remeasuring affected screens and allowing flexible sizes addressed the audited layouts.
The work made restraint a concrete design responsibility: a richer-looking history is less useful if its labels overstate the evidence. I would next evaluate comprehension over repeated real trips—especially whether people distinguish an itinerary from a record—without treating these formative walkthroughs as longitudinal validation.