CN Wszystkie projekty

Booking.com, niezależny koncept funkcji

Nocleg na trasie w jednym miejscu.

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

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ć noc i nie zaczynać urlopu od dochodzenia do siebie po całym dniu za kierownicą. Nocleg miałem znaleźć ja.

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. Jeszcze po rezerwacji chodziło mi po głowie 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 przekreśliło pomysłu, tylko go doprecyzowało.

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 Google Maps, a o tej możliwości dowiedziałem się dopiero wtedy, gdy celowo zacząłem jej szukać. W tym, co sprawdziłem, brakowało mi też jasnego ustawienia, jak daleko mogę zjechać z drogi, i wygody porównywania obiektów 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 zajął się tym problemem. 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 zostawiłem 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: wariant B może być mniej inwazyjny, bo korzysta ze znanego układu. 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. Właśnie wtedy ł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 samych wariantach, tylko na słabym materiale wejściowym. Kiedy to zrozumiałem, przestałem ratować wszystko coraz dłuższym promptem. Dałem prawdziwy zrzut trasy, wskazałem jej właściwy wariant i spisał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 podał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 na pierwszy rzut oka było po sprawie. Kiedy spojrzałem na całość, nadal coś było nie tak: 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 jeszcze raz sprawdzić, jak punkt startowy, przebieg drogi, miejsce postoju i wyniki pasują do siebie. 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 na tym, jak działa rozwiązanie, a nie na tym, 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órego nikt nie wdrożył.

To koncept, 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ą swojego 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 wybrałbym wariant i dopracował 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 własny 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, od którego wszystko się zaczęło:

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