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.
- 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ą.
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. 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ć.
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 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.
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 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ę.
- 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 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ą.
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. To dokładnie ten moment, w którym ł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 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ć.
-
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.
-
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.
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 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.
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
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?