CN Wszystkie projekty

Booking.com, niezależny koncept funkcji

Nocleg na trasie w jednym miejscu.

Zobaczyłem problem podczas własnej podróży. Zamiast od razu projektować ekran, rozłożyłem go na części: gdzie ginie kontekst, czego brakuje w obecnych narzędziach i jak dodać tę jedną rzecz bez budowania całego produktu od początku.

Makieta widoku Zaplanuj trasę w stylu Booking.com: po lewej pola Opole i Trogir, wybór zasięgu 10, 25 lub 50 km i suwak postoju na 50% trasy, po prawej mapa z niebieską trasą i okręgiem z cenami noclegów w połowie drogi
Koncept, niewdrożony Wariant A: osobny widok planowania trasy Opole → Trogir. Makieta, nie zrzut działającego produktu. Booking.com nie brał udziału w projekcie.
Rola
UX i Product Design
Typ
Niezależny koncept
Rok
2026
Trasa w przykładzie
Opole → Trogir, 1179 km

Punkt wyjścia

Lato 2026. Chorwacja. Jak co roku.

Co roku jedziemy tam całą rodziną. Z Polski to około 1100 kilometrów, więc tym razem chcieliśmy podzielić drogę na dwa dni: zatrzymać się mniej więcej w połowie, przespać i nie zaczynać urlopu od dochodzenia do siebie po całym dniu za kierownicą. Znalezienie noclegu przypadło mnie.

Otworzyłem Booking, bo tam zwykle rezerwuję noclegi za granicą. Otworzyłem też Google Maps, bo tylko tam widziałem naszą właściwą trasę. Bardzo szybko okazało się, że te dwa narzędzia w ogóle ze sobą nie rozmawiają.

Google Maps: trasa z Opola przez Ołomuniec, Wiedeń, Maribor i Zagrzeb do Trogiru, bez żadnych noclegów
Google Maps Tu znałem drogę

Przebieg trasy, czas przejazdu i miasta po drodze. Żadnych cen ani dostępności.

Mapa wyników Bookingu: ceny noclegów w jednej miejscowości na wybrzeżu, bez żadnej trasy
Booking Tu mogłem rezerwować

Ceny, dostępność i opinie wokół jednego miejsca. Żadnej trasy.

Trasa Opole → Trogir odtworzona 20.09.2026. Mapa Bookingu pochodzi z innego wyszukiwania (Omišalj, wrzesień 2026) i pokazuje, jak wygląda ten widok, a nie konkretny moment z tamtej podróży.

Zacząłem zgadywać, które miasto wypada sensownie po drodze, sprawdzać je na Bookingu, wracać do mapy i porównywać odległości. Nawet przy dwóch oknach obok siebie cały czas traciłem kontekst. Po kilku dniach znalazłem nocleg, ale wymagał większego zjazdu, niż zakładaliśmy. Nawet po rezerwacji zostało mi z tyłu głowy jedno pytanie:

Czy ja na pewno dobrze to sprawdziłem?

Diagnoza

Każda aplikacja miała połowę odpowiedzi.

Na początku opisywałem ten problem jako brak wyszukiwania noclegów na trasie. Im dłużej o nim myślałem, tym bardziej widziałem, że to nie do końca prawda.

Google Maps znało przebieg drogi. Booking znał ceny, dostępność, opinie i wszystkie filtry potrzebne do wybrania noclegu. To ja musiałem ręcznie skleić te połowy i pilnować, żeby po drodze się nie pomylić.

Pierwsze pytanie

Jak zrobić kolejną mapę z hotelami?

Pytanie po diagnozie

Jak przenieść kontekst trasy do miejsca, w którym i tak podejmuję decyzję o rezerwacji?

Podobna funkcja już istniała. To nie zabiło pomysłu, tylko ustawiło go dokładniej.

Po powrocie z wakacji odkryłem, że Google Maps pozwala szukać hoteli podczas przeglądania trasy. Pierwsza reakcja była prosta: może cały pomysł nie ma sensu?

Sam regularnie korzystam z Map Google, a o tej możliwości dowiedziałem się dopiero wtedy, gdy celowo zacząłem jej szukać. W sprawdzonym flow brakowało mi też jasnego określenia, jak daleko mogę zjechać z drogi, oraz wygody porównywania obiektów takiej jak w serwisie rezerwacyjnym.

Google Maps: trasa Opole → Trogir, 11 godzin 38 minut, 1179 km, nad mapą pasek Szukaj miejsc przy trasie i skróty Hotele, Stacje paliw, Ładowarki EV, Atrakcje, Kempingi
Wejście stoi nad trasą

Pasek „Szukaj miejsc przy trasie” i pięć skrótów: Hotele, Stacje paliw, Ładowarki EV, Atrakcje, Kempingi.

Google Maps: lista Hotele przy trasie po lewej, na mapie ceny od 271 do 474 zł rozrzucone od Opola po Trogir
Ceny wzdłuż całej drogi

Wyniki rozkładają się od Opola po Trogir. Nie da się ustawić, jak daleko od drogi może leżeć nocleg ani w którym miejscu trasy chcę się zatrzymać.

Google Maps: panel filtrów z oceną, klasą hotelu i listą udogodnień, obok trasa z cenami
Filtry są, odległości od trasy nie ma

Ocena, klasa hotelu i kilkanaście udogodnień. Wśród nich nie ma zjazdu z drogi.

Google Maps: Szukaj miejsc przy trasie, lista atrakcji pogrupowana według miast Brno, Bratysława i Wiedeń, przy każdym mieście informacja Wydłuży trasę o 15 minut albo o godzinę
Wzorzec, którego brakuje hotelom

„Atrakcje” grupują wyniki po kolejnych miastach na trasie i przy każdym podają koszt: „Wydłuży trasę o 15 min”. Hotele tego podziału nie dostają.

Zrzuty z 12 i 20.09.2026. To przegląd interfejsu, nie badanie odkrywalności: to, że funkcję znalazłem dopiero celowo, jest moim doświadczeniem, nie pomiarem.

Nie próbowałem udowodnić, że nikt na świecie nie dotknął tego problemu. Zawęziłem diagnozę: istniejące elementy są dostępne, ale nie spotykają się w momencie decyzji i w formie, której potrzebuje osoba szukająca jednego noclegu tranzytowego.

Rozwiązanie

Nie potrzebowałem nowej aplikacji.

Rozważałem osobną aplikację, rozszerzenie przeglądarki, Airbnb i Booking. Każdy kierunek wyglądał ciekawie, dopóki nie zadałem sobie pytania: co właściwie próbuję stworzyć, a co już istnieje?

Brak dostępu do API i danych Bookingu zamknął ścieżkę realnego rozszerzenia. Zamiast udawać, że to nie problem, potraktowałem projekt jako propozycję funkcji wewnątrz Booking.com. Ograniczenie nie zabiło projektu. Powiedziało mi po prostu, jaki projekt naprawdę robię.

Booking już to ma
  • Baza noclegów
  • Ceny i dostępność
  • Opinie
  • Filtry: parking, śniadanie, ocena, typ obiektu
  • Rezerwacja i płatność
Dokładam

Kontekst trasy, którego brakowało podczas mojej podróży.

Fragment makiety wariantu A: panel Zaplanuj trasę i mapa z okręgiem wyników w połowie trasy, z pięcioma numerowanymi oznaczeniami
Fragment wariantu A. Numery odpowiadają decyzjom obok.

Jedna nowa warstwa, pięć prostych decyzji

  1. Punkt A i B albo link z Google Maps

    Użytkownik podaje początek i cel, a system wyznacza drogę. Nikt jej nie rysuje.

  2. Zjazd: 10, 25 albo 50 km

    Maksymalna odległość noclegu od trasy, ustalona z góry.

  3. Postój w procencie trasy

    Sugerowane miejsce zatrzymania, domyślnie w połowie drogi.

  4. Okrąg przytwierdzony do trasy

    Obszar wyników można przesuwać tylko po jej przebiegu, jak po szynie.

  5. Ceny tylko w wybranym obszarze

    Na mapie zostają noclegi z tego fragmentu drogi, a nie z całej trasy.

Filtry zostają

Wszystkie obecne filtry Bookingu działają dalej. Gdy ktoś potrzebuje parkingu, śniadania albo obiektu z oceną powyżej ośmiu, nie potrzebuje nowej wersji tych filtrów. Potrzebuje, żeby działały również dla noclegów po drodze.

Świadomie poza zakresem zostały ręczne rysowanie trasy, bo do dokładniejszego fragmentu wystarcza zwykły zoom mapy, oraz kilka noclegów na jednej trasie.

Dwa warianty odpowiadały na dwa różne ryzyka.

Moja hipoteza była taka, że wariant B może być mniej inwazyjny, bo wykorzystuje znany układ. Nie przedstawiam tego jako pewnego, taniego wdrożenia: bez zespołu technicznego Bookingu byłaby to tylko wygodna historia. Oba kierunki są materiałem do porównania, nie gotową odpowiedzią.

Wariant A: osobny widok planowania

Dużo przestrzeni na mapę, pola Opole i Trogir, wybór zasięgu i punktu postoju. Czytelny i od razu tłumaczy nową funkcję. To ten kadr z początku strony.

Wariant B: panel w istniejącej mapie

Ten sam mechanizm w obecnym widoku mapy Bookingu. Złożyłem go na oryginalnym układzie serwisu: lista obiektów i filtry zostają po lewej, a panel trasy i mapę dołożyłem sam.

Makieta wariantu B: po lewej filtry i lista hoteli z Mariboru i Grazu, na mapie panel Skąd Opole, Dokąd Trogir, zasięg 10 km i postój na 50% trasy, trasa przez Ostrawę, Brno i Wiedeń, okrąg z cenami przy Mariborze
Wariant B po poprawkach. Układ i lista obiektów pochodzą z Bookingu, panel trasy i mapa są moje. Okrąg leży w rejonie Grazu i Mariboru, a lista pokazuje obiekty z tego samego obszaru. Mapa jest celowo uproszczona, bez mniejszych miejscowości i dróg, żeby było widać sam mechanizm. W prawdziwym produkcie byłaby to zwykła mapa Bookingu.

Młot i kowal

Ładna makieta potrafiła być merytorycznie błędna.

Wariant A budowałem z pomocą narzędzi AI, a wariant B składałem na oryginalnym układzie Bookingu. To dokładnie ten moment, w którym łatwo pomylić szybki obrazek z wykonaną pracą projektową.

  1. Efektowne, ale bez geografii

    Pierwsze próby wyglądały efektownie, ale nie trzymały geografii. Trasa była zbyt ogólna, a obszar wyników nie siedział tam, gdzie wynikało to z logiki rozwiązania.

    Wczesna makieta: panel Skąd i Dokąd, mapa bez nazw miast, ogólnie naszkicowana trasa i ceny rozsiane wzdłuż całej drogi
    Wczesna makieta: mapa bez nazw miast, trasa naszkicowana ogólnie, ceny wzdłuż całej drogi zamiast w jednym obszarze.
  2. Zmiana materiału, nie długości promptu

    Najwięcej czasu straciłem nie na samym tworzeniu wariantów, tylko na słabych assetach wejściowych. Kiedy to zrozumiałem, nie ratowałem wszystkiego coraz dłuższym promptem. Dostarczyłem prawdziwy zrzut trasy, wskazałem jej właściwy wariant i rozpisałem zasady, których ekran ma pilnować.

    Google Maps: trzy warianty trasy z Opola do Trogiru, wybrany najciemniejszy przez Brno, Wiedeń i Zagrzeb
    Źródło, które dostarczyłem. Liczyła się tylko jedna z trzech tras.

    Zasady ekranu

    • Start w Opolu, cel w Trogirze
    • Poprawne miasta po drodze
    • Linia przechodzi przez środek okręgu
    • Wyniki tylko w jego granicach
    • Wygląd spójny z Bookingiem
  3. Dobra architektura, błędna historia

    W jednej z wersji wariantu B punkt startowy zmienił się z Opola na Szczecin. Wizualnie było blisko Bookingu. Merytorycznie było źle.

    Odrzucona makieta wariantu B: pole Skąd pokazuje Szczecin, trasa biegnie przez Polskę i Węgry, lista noclegów po lewej jest ze Szczecina
    Odrzucony ekran: start w Szczecinie, trasa przez Budapeszt, lista noclegów ze Szczecina.
  4. Poprawiona etykieta to jeszcze nie poprawiony ekran

    Po pierwszej korekcie w polu startu było już Opole, więc pozornie zadanie było wykonane. Kiedy spojrzałem na cały flow, nadal się nie zgadzał: trasa odbijała za mocno pod Pragę, okrąg wylądował za nisko przy Zagrzebiu, a lista wciąż pokazywała noclegi ze Szczecina. Nie wystarczyło naprawić jednego słowa.

  5. Jeden logiczny stan interfejsu

    Musiałem ponownie sprawdzić relację między punktem startowym, przebiegiem drogi, miejscem postoju i wynikami. Dopiero w kolejnej iteracji skleiłem je w jeden logiczny stan: trasa przez Ostrawę, Brno i Wiedeń, okrąg przy Grazu i Mariborze, lista z tego samego obszaru. To wariant B pokazany wyżej.

Odrzucałem też założenia z odpowiedzi AI, które nie wynikały z produktu.

Rysowanie trasy palcem

Użytkownik podaje początek i cel. Trasę wyznacza system.

Filtry do zaprojektowania od nowa

Parking, śniadanie i ocena już działają w Bookingu.

Dostępność jako nowy problem backendu

Platforma już pokazuje ją na mapie.

Każde takie założenie sprawdzałem wobec działania rozwiązania, a nie wobec tego, jak profesjonalnie brzmiało w tekście.

AI jest młotem. Ja nadal muszę wiedzieć, gdzie uderzyć, i zauważyć, kiedy gwóźdź wszedł krzywo.

Rezultat

Nie dopisuję wyników do produktu, który nie został wdrożony.

To jest koncepcja, nie funkcja Bookingu. Nie mam wzrostu konwersji, testu A/B ani danych, które pozwalają powiedzieć, że rozwiązanie działa lepiej od obecnego procesu.

Następnym krokiem nie byłoby dalsze polerowanie UI, tylko sprawdzenie mechaniki na ludziach planujących długą podróż samochodem. Dałbym im to samo zadanie w obecnym Bookingu i w obu wariantach koncepcji.

Zadanie testowe

Znajdź nocleg mniej więcej w połowie trasy Opole → Trogir, maksymalnie 25 km od drogi.

Poprawność
Czy potrafią znaleźć nocleg w określonym miejscu trasy i limicie zjazdu.
Czas
Ile czasu zajmuje im dojście do sensownego wyboru.
Druga mapa
Czy nadal otwierają drugą mapę, żeby zweryfikować decyzję.
Pewność
Jak pewni są wyboru przed rezerwacją.

Po wdrożeniu mierzyłbym też

  • Użycie trybu trasy
  • Przejście od wyszukiwania do rezerwacji
  • Czas do rezerwacji
  • Porzucenia
Granica danych

Dopiero po takim teście wybierałbym wariant i poprawiał interakcję. Dzisiaj są to kryteria sukcesu, nie sukces.

Nie przeprowadziłem formalnych wywiadów z użytkownikami ani testów makiet. Punktem wyjścia jest mój rzeczywisty problem i analiza istniejących sposobów jego rozwiązania. Rzetelny test wymagałby działającego prototypu na prawdziwych danych, a do nich bez API Bookingu nie mam dostępu.

Wniosek

Najważniejszym rezultatem nie jest ekran z niebieską trasą.

Najwięcej nauczył mnie moment, w którym musiałem przestać bronić pierwszej wersji pomysłu. Google Maps miało już część rozwiązania. Nie miałem dostępu do Bookingu od środka. Makiety, które budowałem z pomocą AI, potrafiły wyglądać dobrze i jednocześnie łamać podstawową logikę.

W każdym z tych momentów mogłem dorobić historię tak, żeby projekt wydawał się pełniejszy. Zamiast tego zawężałem problem, odrzucałem wygodne założenia i wracałem do pytania, które uruchomiło całą pracę:

Jak znaleźć nocleg po drodze bez zgadywania, czy naprawdę jest po drodze?