Skip to content

M7 — New trip in 3 clicks, Pailas, trip dashboard

Status: agreed · Last session: 2026-09-28

Sources: requirements.md M7, M8 · decisions.md P22 (Pailas), P24 (a trip in 3 clicks), P36, P37, A13 · founder review of the prototype, 28 Sep (screenshots: trips list with Pailas dated "Jan 1 – Jan 10, 2000", the "Create New Trip" modal).

Who and the job

  • Editor (P36; the founder at launch, agency staff later): "A group leader asked for 7 days in Kathmandu and Pokhara — give me a good starting trip in under a minute."
  • Traveller / leader browsing (later): "Show me ready-made trips I can start from."

Value

This is NepWalk's core promise: type what you want, pick a Paila, done (P24). Today "New Trip" opens a blank form (name, description, cover URL, date) — the opposite of the promise — and the Pailas sit in "My Trips" with placeholder dates from the year 2000, which looks broken.

Placement — and why

Element Where Why
New Trip Button → its own page /trips/new (no modal) Room for the input, the recommendations and a preview
Request input Large field at the top: "Where and how long? e.g. 3 days in Kathmandu" One sentence is how people ask; it drives everything below
Recommended Pailas Under the input from the start (popular first — preferences later); as the user types, the matching Pailas move to the top (GET /templates/match?q=) Something good to pick before typing a word
Create from scratch Always visible under the recommendations: "Start from scratch: " Pailas are starting points, never the only way (P26)
Paila preview Picking a Paila shows its day plan (view-only) with a right-side drawer: Paila details and the inputs to create — start date, number of people (days prefilled from the typed text) — then "Create trip" See what you get; the drawer sits quietly beside it, the inputs already there, no extra step
Pailas tab (was "Templates") Top nav; grid of Paila cards → same drawer One way to start from a Paila, wherever you are
My Pailas (was "My Templates") Sidebar; the user's custom Pailas; "Save as my Paila" on a trip adds one Reuse your own good trips (28 Sep)
Trip dashboard Tabs: Your trips · Past. "Your trips" has two sections: Upcoming (trips you created or joined) then Shared with you "All" and "Upcoming" said the same thing; sharing belongs on the dashboard

Wireframe

New trip page (/trips/new)

┌──────────────────────────────────────────────────────────────────┐
│ ← Trips                          New trip                        │
│                                                                  │
│  Where and how long?                                             │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │ 3 days in ktm                                            ⏎ │  │
│  └────────────────────────────────────────────────────────────┘  │
│  Matched: 3 days · Kathmandu                                     │
│                                                                  │
│  RECOMMENDED PAILAS                                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                          │
│  │  COVER   │ │  COVER   │ │  COVER   │   best match first,      │
│  │ Kathmandu│ │ KTM +    │ │ KTM, PKR │   then popular           │
│  │ in 3 days│ │ Pokhara  │ │ Chitwan  │                          │
│  │ 3 days ·…│ │ 7 days ·…│ │ 10 days… │                          │
│  └──────────┘ └──────────┘ └──────────┘                          │
│                                                                  │
│  ＋ Start from scratch: "3 days in ktm"  (3 empty days)           │
└──────────────────────────────────────────────────────────────────┘

Paila preview + drawer (same on the Pailas tab)

┌────────────────────────────────────────────┬─────────────────────┐
│ Kathmandu in 3 days          (view-only)   │ KATHMANDU IN 3 DAYS │
│ [Day 1][Day 2][Day 3]                      │ 3 days · Kathmandu  │
│ ┌──────┬──────────────────────────────┐    │ 11 stops · popular  │
│ │PHOTO │ 16:00 · Garden of Dreams     │    │                     │
│ └──────┴──────────────────────────────┘    │ Start date          │
│ ┌──────┬──────────────────────────────┐    │ [ 29 Dec 2026  📅 ] │
│ │PHOTO │ 19:00 · Welcome dinner       │    │ People              │
│ └──────┴──────────────────────────────┘    │ [ 12 ]              │
│                                            │                     │
│                                            │ [ Create trip ]     │
└────────────────────────────────────────────┴─────────────────────┘
Phone: the drawer is a bottom sheet, collapsed to a "Create trip" bar
until tapped.

Trip dashboard

[ Your trips ]  [ Past ]

UPCOMING
┌──────────┐ ┌──────────┐ ┌──────────┐
│  COVER   │ │  COVER   │ │  COVER   │
│ Title,   │ │ Title,   │ │ Title,   │   title: 2 lines max, ellipsis,
│ 2 lines… │ │ 2 lines… │ │ 2 lines… │   full title on hover
│ 29 Dec – │ │ 5 Jan –  │ │ …        │   dates, footer: same height
│ View     │ │ View     │ │ View     │   in every card
└──────────┘ └──────────┘ └──────────┘

SHARED WITH YOU
┌──────────┐ …

States

  • Nothing typed: popular Pailas; the scratch line reads "Start from scratch".
  • Typed text with no match (e.g. "5 days in Lumbini"): "No Paila for this yet" + all Pailas below + scratch. Unknown words come back as unknown from the matcher — say which ("didn't recognise: Lumbini"), never guess.
  • No trips yet on the dashboard: one card "Plan your first trip" → /trips/new. No "Shared with you" section when there are none.
  • Create fails: the drawer keeps the inputs and shows the error.

Rules and edge cases

  • Pailas are not trips of the user: they never show in "Your trips" or "Past" (backend list leaves template trips out). Their cards show "N days · towns", never their placeholder dates (P22: day 1 = 1 Jan 2000 until a trip is made).
  • Covers: a trip card uses the trip's own image; else the first linked place's photo in the trip (with credit on hover). The three Pailas get chosen covers in their seed (Wikimedia, credited, A10).
  • Card text alignment: title clamped to 2 lines with an ellipsis (full title on hover and in title), dates and footer at fixed positions, so every card in a row lines up whatever the text length.
  • Creating from a Paila uses POST /templates/:id/trips (start date, people; days and dates shift, P24). From scratch uses POST /trips + N empty days; title = the typed text.
  • Signed-out visitors: the Pailas tab and previews follow P37 (public tier); creating needs sign-in.

Decided (28 Sep)

  • ~~New Trip is a page~~ — 28 Sep (final): New trip is its own clean page, /trips/create — no box, nothing pushed down on the dashboard (a dashboard panel was tried and dropped the same day); /trips/new redirects there. Same planner as the Pailas tab: input on top, recommended Pailas from the start (popular for now; by preferences later), best matches rise as the user types, scratch always available.
  • Pailas tab = the same planner (28 Sep): input, Pailas (yours first, with a "Yours" chip), and the dashed card "Create your own Paila" — an empty Paila with its days, saved to your Pailas (no dates asked); "Manage your Pailas" links to rename / delete.
  • Picking a Paila: view-only preview + a quiet right drawer with details and the create inputs already there.
  • Scratch: title = typed text, N empty days when the text names a number of days.
  • "Templates" becomes Pailas (NepWalk's Pailas and public ones, same drawer as New trip); "My Templates" becomes My Pailas — the user's own custom Pailas, saved from any trip they edit with "Save as my Paila" (28 Sep, replaces "My Templates leaves the sidebar"). Old /templates and /my-templates links redirect.
  • Dashboard (28 Sep, replaces "Your trips / Past"): tabs My trips · Invitations · Past. My trips = the trips you are going on — your own and invitations you accepted — each with a chip, "Your trip" or "Joined". Invitations = pending invites with Accept / Decline; accepting moves the trip to My trips. Pailas never in trip lists.
  • Sidebar (28 Sep): Shared with me, Archived and Settings leave the sidebar (sharing lives in My trips; Settings stays in the avatar menu). App header is frosted glass like the landing page.
  • No sidebar for travellers and leaders (28 Sep): they move with the top bar tabs Trips and Pailas, centred like the landing page links. The sidebar holds admin tools only (Vendors, P27) and shows to admins only; Help moves to the avatar menu.
  • Pailas tab (28 Sep): your own Pailas first ("Manage" → rename / delete on /my-pailas), then the other Pailas; "My Pailas" leaves the sidebar.
  • Covers: chosen covers for the Pailas + first-place photo for any trip without one.
  • Cards: text aligned across a row (2-line title with ellipsis, full text on hover).

TBD (next M7 session)

  1. The drawer's other information beyond date and people (preferences, included services from P24) — "we can think more later" (founder).
  2. ~~Whether the sidebar keeps "Shared with me"~~ — decided 28 Sep: removed; sharing lives in My trips.

Backlog (after launch)

  • Light and dark mode (founder, 28 Sep): today's app look is the light mode; the clickable prototype's look (docs/management/mvp/v2/prototype/, dark theme) is the dark mode and the reference for the day plan's stop cards (photo with the time chip on it, title + duration, story, "Tip ·" line), flight / travel cards ("Your flight home", icon tile, note line), the travel-day banner ("Today · Travel day"), tips and notes, and the word-of-the-day line. "We can change UI later" — design only, not before launch.

  • One header for the landing page and the app (founder, 28 Sep: "they should align, we can do it slowly"). Step 1 done 28 Sep (nepwalk-fe b3aea2f): the app header copies the landing header's shape — inset, logo size, 8 px corners, plain centred links, rounded-full call to action. Next: one shared SiteHeader component with a light (app) and dark (hero) variant, same mobile menu.

  • Archived trips and account Settings in the sidebar: removed 28 Sep as template-era leftovers (founder: "we can think about this later"). The pages still exist (/trips/archived, /settings); decide their place later.

  • Recommendations by the traveller's preferences and real popularity.

  • AI parsing for free text the matcher cannot place (OpenRouter, decision B-track).

Tasks

  1. [be] Trip lists leave out the Pailas (NepWalk-owned templates; a user's own trip saved as a Paila stays listed) — e2e test. Pailas seed: a chosen cover image per Paila; a trip made from a Paila takes its cover. — ✅ 28 Sep, nepwalk-be 8ac9a26, 32a7c22.
  2. [fe] Trip cards: cover = trip image, else first linked place photo; aligned text (2-line title, ellipsis, hover); Pailas show "N days". — ✅ 28 Sep, nepwalk-fe 8f82e46.
  3. [fe] Dashboard tabs "Your trips" (Upcoming + Shared with you) and "Past". — ✅ 28 Sep, nepwalk-fe 138cfa4.
  4. [fe] /trips/new: request input, recommended Pailas (popular, then matches on top), scratch with title + N days. — ✅ 28 Sep, nepwalk-fe 26277a6.
  5. [fe] Paila preview (view-only day plan) + right drawer (details, start date, people, "Create trip"); bottom sheet on phones.
  6. [fe] "Templates" → "Pailas" tab with the same drawer; "My Templates" → "My Pailas" (custom Pailas); "Save as my Paila" on a trip. — ✅ 28 Sep, nepwalk-fe 63c4cb6.

Revision 2 — 19 Oct (find, fit, then edit all days on one page)

Job: a traveller or leader types what they want, finds the right Paila, answers the logistics questions, sees the whole trip on one simple page and changes anything there, then says OK and gets the day-by-day plan. Looking costs nothing: nothing is saved until they change something.

Why (founder, 19 Oct): today the journey is "pick a Paila → trip made → day plan". Creating commits too early, the start date + number of days is not how people think ("from the 28th to the 3rd"), and changing hotels, vehicles and stops means switching days and drawers. Start from scratch is too prominent for a product built on Pailas.

Decided (founder, 19 Oct)

1. Find a Paila (/trips/create)

  • One search box, as today ("3 days in ktm…"). Pailas show from the start; typing moves the best matches up.
  • Filter chips under the box, all optional: days, cities, pace (Relaxed · Balanced · Packed, P33), budget, interests. Days and cities go into the request the matcher reads, so they rank the Pailas. Pace, budget and interests do not rank Pailas yet (no Paila carries those tags); they are carried into the trip. Tagging Pailas so they rank too: later, a decision first.
  • Start from scratch is visible but quiet: a small plain link under the results, not first and not a card.

2. Logistics questions (the right drawer, after picking a Paila)

  • Required: date range (from – to), adults, children, rooms. The date range replaces start date + number of days.
  • Rooms are suggested from the head count (twin-share, as today) and can be changed (the room mix the trip setup already has). (Claude's call.)
  • Pace, interests and budget are not asked here: they come from the filters and are changed on the edit page.
  • The range differs from the Paila's length: the Paila is fitted as today (resizePailaDays — stays stretch or shrink, R1).
  • "Continue" opens the one-page edit. Nothing is saved yet as far as the user can tell.

3. One-page edit (/trips/:id/plan) — the bridge

  • Dates line at the top: "28 Dec – 3 Jan · 7 days · 6 nights". When the Paila was fitted to the range, one note says what changed ("2 days added in Pokhara"), never a silent stretch. Adding or removing a day updates the line and the end date.
  • All days on one page, short lines, no images; editing controls stay tucked away until a row is tapped (progressive disclosure): day number and date, each stop as one line (time · kind icon · name), tonight's hotel. Tap a line → the existing stop sheet. "+" adds a stop; a day can be added or removed.
  • Services block at the top: hotel per town, vehicle, airline, guide (P47), the same choices as the services drawer.
  • Trip name at the top, editable. Default: a memorable name with the destination, a season word and the start date with the year — never the Paila's own name — e.g. "Pokhara Winter Escape · 28 Dec 2026". A name the user typed is never replaced. The date helps people recognise a trip; it does not guarantee a unique name.
  • Preferences (pace, interests, budget) are a collapsed row here.
  • Draft rules:
  • Opening the page and only looking saves nothing. Leaving without a change deletes the trip silently.
  • The first change makes it a draft.
  • Back (or leaving) after a change asks once: Keep as draft · Discard · Keep editing. Discard deletes it (a mistake should not stay). A tab closed without the question keeps the draft.
  • Create trip (not "OK") makes the trip final and opens today's day-by-day plan. Beside it: "Hotels, vehicles and flights are confirmed by NepWalk after this." Final means the plan is saved, never that anything is booked.
  • A draft cannot be shared or booked; the share link and vendor booking work on a final trip only.

4. Trips page

  • A Drafts (N) tab, shown only while drafts exist (like Invitations): Upcoming · Drafts (2) · Past trips. A draft card: "Draft" badge, Continue, delete with undo.
  • The create page shows "Continue your draft: " when one exists.

How it is built (Claude's calls)

  • The trip is made when "Continue" is pressed, with a status: PREVIEW (only looking) → DRAFT (changed) → FINAL (OK). Existing trips are FINAL. Statuses only move forward.
  • PREVIEW trips are never listed anywhere. Making a new one clears the user's previews untouched for a day (an abandoned tab); a newer preview may be open in another tab, comparing Pailas, so it is kept (review, 19 Oct). DRAFT trips are listed only in the Drafts tab. Lists, the public trips and the share link use FINAL trips only.
  • The page reuses the existing stop sheet, stop and day endpoints, and the services choices, so every edit is a normal save on the trip; the first one moves PREVIEW to DRAFT.
  • Children are stored on the trip (children); the head count stays paxExpectedMax (adults + children).
  • The sweet name is a pure function in nepwalk-fe/src/lib/ (towns + season + dates), rules now, AI later (F10).

After the founder's check (19 Oct, afternoon)

The founder tried the build and changed five things.

1. One calendar for the range

From and To are one calendar: tap the first day, then the last; the length shows as you go. It replaces the two date boxes everywhere the range is asked.

2. Services on the right

On a wide screen the one-page edit has two columns: the days on the left, the services on the right (sticky). Every hotel night, the vehicle and the flights are listed there, already holding the NepWalk pick; the traveller changes any of them and presses Send to NepWalk, and the admin team processes it. On a phone the services come after the days.

  • A flight has an airline and an approximate time. The traveller picks the airline (Buddha Air, Yeti…) and types the time they would like to fly; beside it: "NepWalk books the flight closest to this time." Later the real flights come from an airline API and the traveller picks one.

3. Back to the one-page edit

A final trip opens the same page from "Edit all days" on the trip page; its button says Save trip.

4. No questions before the trip shows

Picking a Paila opens the one-page edit at once: the traveller first wants to see what they get. The date range, adults, children and rooms move to the top of that page; the logistics drawer goes. Create trip stays locked, with what is missing, until the dates and the adults are filled.

  • Before any change (a preview), choosing a range of another length fits the Paila again (stays stretch or shrink, as when it was made).
  • After a change (a draft or final trip), a longer range adds empty days at the end; a shorter one removes the last days after a confirm that names what is lost.

5. A quiet search page

The five chip rows go. The search box, "Understood: 3 days · Kathmandu", and one quiet Filters button beside the box ("Filters · 2" when something is picked) that opens a small panel with days and cities. Pace, budget and interests move to the one-page edit's Preferences: they do not change which Pailas show, so showing them as filters misled. (Claude's suggestion, founder agreed.)

Second check (19 Oct, evening)

  • Pace, budget and interests go back to the search Filters (with days and cities): they help find the Paila and are carried into the trip. The one-page edit has no Preferences block.
  • The right column holds the dates, who comes and the rooms, then the hotels and flights, shown only once the dates are picked. On a phone the dates come first.

Third check (19 Oct, night)

  • Dates: a small calendar of two months opens under the Dates field; a tap outside or Escape closes it. Adults and children are − / + steppers; rooms open as four steppers.
  • Vendor choice is a search field. A tap empties it for typing and opens the whole list with the current choice highlighted. Typing narrows the list (every word, any case; names starting with the text first). The list always opens downwards, keeps a fixed height and scrolls inside.
  • Stays and travel use tabs (Hotel, Vehicle, Flight, Guide), each with a badge: Pending, Partial, Confirmed or Unsaved. One line on top says where all of them stand ("2 of 4 confirmed"). Each tab has Request confirmation; Request all sends every change.
  • On a large screen the facts card scrolls with the page; the Stays and travel card stays in view and scrolls inside when taller than the screen.
  • Switching a service off is a preview only. The API cannot leave a service out yet, so while a switch is off nothing can be saved or sent. Building it for real is a task below.

Tasks (build day 21, after the check)

  • 6. [be] A preview without dates (the Paila's length); a date range of another length on PATCH adds empty days at the end or removes the last ones; a flight slot keeps the traveller's approximate time.
  • 7. [fe] One calendar for the date range.
  • 8. [fe] Picking a Paila opens the one-page edit at once; dates, group and rooms at the top; Create trip locked until filled; the drawer goes.
  • 9. [fe] Services on the right, Send to NepWalk; a flight's approximate time.
  • 10. [fe] "Edit all days" on the trip page.
  • 11. [fe] Search page: one Filters button (days, cities); pace, budget and interests on the edit page only.

Later

  • Reorder stops and days by drag.

Tasks (build day 21)

  1. [be] Trip status PREVIEW / DRAFT / FINAL and children; create-from-Paila takes from–to, adults, children, rooms and makes a PREVIEW (older previews of the user deleted); PATCH moves status forward only; lists, public and share link use FINAL only; GET /trips/drafts.
  2. [fe] Create page: filter chips (days, cities, budget, pace, interests); start from scratch as a quiet link.
  3. [fe] Drawer: date range, adults, children, rooms → Continue opens the one-page edit.
  4. [fe] One-page edit: name (memorable default), dates line with what changed, all days as lines, services summary, preferences row; first change → draft; leave → silent delete or Keep as draft / Discard / Keep editing; Create trip → final → day plan.
  5. [fe] Trips page: Drafts tab, Continue, delete with undo; "Continue your draft" on the create page.

Plan page visual refinement — 19 October 2026

Requested by the founder after reviewing the new all-days plan page. The goal is a warmer, clearer planning workspace with stronger hierarchy, while keeping every day visible and both desktop columns scrolling with the page.

  • A trip header shows the full, wrapping name, an explicit Rename trip control, dates, people and destinations.
  • Day shortcuts jump within the same page. Each day has a numbered marker, a separate date and a wrapping title. Stops stay compact; overnight stays have a distinct tinted row instead of looking like a timed activity.
  • Dates, people and rooms form one card; stays and travel form another. Flight time gets its own labelled row below the airline choice. Dates remain first on phones.
  • Use the existing typography, buttons, inputs and colour tokens. No itinerary images, extra UI libraries or changes to draft, booking or saving rules.
  • The Create trip / Save trip bar stays above phone navigation and remains reachable when navigation hides.

Acceptance checks:

  1. On a phone and desktop, long trip, day and stop names wrap without covering controls. Rename trip exposes the existing name field.
  2. Jumping to a day keeps its heading below the app header. All days remain visible; stop editing, removal confirmation, undo and Add a day still work.
  3. Date, guest, room and service controls retain their existing behaviour. Airline choice and preferred flight time do not squeeze each other.
  4. Create trip remains disabled until required details are present. The action bar clears the mobile navigation and opens the existing day-by-day plan after saving.

Validation: type checking, lint, unit tests and an isolated production build. Browser validation remains a founder check unless requested separately.

Paila preview refinement — draft, 23 October 2026

Status: prototype for founder review; not approved for implementation.

Discussion: the founder supplied a ten-day preview screenshot and requested a clearer, more appealing page. The proposed direction makes the journey scannable before completing trip setup. Preserve existing trip-creation behavior and actual itinerary content; do not change backend contracts in this design task.

Open the interactive Paila preview prototype.

  • Desktop: compact destination introduction, expandable day summaries, day jump navigation and one sticky setup panel containing the primary action.
  • Phone: readable itinerary with a bottom setup action and focused setup sheet.
  • First day expanded; individual days and expand/collapse-all remain available.
  • Date selection derives the ten-day range and labels itinerary days. Adults start at two as a proposed default, remain editable, and cannot fall below one.
  • Preserve selections while exploring. Show a field-level error for missing or past dates. Room preference remains a planning preference, not confirmed inventory.
  • Rename works locally. Creation and navigation outside the page are explicitly simulated; no API calls, customer data, bookings or persistence.
  • Purposeful short transitions respect reduced-motion settings. Illustration is inline SVG to meet self-contained prototype rules; production photography is deferred until approved assets are selected.

Reference: the founder's supplied screenshot and the historical Visit A City observations. These are not fresh competitor research or proof of user validation.

Review checks

  1. Scan all ten days, open a day and jump between days without losing setup values.
  2. Choose a date and travellers; confirm the computed dates and summary agree.
  3. Submit without a date; confirm the error explains how to recover.
  4. On a phone, open and close setup, then complete the simulated creation flow.
  5. Review keyboard navigation and reduced motion before implementation.

Open decisions: confirm two-adult default, room preference choices, compact-day copy, and whether the overview gives enough detail to evaluate the Paila. Next: founder phone review, then refine and record approval before assigning work.

Prototype revision 2 — one editable workspace

The founder prefers editing the itinerary and setup together, without a wizard. This draft supersedes revision 1's preview-only editing and simulated creation. It remains unapproved for production implementation.

  • The first meaningful edit starts a draft. Expanding days alone does not.
  • Desktop keeps itinerary left and setup right; phone opens setup as a full-height view. Switching views preserves input.
  • Stops support name/time edits, add, remove and undo. Place selection is free text in the demo; production must use the real place library and permissions.
  • Start/end dates support extending the itinerary with free days before departure. Shortening explicitly warns before removing days and activities.
  • Hotels, vehicle, flights and guide preferences can be included or excluded. Suggestions are demo content without live availability.
  • Draft recovery and Save my trip use browser-local storage only. Storage failure is reported rather than presented as success. Reset demo clears the local draft.
  • Service request preview requires a saved trip; no request is actually sent. Saving, requesting and provider confirmation remain separate states.

Review: edit a stop, change travellers and services, refresh to check recovery, then save with dates. Try adding days and cancelling a shorter range. On phone, switch between itinerary and setup. Nothing contacts providers or updates the app.

Open decisions: persistence behavior in the actual product, production end-date change rules, place picker details and the appropriate confirmation-request action.

Design review contract

Mobile, tablet and web reviewer view. This test HTML design is not yet an engineering-ready approved journey. References currently inspected are the supplied screenshots, this card, requirements, design system and historical Visit A City notes. Current competitor flows, neighboring screens and actual draft persistence contracts require reconciliation before approval.

Proposed journey: Paila selection (existing, not redesigned here), preview, first meaningful edit starts draft, edit itinerary/setup in either order, save trip, review service request, continue editing. Back/exit must preserve or explicitly discard edits. Local persistence in this HTML is only a design simulation.

Responsive intent: mobile 390 uses itinerary plus full-height setup view; tablet 768 uses two columns with a 300px setup panel; web 1440 uses a wider itinerary and 330px panel. Both columns collapse below 720px. No physical-device validation is claimed. Check 320px, tablet portrait/landscape, keyboard, zoom and breakpoint boundaries before handoff. The reviewer canvas provides sizes, not test evidence.

Engineering tasks must link this card, the design/reviewer view, exact approved revision, relevant state, responsive behavior and originating ticket. No tasks have been assigned from this exploratory design.