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.

JourneyCraft Planner showing the Valletta day plan, map, date rail and unplaced Pocket ideas.
Plan / Arrange the day.
JourneyCraft Travel Day prioritizes the next item, Colosseum at 09:30, and the rest of the Rome itinerary.
Travel / Bring the next action forward.

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.

ObservationDesign decisionInterface consequence

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

Journey Memory distinguishes 16 planned places, four recorded Moments and destination presence verification in the Italy and Malta archive.
Memory / The plan remains distinct from named places in Moments; presence is stated separately.Open full-size
Travel History summarizes completed Journeys using explicit counts with denominators and a separate presence-verification statement.
History / Counts keep their denominators. Patterns are factual summaries, not personality labels.Open full-size
Pocket ideas retain their original source and show whether they belong to a Journey or a specific day.
Pocket / An idea keeps its provenance and Journey/day context; unassigned ideas remain reusable.Open full-size

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.