A ground-up redesign of a tandem-paragliding operator's website - turning a generic booking page into a fast, bilingual, WhatsApp-first conversion path built for an international tourism audience.
A quick map of how this project actually went, before the deep dive below - audit, research, system, build, then a localisation layer on top.
Sooperfly Tandemparagliding flies 600+ tandem flights a year over the Stubaital - but the website looked like every other small-business template: single language, unclear pricing, and a booking path that made visitors work to hand over money.
Both frames below are real screenshots, not redrawn templates - the original
innsbruck-paragliding.at on the left exactly as it shipped at the time of writing, next to a
screenshot of the rebuild on the right.
German-only nav, a cookie modal that covers the CTA on load, and a single hero image doing the job an entire page should be doing.
Screenshot taken at the time of writing - the live site may have changed since.
A DE/EN toggle, a stats strip that states 600+ flights up front, and a hero CTA nothing sits on top of. Live, interactive renders of all four pages are further down in Responsive.
Every nav label, price description and FAQ answer exists only in German. But the two traveller profiles this operator actually books - detailed just below - skew German, Dutch, Danish, Swedish and American. For most visitors, evaluating trust, price and safety policy means translating the page themselves first.
On load, the consent dialog covers roughly half the viewport - including the "Flug Buchen" button - and didn't reliably dismiss on the first click during testing.
Flight types and prices live several scrolls down, with no way to compare Actionflug vs. Thermikflug vs. Premiumflug before committing to read the whole page.
No testimonials, review count or star rating anywhere on the homepage - despite the operator flying 600+ tandem flights a year.
Weight limits, weather cancellations and voucher redemption aren't addressed on the page - each becomes a message a visitor has to type by hand.
The only fast booking path on mobile is a bubble in the corner - not a guided flow, not pre-filled with a flight type or date.
Typography, spacing and button style shift from section to section - a stock template stitched together, not one product.
Almost nobody landing on this site is local. Bookings skew heavily German, Dutch, Danish, Swedish and American - holidaymakers in the Stubaital for a week, not locals browsing on a Tuesday. Before building deep personas, I mapped every visitor type the redesign actually had to serve.
DE / NL / DK / SE tourists building a Tirol itinerary from home, days or weeks before arrival. Need to evaluate trust and pricing without translating the page.
US / UK / AUS visitors with little or no German. The old site gave them nothing to read - the single biggest gap this redesign had to close.
Sees paragliders overhead, decides same-day. Needs a three-second call-to-action, not a page to read.
Buying for someone else, often not flying themselves - needs a clear, standalone gift path, not a booking form built for the flier.
Returning for video or photo purchases, or to leave a review - a second touchpoint the old site did nothing to capture.
Concierge desks and hostel staff who recommend the operator - need a page credible enough to point a guest to without hesitation.
DE / NL · booking 1-3 weeks before arrival
Core pain points
"We book activities weeks ahead so the week isn't wasted searching. I need to compare prices without translating every line."
Profile A · Composite voiceSE / DK / US · decides same day or next
Core pain points
"I'm not planning three weeks out. If I can't message you in the next minute, I'll book with whoever answers."
Profile B · Composite voiceMapped across both personas - where the old site lost people, and where each rebuilt page picks them back up.
|
Discovery
Planning the trip
|
Comparison
Choosing a flight type
|
Booking
Committing to a date
|
Day of Flight
Weather-dependent
|
After
Sharing & reviewing
|
|
|---|---|---|---|---|---|
| Actions | Searches "paragliding Innsbruck" on Google/TripAdvisor while planning the Tirol trip | Opens the shop page, compares Thermikflug vs Actionflug vs Premium pricing | Taps WhatsApp CTA or fills the hero booking widget with a preferred date | Checks for a weather-reschedule message, meets at the pickup point | Buys the flight video/photos, leaves a Google review |
| Touchpoints | Google search · TripAdvisor · hotel/hostel recommendation | Shop page · price cards · FAQ accordion | Hero booking widget · WhatsApp deep link · floating WhatsApp button | WhatsApp thread · pickup coordination | Instagram/Google review prompts |
| Thinking | "Is this a real operator, and can I even read this site?" | "What's actually the difference between these three flights?" | "This is the app I already use - I'm not calling a landline abroad." | "Will they tell me if it's cancelled, or do I just show up?" | "That was worth it - I want the video before I forget." |
| Emotions | ScepticalCurious | ComparingReassured | ConfidentIn control | AnxiousExcited | ProudGrateful |
| Experience | |||||
| Pain Points | German-only content · generic template feel · no trust signal | Prices buried under stock photography, hard to compare | Phone-only contact, unclear from abroad if anyone will answer | No visible weather/reschedule policy | No prompt to leave feedback or reorder photos/video |
| Opportunities | ↑ DE/EN toggle↑ Real trust strip | ↑ Scannable price cards↑ FAQ up front | ↑ WhatsApp deep link↑ Hero booking widget | ↑ Free rescheduling promise | ↑ Google review CTA |
| Site Response | Language toggle in nav on every page · trust strip with response time | Featured price card + comparison list · FAQ accordion open by default | Hero widget builds a pre-filled WhatsApp message with flight type + date | "Kostenlose Terminänderung" stated on shop & contact pages | Social links and Google reviews surfaced in the footer |
Every colour, radius and spacing value lives as a CSS custom property, shared across all four pages - so the site reads as one product, not four separate builds.
07 - Solution 01
A floating nav with a scroll-aware light/dark state, a persistent cart badge, and a DE/EN
pill that swaps every data-i18n element in place. The chosen language is saved to
localStorage, so it survives navigation between all four pages.
Sechs Erlebnisse über dem Stubaital - wähle deinen Flug, den Rest übernehmen wir.
07 - Solution 02
Six flight types collapsed into scannable cards - one featured with a pilot quote, a gift-voucher banner for the "not sure which flight" gift-buyer, and a mouse-follow spotlight so the cards feel alive on hover, not static.
Der längste reguläre Flug: über 30 Minuten in der Luft, viel Zeit für das Bergpanorama.
07 - Solution 03
Weight limits, bad-weather policy, rescheduling, age minimums - the questions that otherwise turn into back-and-forth messages, answered inline on the shop page as an accordion, first item open by default so the pattern is obvious immediately.
Wir fliegen Gäste von ca. 15 kg bis 125 kg. Bei Abweichungen sprich uns vor der Buchung kurz an.
Sicherheit geht vor. Wetterbedingt verschieben wir deinen Termin kostenlos - so oft wie nötig.
Gutscheincode bei der Terminvereinbarung angeben - ein Jahr gültig, für jeden Flugtyp einlösbar.
The kind of issues QA finds on a real phone, not in a design file - both traced back to how CSS actually resolves stacking and specificity, not surface-level styling.
The shop toolbar's dropdown had a higher z-index than the cards below it - yet still painted
underneath them. Root cause: the toolbar's scroll-reveal transform created its own
stacking context, trapping the dropdown's z-index inside it while sibling cards - also transformed -
formed later, higher-painting contexts of their own.
.shop-toolbar { z-index: 6; }
/* transform already grants z-index
eligibility - no position:relative
needed on the toolbar itself */
The current-page link was meant to show in accent orange on mobile. It worked - until the menu was
opened after scrolling past 80px, when a same-context nav.scrolled rule with higher
specificity silently overrode it back to near-black on a dark overlay.
nav.scrolled .nav-links
a[aria-current="page"] {
color: var(--color-accent);
}
/* equal specificity, later in the
cascade - wins without !important */
Two decisions that changed after the initial build - not comps rejected in a design file, but real revisions made once the pages actually existed.
The shop page launched with just the six flight cards and a trust strip - pricing and booking, and nothing else.
Added an accordion answering weight limits, weather policy, rescheduling and voucher redemption - the exact questions that would otherwise land in the WhatsApp inbox one by one.
Every unanswered question on the page is a question asked by hand later, in a second language, on a phone. Cheaper to answer it once, in writing, than every time.
The founding-year badge on the story photo used a negative offset to overlap the image edge -
intentional on desktop, but the photo container's overflow:hidden cut the badge's own
corners off on narrower screens.
Rounded the image itself instead of clipping its container, freeing the badge to sit on top without being cropped by the same box it was meant to overlap.
The bug only showed up once revealed on a real phone width - a
reminder that overflow:hidden clips everything inside it, including elements meant to
break out of it on purpose.
No CMS, no backend, no build step - so the DE/EN switch had to work as a thin layer over the existing markup, safe to add to a static four-page site without rebuilding any of it.
The nav collapses at 860px, not by accident - it's the point real content started colliding on a tested device. These are the live pages rendered at three real widths, not redrawn templates.
No analytics history exists for the old site to quote a conversion lift from - so rather than invent one, here's what measurably shipped.
Built for the channel this audience already uses, in the language they actually read - and left simple enough for a solo operator to hand off to a booking plugin later without a rebuild.
The hero booking widget hands off to WhatsApp rather than processing payment - that's intentional, not a gap. A one-person operation needed a live, bilingual site fast; real-time availability and card payment are scoped for a follow-up phase on a booking plugin (Amelia / WooCommerce Bookings), once the business is ready to commit to that overhead.