E-commerce for park homes,
built on trust.

The homepage had one job above everything else: establish credibility before the user scrolls. The hero leads with the buyer's intent — Buy, or Sell Your Perfect Caravan, Lodge, or Park Home Across the UK — not the brand's identity. The search bar is positioned immediately below the hero with four filters visible above the fold: Location, Property Type, Pricing Range, and Bedrooms. A buyer can begin filtering within seconds of arriving.

The announcement bar at the top surfaces the advertiser offer — a secondary revenue stream that also functions as a trust signal. The navigation covers the full product breadth without being cluttered: Caravans/Lodges/Park Homes, Our Parks, Park Finder, Parks For Sale, Events, and Private Sales. The "Discover a World of Possibilities" section below the fold leads buyers into category browsing with zero friction.

• Search bar above the fold — the primary conversion point is never hidden or reached only after scrolling.
• Value proposition in buyer language — not the brand's category names, but what the buyer actually wants to do.
• Deals of the Week badge — creates urgency without feeling manipulative; buyers in this category respond to curated selections, not countdown timers.
• Sign In prominent but not dominant — respects that most buyers are browsing anonymously at this stage.

The listing grid was designed around the concept of efficient triage. A buyer arriving at the listings page has signalled intent — they know broadly what they want, and now they need to evaluate quickly. Each property card contains precisely what's needed for that triage: a photograph, the property name, a one-line description, key specifications (bedrooms, bathrooms, floor area), and the price. The CTA ("Read More") is clear and low-commitment — it doesn't say "Enquire Now" at this stage, because the buyer isn't there yet.

The filter bar persists at the very top of the page — Location, Property Type, Pricing Range, Bedrooms, and an Advanced Filter expand option. The "Show Map" button sits top right, always one click from geographic browsing mode. The "FEATURES" badge on select cards signals curated or promoted listings without breaking the grid's visual rhythm.

• Filter persistence — filters stay visible as the buyer scrolls; refining a search should never require scrolling back to the top.
• Price always visible on cards — never hidden behind a click; high-consideration buyers will not click into a listing whose price they can't see.
• Three columns on desktop — enough visual variety to engage without overwhelming; collapses to single column on mobile.
• Map toggle always accessible — geographic browsing is a primary mode for this category, not a buried option.

For buyers in the park home category, location is often the most important filter of all. A buyer choosing a park home is choosing where they will live — proximity to family, coastline, countryside, or a specific region of the UK is frequently the deciding factor before any property specifications are even considered. The map view was built as a first-class experience to serve this directly.

The layout is a dual-pane design: the interactive Google Maps panel fills the left, showing all available listings as location pins across the UK. The right panel displays a live property preview card that updates instantly when a pin is selected — no page reload, no loss of context. The preview card contains the property photo, a one-line description, bedroom/bathroom/size specs, price, and a "View Property Details" CTA. The "Show list" toggle at the top right allows an instant switch back to grid mode.

• Instant pin-to-card preview — selecting a pin requires no commitment; buyers can scan multiple properties rapidly without loading new pages.
• Price visible in the preview card — consistent with the listing cards; pricing is never hidden in any context.
• "Discover a World of Possibilities" header — the section copy above the map is aspirational without being misleading; it reflects the geographic breadth of the portfolio.
• Satellite/Map toggle on the map itself — useful for buyers evaluating natural surroundings, coastal proximity, or rural setting.

The Park Finder was one of the most carefully considered features on the platform. It emerged directly from the research insight that a significant portion of buyers arrive at Prana without a specific property type in mind — they have a lifestyle aspiration rather than a clear brief. They know they want to simplify, downsize, or live somewhere beautiful. They don't yet know whether they want a holiday park, a residential park, a touring site, or a mixed-use development.

The Park Finder is a structured preference wizard that walks buyers through their requirements question by question. It starts with budget range — price bands from £0–£50k through to £200k+ — before moving to park type selection. Critically, park type uses real photography for each category rather than text labels alone. A buyer can see what a "Touring/Glamping Park" actually looks like, what a "Residential Park" feels like, before selecting. The ownership type section (Buy / Rent / Lease-to-Own) surfaces a pivotal decision point early in the process. The wishlist chip system is extensive — covering everything from Gated Development and Over 55s Community to Pet-Friendly Policy and Investment Potential — allowing buyers to express nuanced lifestyle preferences in plain, scannable language.

• Photography-led park type selection — reduces cognitive load for buyers who find abstract category names ambiguous.
• Ownership type surfaced early — Buy vs Rent vs Lease-to-Own is a foundational filter that should shape all subsequent results; asking it early prevents mismatched outcomes.
• Wishlist chips, not dropdowns — chip-based selection allows buyers to add multiple lifestyle preferences simultaneously without navigating multi-select dropdowns; faster and more expressive.
• Progressive form structure — one clear question section at a time prevents the overwhelming "wall of filters" experience common on competing platforms.

The owner dashboard was designed to give a property operator their complete operational picture in a single view. A property owner managing multiple listings across one or more parks needs to know, at a glance: how many listings are live, how many leads have come in recently, how their traffic is trending, and what's coming up on the calendar. All of that is answered before they scroll.

The five KPI cards at the top — Total Listings (85), Active Listings (85), Advertise Listings (02), Inactive Listings (85), Awaiting Approval (01) — give the owner an immediate operational status check. The "Awaiting Approval" card is particularly important: it signals that something requires action without requiring the owner to hunt through their listings to find out what.

Below the KPI row, the dashboard is divided into three zones. Left: the Recent Leads table, showing the five most recent buyer enquiries with park/property name, buyer name, email, and a quick "View Details" action. Right: the Daily Traffic chart — a seven-day bar chart showing visitor volume (2,579 that week, +2.45% trend). This gives operators visibility into how their listings are performing without requiring them to navigate to a separate analytics section. Below both of these: a monthly calendar view (January 2025) paired with an inline event creation form — title, property association, event type, date range, description, and image upload all in one panel.

• Everything critical above the fold — an owner can assess their entire operational situation — listings status, recent leads, traffic trend — without scrolling.
• "Awaiting Approval" as an action prompt — this card is not purely informational; it's a direct pointer to something that needs the owner's attention.
• Traffic chart on the main dashboard — owners care about whether their listings are being seen; making this a top-level metric reduces the need for separate analytics visits.
• Inline event creation — placing the event form directly on the dashboard reduces friction for an operator who wants to add a park open day or viewing event quickly.
• Left sidebar navigation — Dashboard, Manage Park, Manage Listings, Leads, Customer, Manage Events, Media Download — covers all owner needs in seven clearly named items with no nesting.

The Leads page is where a property owner manages every buyer enquiry that has come through the platform. This screen needed to be a functional working tool — not a report — because an owner with 91 unreviewed leads needs to move through them efficiently, identify the most recent or most promising contacts, and take action.

The page opens with the same five KPI cards carried from the dashboard. This was a deliberate continuity decision: wherever an owner is in the system, their key operational metrics are always visible at the top. Below the KPI row, the "Leads +91" heading communicates immediately that there are 91 new leads since the last review — a clear call to action before the table even registers.

The leads table presents six columns: ID, Property Info (which specific property the enquiry is about), Name, Email, Phone, Last Event (timestamp of the most recent interaction with this lead), and Action ("View Details"). The table is designed for scanning, not reading — all critical fields are visible at once, and "View Details" is always one click away. The search bar at the top right allows an owner to find a specific lead by name, email, or property without scrolling through the full table.

• Leads counter on the page title — "+91" immediately communicates the volume of unreviewed leads; an owner knows their workload before reading a single row.
• Last Event timestamp — shows when the most recent interaction with each lead occurred, allowing owners to prioritise follow-ups by recency.
• Property Info column — essential for owners managing multiple listings; a lead means nothing without knowing which property it relates to.
• KPI cards persist across pages — an owner switching from Dashboard to Leads never loses sight of their overall listing status.

The Superadmin dashboard is a completely separate system from the owner PMS — different navigation, different data scope, different permissions. Where the owner sees their own listings and leads, the superadmin sees the entire platform. The navigation reflects this: Property Owner, All Park, All Listings, Events, Media Download — six items covering total platform oversight.

The All Parks page gives the admin team a complete view of every park registered on the platform, regardless of owner. The four KPI cards at the top reflect platform-wide scale: 8,500 total listings, 1,500 active, 180 advertised, 85 awaiting approval. The "Awaiting Approval" figure is the most operationally critical — 85 parks are pending review before they can go live on the public platform.

The parks table presents the information an admin needs to act: Property Owner, Park Name, Property Type, Status (ACTIVE badge), a "View Properties" quick action, a "Preview" link to see the live listing, and an Approval toggle (red/orange toggle switch) in the final column. The approval toggle is the most important UI decision on this screen — it gives the admin team the ability to activate or deactivate any park instantly, directly from the table row, without navigating into a detail page.

• Platform-wide KPI cards — the admin team's top-level metrics are categorically different from an owner's; the same card structure carries different data to serve a different operational role.
• Approval toggle in the table row — the most frequent admin action (approving or pausing a listing) is achievable without leaving the table view; this eliminates an entire navigation step from a high-frequency workflow.
• Preview link per park — admins can view the public-facing listing before or after approval to verify content quality without switching context.
• Search within the table — with 8,500 total listings, table-level search is essential; the admin cannot scroll to find a specific park.
• Different sidebar from PMS — admin navigation and owner navigation are separate systems with separate access levels; the visual similarity of the sidebar masks a completely different permission layer underneath.