System Fala
Kompleksowy redesign oparty o analizę ponad 100 recenzji, wywiady IDI z pasażerami i 25-stronicowy audyt heurystyczny. Projekt skupiony na ujednoliceniu interfejsu zakupu i funkcji biletowania.
Zobacz prototyp ↗
- Title
- System Fala
- Industry
- Aplikacja mobilna B2C / Transport publiczny / Sektor publiczny
- Role
- UX Research, UI Design, współpraca z QA
- Tools
- Figma, analiza App Store / Google Play
- Date
- 2026
Przegląd i kontekst rynkowy
System Fala to zintegrowany ekosystem biletowy obsługujący transport miejski oraz kolejowy w województwie pomorskim. Od sierpnia 2025 roku, po konsolidacji kanałów sprzedaży biletów okresowych, aplikacja stała się główną regionalną platformą transakcyjną dla ruchu masowego. Zmiana ta wywołała gwałtowny wzrost wolumenu transakcji, stawiając interfejs przed wyzwaniem natychmiastowej obsługi zróżnicowanej bazy pasażerów. Zderzenie założeń systemowych z opiniami użytkowników (Review Mining) wskazało na pilną potrzebę wdrożenia rozwiązań zwiększających pewność podróży w warunkach ograniczonego dostępu do sieci.
→Wyzwania biznesowe:
Lokalizacja i eliminacja krytycznych punktów oporu kognitywnego (low-hanging fruits) w celu odbudowania zaufania pasażerów i poprawy doświadczenia z aplikacją.
→Cel główny:
Uproszczenie procesu wyszukiwania biletów (geograficzny selektor miast) oraz wdrożenie bezpiecznego i bezstresowego trybu offline na potrzeby kontroli biletowej.
→Pragmatyzm techniczny:
Poszanowanie i utrzymanie stabilnych, sprawdzonych wzorców funkcjonalnych systemu przy minimalnym zaangażowaniu zasobów deweloperskich.
→Inkluzywność (Dostępność):
Dostosowanie kluczowych elementów interfejsu w wersji standardowej i uproszczonej do wytycznych WCAG 2.2 na poziomie AA, gwarantujące czytelność w trudnych warunkach.
Odkrywanie
4 metody badawcze
Nieformalne wywiady z użytkownikami
Rozmawiałam z osobami jeżdżącymi komunikacją trójmiejską na co dzień. Rozmowy były swobodne, właśnie dlatego szczere. Dowiedziałam się o emocjach, które nie trafiają do recenzji: Marta stresuje się już na widok kontrolera w tramwaju, bo nie wie, czy aplikacja się otworzy i czy zdąży pokazać bilet.
„Jak jedzie kontroler, to ja już wiem, że będzie problem.”
Analiza heurystyczna
Przeszłam przez wszystkie kluczowe przepływy aplikacji i udokumentowałam naruszenia zasad projektowania interakcji. Zidentyfikowałam 16 problemów w 6 obszarach: wybór organizatora, wyszukiwanie tras, zakup biletów, wydajność, hierarchia wizualna, onboarding. Ta metoda ujawnia co jest zepsute. Recenzje mówią jak bardzo.
Mining recenzji (67 opinii)
Przeanalizowałam tematycznie 40 recenzji z App Store i 27 z Google Play. Trzy tematy dominowały: sesja (wylogowanie przy każdym otwarciu, po każdej aktualizacji), brak trybu offline i nieintuicyjny zakup biletów. Użytkownicy nie wiedzieli jak dotrzeć do zakupu, rezygnowali i kupowali papierowe. Osobna kategoria: użytkownicy nie rozumieją co kupują, opisy biletów nie istniały, infolinia też nie potrafiła wyjaśnić.
„Za każdym razem gdy chcę okazać bilet muszę się ponownie logować. Przy kontrolerze to naprawdę stresujące.”
Benchmark konkurencji
Porównałam Falę z JakDojade, moBilet i SkyCash według 13 kryteriów. Fala była jedyną aplikacją bez trybu offline. To standard, który SkyCash wdrożył już w 2014 roku. Wszystkie trzy aplikacje używają zrozumiałych nazw biletów: „jednorazowy”, „dobowy”. Fala miała „Krótkookresowe” i „Długookresowe”.
Persony
Cztery typy użytkowników
Marta
Komutantka
Dojeżdża codziennie z Gdańska do Gdyni. Stresuje się przy każdej kontroli, nie wie, czy aplikacja się otworzy, czy bilet będzie dostępny. Cel: bilet miesięczny zawsze pod ręką, zero stresu przy kontrolerze.
Tomasz
Okazjonalny pasażer
Szuka biletu jednorazowego w 30 sekund. Rezygnuje i kupuje bilet papierowy, gdy flow trwa ponad 2 minuty. Nie rozumie różnicy między ZTM, ZKM i SKM.
Kasia
Turystka
Nieznająca struktury operatorów. Kupiła zły bilet, bo interfejs odzwierciedlał podział instytucjonalny, nie jej model mentalny. Nie mogła sprawdzić cen bez założenia konta.
Sławek
Pasażer SKM
Mówił znajomym, że „Fala nie obsługuje SKM”, bo interfejs nie dawał żadnej wskazówki jak się w nim poruszać. Dezinformacja się rozchodziła.
Jobs to be Done
Co użytkownik chce osiągnąć
Kupić bilet przy nadjeżdżającym autobusie
Bloker (przed)
Selektor organizatora niewidoczny jako kontrolka, 30+ biletów bez struktury
Po redesignie
Nowy selektor z grupowaniem, uproszczone kategorie, Bilety pierwsze w nav
Pokazać bilet przy kontroli bez zasięgu
Bloker (przed)
Brak trybu offline
Po redesignie
Tryb offline wdrożony
Zrozumieć status biletu w 2 sekundy
Bloker (przed)
Brak statusu QR kodu, słaby kontrast, cena ukryta
Po redesignie
Nagłówek statusu, białe tło QR, cena widoczna
Wybrać właściwego organizatora
Bloker (przed)
Płaska lista bez grupowania, zaznaczenie przez małe radio button
Po redesignie
Podział Transport miejski / Kolej, toggle na cały wiersz, ikony transportu
Zrozumieć ofertę jako nowy użytkownik
Bloker (przed)
Nazwy Krótkookresowe / Długookresowe bez kontekstu czasowego
Po redesignie
Jednorazowe / Dzienne / Okresowe z opisem czasu
Kluczowe decyzje projektowe
Co i dlaczego zmieniłam
Selektor organizatora
Problem
W starej wersji aplikacji pole wyboru organizatora było praktycznie niewidoczne. Użytkownik trafiał bezpośrednio na listę biletów, a w zależności od kategorii mogło ich być nawet pięćdziesiąt na jednym ekranie. Żadnego filtrowania, żadnej struktury. Dodatkowo lista organizatorów operowała oficjalnymi nazwami instytucjonalnymi: MZKZG, ZKM w Gdyni, POLREGIO S.A. Dla kogoś, kto nie zna administracyjnej struktury trójmiejskiego transportu, te skróty nic nie mówią.
Rozwiązanie
Przeprojektowałam samo pole selektora, teraz jest wyraźnie widoczne, wygląda jak kontrolka, w którą można kliknąć, i jednoznacznie komunikuje, że wybór obszaru jest wymagany. Listę organizatorów zmieniłam z oficjalnych nazw instytucjonalnych na nazwy geograficzne według miast (Gdańsk, Gdynia, Lębork) z ikonami typów transportu i switchem na cały wiersz zamiast małego radio buttona. Organizatorów podzieliłam na dwie grupy: Transport miejski i Kolej. Usunęłam opcję „Wszyscy organizatorzy”, teraz wybór obszaru jest pierwszym krokiem, a lista biletów filtruje się od razu.
Kategorie biletów
Problem
Nazwy kategorii (Krótkookresowe, Średniookresowe, Długookresowe, Wieloprzejazdowe) nie mówiły nic o tym, co jest w środku. Żeby znaleźć właściwy bilet, użytkownik musiał wchodzić kolejno do każdej kategorii i sprawdzać jej zawartość. Żadna z nazw nie dawała wskazówki, czego się spodziewać.
Rozwiązanie
Zmieniłam nazwy na Jednorazowe / Dzienne / Okresowe, z opisem czasu obowiązywania bezpośrednio w etykiecie: do 180 min, do 72h, do 5 mies. Użytkownik od razu wie, co kryje się w każdej kategorii, bez konieczności wchodzenia do środka. Te nazwy funkcjonują też w innych aplikacjach transportowych. Użytkownik, który zna JakDojade czy moBilet, już wie, o co chodzi.
Lista połączeń SKM
Problem
Lista wyników dla trasy kolejowej pokazuje kursy SKM i Polregio, ale nie dawała żadnego sygnału, że można stąd kupić bilet. Przycisku nie było. Żeby dotrzeć do zakupu, trzeba było wiedzieć, że należy kliknąć głębiej w konkretny kurs. Wielu użytkowników po prostu tego nie odkrywało i wychodziło z aplikacji, nie wiedząc, że możliwość zakupu istniała.
Rozwiązanie
Wyniosłam przycisk „Kup bilet” bezpośrednio do wiersza wyników, widoczny przy każdym kursie, bez konieczności wchodzenia głębiej. Ta zmiana nie tylko ułatwia zakup, ale może bezpośrednio przełożyć się na wzrost liczby transakcji: użytkownicy, którzy wcześniej nie odnajdywali ścieżki zakupu, teraz widzą ją od razu. Gdyby była możliwość pomiaru, patrzyłabym na conversion rate funnela: odsetek użytkowników, którzy przeszukali trasę i skończyli zakupem. Wzrost tego wskaźnika bezpośrednio potwierdziłby skuteczność tej zmiany. Dodałam też chipy „SKM” / „PR” przy każdym kursie (fiolet spójny z systemem kolorów kolei) i powiększyłam godzinę odjazdu, najważniejszą informację przy wyborze kursu.
Tryb offline i widok biletu
Problem
Aplikacja wymagała połączenia z internetem żeby wyświetlić zakupiony bilet. W metrze, w tunelu, przy słabym zasięgu, ważny bilet stawał się niedostępny. Dokładnie w momencie, gdy był najbardziej potrzebny: przy kontrolerze. Sam widok biletu nie pomagał: kod QR nie miał wyraźnego statusu ważności, brakowało białego tła pod kodem (słaby kontrast przy skanowaniu). Ceny nie było widać wcale, użytkownik widział ją tylko przy zakupie. Tymczasem kontrolerzy często weryfikują bilet właśnie po cenie, żeby szybko ocenić jaki to rodzaj biletu.
Rozwiązanie
Tryb offline został wdrożony: bilet zapisuje się lokalnie po zakupie i jest dostępny bez połączenia z internetem. Internet potrzebny jest tylko do zakupu. Równolegle przeprojektowałam widok biletu: dodałam status ważności kodu QR z licznikiem czasu („Kod ważny jeszcze 00:15”), białe tło pod kodem dla czytelności przy skanowaniu oraz cenę biletu widoczną na ekranie biletu, dla użytkownika i dla kontrolera. Tło ekranu zmienione na ciepłą żółć (#FEF3C7), spójne z systemem kolorów aplikacji i natychmiast rozpoznawalne.
System kolorów
Przed
Problem
Kolej (SKM i Polregio) była oznaczona szarym kolorem w ikonach i elementach wizualnych. Szary na mapie i na listach łatwo przeoczyć. Logo Fali ma cztery kolory, z których trzy były już przypisane do konkretnych środków transportu. Czwarty, fioletowy, nie pełnił żadnej funkcji semantycznej w interfejsie.
Po
Rozwiązanie
Przypisałam fioletowy do kolei. Kolor już istniał w systemie identyfikacji wizualnej Fali, nie był zajęty, wystarczyło nadać mu znaczenie. SKM i Polregio są teraz spójnie oznaczone fioletowym w chipach, ikonach i nagłówkach sekcji. Na mapie i liście wyników kolej jest natychmiast rozpoznawalna i nie gubi się w tle. Do nagłówków sekcji biletowych dodałam elementy graficzne nawiązujące do logotypu systemu, pomagają użytkownikowi orientować się w strukturze oferty i szybko nawigować między sekcjami.
Efekty
Co się zmieniło
Tryb offline eliminuje najczęstszy P0 z recenzji i zamyka jedyną lukę na tle polskiego rynku aplikacji transportowych.
Przeprojektowany selektor organizatora usuwa barierę, której użytkownicy nawet nie umieli nazwać.
Uproszczone kategorie i spójny system kolorów skracają czas do pierwszego zakupu.
Wdrożenia właśnie się skończyły. Danych jeszcze nie ma. Byłoby nieuczciwe udawać, że są.
Gdybym miała dostęp do analityki, mierzyłabym skuteczność frameworkiem HEART:
- Happiness
- Ocena w sklepach jako punkt wyjścia. Interesowałaby mnie nie tylko średnia, ale zmiana tonu recenzji dotyczących kontroli biletowej i offline. Te dwa tematy dominowały w mining i powinny zniknąć po redesignie.
- Engagement
- Czy użytkownicy wracają do aplikacji zamiast kupować bilety papierowe. Jeśli nie, aplikacja wciąż nie wzbudza zaufania.
- Adoption
- Odsetek biletów otwieranych w trybie offline. To bezpośredni dowód, że nowa funkcja działa i użytkownicy jej ufają.
- Retention
- Aktywność po 30 dniach. Przy aplikacji z monopolem to szczególnie ważna metryka: wysoka retencja oznacza, że użytkownicy korzystają z wyboru, nie z przymusu.
- Task Success
- Conversion rate funnela: wyszukanie trasy → zakup biletu. Główna metryka dla decyzji o wyniesioniu przycisku „Kup bilet” na listę połączeń SKM.
Do priorytetyzacji kolejnych zmian użyłabym opportunity score z JTBD: ile dane zadanie jest dla użytkownika ważne minus ile jest z niego zadowolony. Tam, gdzie różnica jest największa, problem jest najbardziej realny.
Interaktywny prototyp
Wypróbuj aplikację
Klikaj po interfejsie, poniżej działa mobilny prototyp zbudowany w Figma Make.