Wygoda ↔ kontrola
Biuro ma zdjąć z użytkownika organizację, ale nie może odebrać mu poczucia wpływu.
CASE STUDY / UX RESEARCH · EXPERIENCE STRATEGY
Projekt badawczy doświadczenia zakupu wycieczki z biurem podróży. Zamiast projektować gotowy interfejs, skupiłam się na tym, co powinno powstać przed UI: zrozumieniu potrzeb, ryzyk, zachowań i momentów, w których użytkownik traci pewność decyzji.
UX-only case study. W tym projekcie nie powstał finalny UI strony ani aplikacji. Pokazuję proces badawczy i decyzje, które miały przygotować rozwiązanie do kolejnego etapu projektowania.
OBSZAR PROBLEMU
Materiały badawcze powtarzały ten sam wzorzec: użytkownik chce wygody biura podróży, ale jednocześnie obawia się utraty kontroli nad pieniędzmi, pokojem, zmianami po zakupie i możliwością uzyskania pomocy.
Biuro ma zdjąć z użytkownika organizację, ale nie może odebrać mu poczucia wpływu.
Tańsza oferta nie wystarcza, gdy nie wiadomo, czy opis, pokój i warunki pozostaną niezmienione.
Duża liczba kierunków i filtrów pomaga dopiero wtedy, gdy informacja ma dobrą hierarchię.
Zdjęcie sprzedaje marzenie, ale decyzję domykają zweryfikowane opinie, warunki i możliwość kontaktu.
„Nie mam czasu na szukanie samemu wakacji.”Empathy Map / Think & Feel
„A co jeśli biuro przestanie istnieć?”Empathy Map / obawa o bezpieczeństwo
„Nie mogę znaleźć dobrej oferty na stronie.”Empathy Map / friction
„Finalizowanie na laptopie, czytelniejsze to jest.”Notatki z wywiadów / zachowanie na urządzeniach
EVIDENCE BEFORE IDEAS
Proces łączył dane z desk research, badania jakościowe, syntezę oraz benchmarking konkurencji. Dopiero potem powstały persona, empathy map, journey i scenariusz użytkownika.
Źródła obejmowały m.in. Raport Podróżnika, materiały UOKiK/TNS, rankingi biur i raporty o trendach wakacyjnych.
Wybór biura zależy nie tylko od ceny. Respondenci sprawdzali wielkość firmy, opinie, stabilność i możliwość uzyskania pomocy.
Materiały wskazują na przełączanie urządzeń: szybkie przeglądanie na telefonie, bardziej wymagające porównanie i finalizacja na większym ekranie.
Zmiana warunków po zakupie, brak kontaktu i rozbieżność między ofertą a rzeczywistością były ważniejszymi frustracjami niż sam brak funkcji.
TUI, ITAKA i Rainbow zostały porównane przez wyszukiwanie, listę ofert, szczegóły i opinie. Coral Travel pominięto, bo wyszukiwanie nie zwracało ofert.
Zweryfikowane opinie, jasne warunki, kontakt z doradcą i możliwość krótkiej rezerwacji wstępnej tworzą jeden system redukcji ryzyka.
ANNA + FILIP
Persona porządkuje najważniejsze zachowania z researchu: ograniczony czas, wysokie oczekiwania, potrzebę bezpieczeństwa i skłonność do lojalności wobec biura, które raz dowiozło dobre doświadczenie.
PRIMARY PERSONA
„Wszystko takie drogie.”
„Nie mam czasu na szukanie samemu.”
„A co jeśli biuro przestanie istnieć?”
Posty z wakacji znajomych.
Reklamy oraz negatywne opinie o hotelach i biurach.
Rekomendacje znajomych.
Historie o opóźnionych lotach i nieudanych wakacjach.
Porównuje ceny i hotele.
Pyta znajomych o biura oraz miejsca.
Odwołanie wycieczki w ostatniej chwili.
Brak kontaktu i zmiany po zakupie.
Oferta niezgodna z rzeczywistością.
Wygoda i mniej organizacji.
Pomoc w razie problemów.
Możliwie lepsza cena pakietu.
TUI · ITAKA · RAINBOW
Analiza była rozbita na cztery momenty doświadczenia. Dzięki temu dobre wzorce i problemy można było przenieść do wymagań UX, zamiast kopiować rozwiązania 1:1.
Notatka z analizy: w materiale źródłowym TUI zostało wskazane jako najlepsze rozwiązanie ogólne. Coral Travel nie trafił do porównania, ponieważ wyszukiwanie nie zwracało ofert.
FROM INTENT TO ADVOCACY
Mapa doświadczenia pokazuje ścieżkę od pierwszego impulsu do polecenia biura. Najniższe emocje pojawiają się nie tylko przy szukaniu, ale również przy rejestracji i ryzyku po zakupie.
„Jesteśmy zmęczeni. Potrzebujemy wakacji.”
Trigger: odpoczynekGoogle, rekomendacje i pierwsze porównanie biur.
Risk: brak zaufaniaFunkcje strony, opinie, informacje o firmie i konkretne oferty.
Potrzeba: wiarygodnośćFormularz pojawia się jako warunek zapisania interesującej oferty.
Bariera: wymuszone kontoPreferencje → dopasowana lista → opinie → rezerwacja wstępna.
Potrzeba: porównanieZakup, podsumowanie, weryfikacja i doświadczenie samego wyjazdu.
Potrzeba: pewnośćOpinia, kontakt z przyszłymi podróżnymi i rekomendacje.
Rezultat: rekomendacjaJeśli produkt obiecuje „wakacje bez organizacyjnego stresu”, doświadczenie cyfrowe nie może przenosić tego stresu na użytkownika w formie przeciążonych filtrów, niejasnych zasad i braku kontaktu po płatności.
ANIA + FILIP / GRAN CANARIA
Nie jest to makieta interfejsu. To test logiki usługi: co użytkownik robi, kiedy potrzebuje pomocy i które elementy muszą zachować ciągłość między telefonem a laptopem.
Po próbie samodzielnej organizacji para decyduje się na biuro podróży i Gran Canarię.
Reklama w Google prowadzi do przeglądania ofert na telefonie: Hiszpania, Grecja, Cypr.
Filtry i sortowanie redukują liczbę wyników do sensownego zestawu.
Dodanie do ulubionych prowadzi do rejestracji; po niej mogą zachować wybrane wycieczki.
Każde przegląda osobno, a potem wspólnie porównują sześć najlepszych ofert.
Dokładnie czytają opinie i sprawdzają hotel również w innych źródłach.
Czat z doradcą pomaga domknąć pytania i prowadzi do rekomendacji jednej oferty.
Rezerwacja wstępna daje czas na decyzję; scenariusz zakłada zwrotną zaliczkę.
Finalna decyzja i płatność odbywają się na większym ekranie.
Potwierdzenie, prawo odstąpienia, instrukcja pomocy i pełne podsumowanie oferty.
SYNTEZA → ZASADY
Poniższe zasady wynikają z materiału Sky Travel. Sekcja „2026 refinement” odróżnia oryginalne wnioski projektu od tego, co dziś dopracowałabym przed przejściem do UI.
Wiarygodność biura, zweryfikowane opinie i zasady zmian muszą być widoczne tam, gdzie użytkownik podejmuje ryzyko finansowe.
Oferta ma pomagać porównać stały zestaw cech, nie tylko eksponować fotografię i promocyjną cenę.
Czat / doradca / rezydent są częścią service UX. Kontakt powinien mieć oczekiwany czas odpowiedzi i jasny status.
Telefon służy odkrywaniu, laptop porównaniu i finalizacji. Zapisane kryteria, shortlist i etap procesu powinny przechodzić między urządzeniami.
Potwierdzenie, dokumenty, warunki zmiany i pomoc na miejscu nie są „obsługą po sprzedaży”, są integralną częścią doświadczenia.
Największą wartość mają opinie osadzone w kontekście: typ wyjazdu, termin, hotel i potwierdzenie uczestnictwa.
2026 REFINEMENT
To nie dopisuje funkcji do starego projektu. To świadome rozwinięcie założeń przy obecnych standardach UX.
Nie blokowałabym zapisu oferty natychmiastową rejestracją. Tymczasowy shortlist może działać lokalnie, a konto pojawić się dopiero przy synchronizacji / hold.
Filtry dzielone na „najważniejsze” i „więcej”, z liczbą wyników aktualizowaną przed zatwierdzeniem.
Warunki anulowania, zmiany hotelu i zwrotów powinny być zwięzłe, porównywalne i pokazane przed płatnością.
WCAG 2.2 AA, pełna obsługa klawiaturą, czytelne stany, targety dotykowe ≥44 px i brak informacji przekazywanej wyłącznie kolorem.
Tożsamość i dane dokumentu tylko wtedy, gdy są faktycznie wymagane prawnie lub operacyjnie, nie jako koszt wejścia do zwykłych badań ofert.
Wyraźny awaryjny flow: „moja oferta się zmieniła” → status → osoba odpowiedzialna → opcje rozwiązania → ślad decyzji.
NO FAKE KPI
Sky Travel był projektem koncepcyjnym, dlatego zamiast deklarować nieistniejące wyniki produkcyjne, definiuję sygnały, które warto zweryfikować w prototypie i po wdrożeniu.
Czas potrzebny do znalezienia 3 ofert spełniających kluczowe kryteria.
Czy użytkownik poprawnie rozumie cenę, pokój, wyżywienie i zasady zmiany bez dodatkowej pomocy.
Deklarowana pewność przed rezerwacją i po przeczytaniu trust evidence.
Gdzie użytkownik porzuca zawężanie wyników lub resetuje kryteria.
Odsetek osób, które bez utraty kontekstu kontynuują shortlist / checkout na drugim urządzeniu.
Czy pytanie lub problem kończy się rozwiązaniem bez ponownego kontaktowania się innym kanałem.
TRAVEL / EXPERIENCE09 / REZULTAT
Projekt porządkuje, gdzie użytkownik potrzebuje szybkości, gdzie kontroli, a gdzie dowodu bezpieczeństwa. Dzięki temu kolejny etap: architektura informacji, wireframes i UI, może zacząć się od jasno określonych priorytetów, zamiast od estetycznych założeń.
KIERUNEK WIZUALNY
To nie jest zamknięty projekt gotowych ekranów, lecz przykładowe przełożenie wniosków z researchu na język interfejsu. Pomaga wspólnie ocenić hierarchię informacji, sposób budowania zaufania i charakter przyszłego produktu przed rozpoczęciem projektowania widoków.
ZACZNIJMY OD DOBREGO PYTANIA
Od odkrywania i syntezy po jasne wymagania UX, bez przeskakiwania od briefu prosto do „ładnych ekranów”.