Problem, approach, outcome
01Problem
A long trip's details end up scattered across email confirmations, booking sites, a planning doc and a task list. The hard part isn't storing them — it's seeing at a glance whether every night has a bed, which day is the long drive, and what still needs doing before a deadline passes.
02Approach
Model the trip around nights and legs rather than a flat list of events. Every day knows which bed it ends in, so a timeline can show where you are, where you sleep, the car and each travel day as parallel lanes — and a missing night stands out immediately. A route view on the map draws the trip in day order, in the same colours. Time-sensitive items — permits, check-in deadlines, time-zone traps — are pinned above everything else.
For the public version, a build script assembles the demo from an approved file list and refuses to ship if any real name, trip or confirmation number gets in.
03Outcome
As a planning tool, it did its job: laid out on a timeline, the trip's gaps, deadlines and still-unplanned days were easy to spot, and it helped me find and close them before leaving.
On the road, a Google Doc won — not on design, but on access. The doc was on my phone and quick to edit; TripBase lived on my laptop, and by then parts of it had gone stale or were still open-ended. I wanted TripBase's visual layout, but I settled for the simplicity of the doc. The lesson is plain: a trip tool is only as useful as it is current and within reach.
So TripBase continues as three things: a portfolio piece, an experiment in UX and UI, and a product idea that may have legs — one that lives on your phone, stays current, and maybe keeps itself up to date by working alongside an AI assistant on the next trip.