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.
- 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ą.
Przebieg trasy, czas przejazdu i miasta po drodze. Żadnych cen ani dostępności.
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ć.
Jak zrobić kolejną mapę z hotelami?
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.
Pasek „Szukaj miejsc przy trasie” i pięć skrótów: Hotele, Stacje paliw, Ładowarki EV, Atrakcje, Kempingi.
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ć.
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ę.
- Baza noclegów
- Ceny i dostępność
- Opinie
- Filtry: parking, śniadanie, ocena, typ obiektu
- Rezerwacja i płatność
Kontekst trasy, którego brakowało podczas mojej podróży.
Jedna nowa warstwa, pięć prostych decyzji
-
Punkt A i B albo link z Google Maps
Użytkownik podaje początek i cel, a system wyznacza drogę. Nikt jej nie rysuje.
-
Zjazd: 10, 25 albo 50 km
Maksymalna odległość noclegu od trasy, ustalona z góry.
-
Postój w procencie trasy
Sugerowane miejsce zatrzymania, domyślnie w połowie drogi.
-
Okrąg przytwierdzony do trasy
Obszar wyników można przesuwać tylko po jej przebiegu, jak po szynie.
-
Ceny tylko w wybranym obszarze
Na mapie zostają noclegi z tego fragmentu drogi, a nie z całej trasy.
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ą.
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.
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.
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ą.
-
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: mapa bez nazw miast, trasa naszkicowana ogólnie, ceny wzdłuż całej drogi zamiast w jednym obszarze. -
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ć.
-
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.
-
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.
Użytkownik podaje początek i cel. Trasę wyznacza system.
Parking, śniadanie i ocena już działają w Bookingu.
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.
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
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?