Homepage — V1 → V2

After the first design pass the homepage communicated the product's existence but not its value. Six structural problems were identified through review: two in navigation, one in visual fidelity, and three in trust and positioning. This document annotates the V1 screen, explains the reasoning behind each change, and shows the resolved V2 state.

6
Issues identified across navigation, trust, and visual fidelity
3
Sections removed (app download, icon grid, route illustration)
2
Nav items replaced with a single clear primary action

Before & After

V1 — Before
Homepage V1 1 2 3 4 5 6 7
V2 — After
Homepage V2

Problems & decisions

01
Navigation

Header IA mismatch

Logged-out visitors see "Itineraries / Reservations / Wishlist / Explore activities" — items that belong to a signed-in product session. A first-time visitor has no itineraries or reservations yet, so the nav describes a state they can't reach. "Explore activities" is undefined: it's unclear whether it leads to a search, a city guide, or something else entirely. Additionally, showing "Get itinerary" as a persistent nav CTA while the user is already mid-flow creates ambiguity — does it start over, or save progress?

Decision in V2

Nav is simplified to three links that reflect actual page destinations: How it works, Destinations, and Pricing. A single "Get itinerary" CTA remains in the nav but is visually subordinated to the hero. Once signed in, the nav transitions to a product-context header with user-specific items. Ambiguous items like "Explore activities" are deferred until the product's activity layer is built and can be linked to a real page.

02
First impression

Value proposition is implied, not stated

"A trip plan tailored to you / Just answer a few questions" describes a mechanism (questionnaire-based planning) rather than an outcome (a ready-to-use day-by-day itinerary with bookings). A user landing for the first time cannot determine in under three seconds what is different about Pockigo compared to Google Maps, TripAdvisor, or a travel agent. The supporting route illustration reinforces "planning tool" but not the specific value of AI-generated, locally optimised itineraries.

Decision in V2

The hero headline leads with the outcome, not the method. "Your Granada plan, built in seconds" places the result — a named, specific itinerary — front and center, with a subhead that explains the mechanism ("Routed stops, pre-checked times, reservations handled"). The hero also includes a destination search bar as the primary interaction, so the value proposition is demonstrated immediately rather than described.

03
CTA architecture

Two competing primary actions

The V1 hero contains a "Get itinerary" button in the nav and a large "Get itinerary" button in the hero. Two identical CTAs at different visual weights create indecision. The labels are identical, which raises the question: are they different actions? If not, one is redundant; if yes, the distinction is invisible.

Decision in V2

A single interaction point in the hero: the destination search bar. Typing a city name initiates the flow — no secondary button needed. The nav "Get itinerary" CTA is retained as a ghost button for users who scroll past the hero, but it is visually lighter than the hero element and uses different copy ("Plan a trip") to distinguish entry points. No hero button duplicates the nav.

04
Visual fidelity

Hero illustration reads as a sketch artifact

The dashed orange route path connecting circular photo thumbnails is conceptually strong — it maps the journey structure that Pockigo produces. In execution it reads as an early wireframe rather than a finished product: the stroke weight, the mismatched avatar crop sizes, and the icon circles without consistent labels signal prototype fidelity. For a travel product where the first impression is "is this trustworthy enough to book through?", a sketch aesthetic in the hero works against conversion.

Decision in V2

The hero illustration is replaced by a high-fidelity product screenshot (the itinerary card view) displayed in a browser chrome frame. This shifts the hero from "explaining the concept" to "showing the output." Seeing a real itinerary card — with stop times, a map, and action buttons — is a stronger trust signal than a metaphor. The route-journey motif is preserved in a smaller supporting graphic below the fold.

05
Positioning

Destination examples mismatch the product's focus

The "Recommended itineraries" section shows Tokyo (6-day) and Thailand (10-day). The actual product in its current state is scoped to European city trips — the Granada itinerary is the core demo, and the destinations section in V2 shows Seville, Lisbon, Porto, and Marrakech. Showing long-haul Asia trips implies global coverage that doesn't yet exist, and creates a credibility gap when a user tries to plan Tokyo and finds a thinner experience.

Decision in V2

Destinations are scoped to the product's actual coverage: Spain, Portugal, and Morocco — geographically coherent, culturally linked, and representative of the Granada-centered demo. This makes the claim "loved in 40 cities" honest and verifiable. Tokyo and Thailand are removed. Long-haul expansion can be added to the section when the product supports it.

06
Trust

Trust signals are insufficient for a payment product

"Over 5,000 people have built their plan with us" is a lifetime aggregate number with no time dimension — it doesn't signal current activity. The two testimonials use stock-photo avatars, which are widely recognised as placeholder assets and reduce credibility. For a product that holds ticket reservations and processes payments, users need: evidence of live usage, visible cancellation and refund policies near the payment step, and partner or security indicators that confirm their money is safe.

Decision in V2

Social proof is restructured: "1,200+ trips planned this month" replaces the lifetime count; testimonials are removed from the hero and deferred to a later trust-building section with real user names and linked trip destinations. Refund policy and cancellation terms are surfaced inline on the booking step, not buried in footer links. A "Tickets secured by Stripe" badge is placed adjacent to the payment field. The app download push is removed entirely from the homepage — it added friction before the user had seen the product.

07
Footer

Footer was overloaded and unfocused

The V1 footer included a QR code for app download, a broad set of navigation links, and social media icons — all competing for attention at the bottom of the page. For a product this early in its lifecycle, a dense footer signals breadth that doesn't yet exist and draws the user's eye away from the primary conversion path. The app QR code in particular was misplaced: a user who just landed on the homepage hasn't experienced the product yet, so there is no compelling reason to download an app.

Decision in V2

The footer is simplified to three functional columns — Product, Company, Support — with the Pockigo wordmark and a one-line mission statement on the left. The app QR code is removed entirely from the homepage footer; it reappears contextually after a booking is confirmed. Social media links are removed — the product doesn't yet have active social channels worth promoting. The footer now serves purely as navigation and legal, not as a secondary marketing surface.