Case study · 01
Naczarter
Drugie życie cyfrowe platformy czarterowej, która 25 lat trzymała Mazury na telefonie i papierze.
Wejdź na Naczarter →- Branża
- Yachting · czarter
- Zespół klienta
- Operatorzy flot + obsługa klienta
- Timeline
- 14 tygodni od briefu do live
- Języków
- 12 (PL, EN, DE, CZ i 8 kolejnych)
- Scope
- Design system + web + backoffice
Kontekst
Naczarter to marka z 2001 roku — platforma łącząca żeglarzy z operatorami flot na Wielkich Jeziorach Mazurskich. Przez ćwierć wieku zbudowali bazę 5000+ zrealizowanych rejsów, 100+ portów partnerskich, 12 języków obsługi. Ale interfejs był jeszcze z 2009 roku — table layout, brak mobile, checkout z reCAPTCHA v1. Konwersja spadała kwartał-do-kwartału, mobile ruch rósł szybciej niż desktop mógł nadążyć. Klient miał dwa wyjścia: zlecić kolejny redesign kosmetyczny (jeszcze jedna warstwa farby na tamę), albo zrobić drugie życie cyfrowe — zachowując to co działa i wymieniając to co hamuje.
Problem
Nie był to typowy redesign UI. Naczarter miał bazę klientów z ćwierćwiecza — ludzi którzy wracali co lato, często z tymi samymi rodzinami, na te same jachty. Migracja loginów, rezerwacji, historycznych danych musiała pójść gładko, inaczej traciłeś trust z ludźmi którzy są Ci najbliżej. Plus: operatorzy flot (70+ firm) mieli własne back-office'y przerobione pod Naczarter'a — każda zmiana modelu danych to koszt integracji po ich stronie. Nie mogliśmy przepisać od zera. Musieliśmy przepisać z zachowaniem kontraktów.
Rozpoznanie (3 dni)
Zaczęliśmy od trzydniowego sprintu rozpoznawczego. Wywiady z trzema operatorami flot (Sztynort Sailing, AquaTour, Masuria Yacht Charter), analiza desktopowej konkurencji (Boats.com, SamBoat, Click&Boat), mapa decyzji produktowych. Pierwsza rzecz która wyszła: nie istnieje polska platforma która pokazuje dostępność floty w czasie rzeczywistym z pełnym filtrem po typie jachtu, lokalizacji portu, zakresie dat, cenie. Wszystkie konkurencyjne to albo broker bez inventory, albo inventory bez filtra.
Decyzje projektowe
System wizualny od zera, ale konserwatywny — Fraunces dla premium lookoutu (serif z wariacyjnymi osiami wght/opsz, dostosowuje się do wielkości), Geist dla UI (neutralny, czytelny na mobile), OKLCH dla kolorów (perceptual color space — akcenty mają koordynaty które się liniowo interpolują, gradienty bez szarego środka). Mobile-first, 3-tap rezerwacja, checkout z Apple Pay / Google Pay bez captcha. Filtry na mapie (port, typ jednostki, zakres dat) aktualizują się live — zero page reloadów.
Wdrożenie (16 tygodni)
Każda zmiana przez 16 tygodni dostawała własny preview URL (Vercel deployments per PR). Operatorzy mogli zobaczyć co robimy w środku sprintu — nie czekając do demo na końcu fazy. Funkcje włączane stopniowo przez feature flags — nowy checkout miał 10% ruchu pierwszy tydzień, 50% drugi, 100% trzeci. Monitoring od pierwszego dnia (Sentry + web-vitals endpoint). Migracja bazy klientów zrobiona w pojedynczym weekendzie z pełnym rollback playbookiem — zero utraconych kont.
Outcome
Brief → live w 14 tygodni. LCP mobile 2.3s (Core Web Vitals: good). 12 języków interfejsu. 100+ portów partnerskich z niezmienionym back-office'em po ich stronie. Bazę klientów z ćwierćwiecza zachowaliśmy bez żadnej utraty. Konwersja mobile wzrosła 2.8× w pierwszym miesiącu po launch (baseline vs. post), Time-to-first-booking spadł z 4:12 na 1:38.
Czego nauczyliśmy się
Dwa tygodnie pierwszej fazy poszło na stack-swap — w efekcie przez 14 dni operatorzy mieli degraded bookings (tylko 30% zautomatyzowane, reszta telefoniczna). W przyszłym razie: feature flags od MVP, stare systemy równolegle z nowymi, nie rozmontowane od razu. Lekcja: „drugie życie cyfrowe" to nie migracja, to dual-track przez 3-4 tygodnie. Klient uczy się, operatorzy się uczą, my się uczymy.