Jak stworzyć aplikację mobilną do biletów i kontroli wejść

Zacznij od celów, użytkowników i typów wydarzeń

Zanim naszkicujesz ekrany lub wybierzesz bibliotekę do skanowania QR, wyjaśnij problem, który chcesz rozwiązać. Aplikacje biletowe często zawodzą z prostych powodów: bilety trudno znaleźć, kolejki wolno posuwają się naprzód, oszustwa nie są konsekwentnie wykrywane, albo personel nie ma narzędzi do szybkiego działania.

Zdefiniuj problem, który rozwiązujesz

Zapisz 2–3 najważniejsze punkty bolączek prostym językiem. Przykłady:

• Dostarczanie biletów jest niewiarygodne (maile giną, zrzuty ekranu zawodzą, transfery są mylące)
• Kolejki przy wejściu są za długie (ręczne wyszukiwania, zła łączność, niejasne role personelu)
• Często występują oszustwa i duplikaty (wspólne PDFy, ponowne użycie kodów QR)
• Personel nie ma właściwych narzędzi (brak widoku pojemności na żywo, brak ścieżki eskalacji)

To pomaga utrzymać fokus produktu, gdy pojawiają się kolejne prośby o funkcje.

Zidentyfikuj swoich kluczowych użytkowników

Większość produktów biletowych łączy trzy doświadczenia w jednym:

• Uczestnicy: potrzebują bezproblemowego dostępu do biletów, możliwości ich transferu i szybkiego wejścia.
• Personel (skanery): potrzebuje szybkości, jasności i niezawodności pod presją.
• Administratorzy/organizatorzy: potrzebują kontroli (reguły biletowe, obsada, raportowanie) i mniejszej liczby zgłoszeń do wsparcia.

Bądź konkretny, kogo obsługujesz najpierw. MVP skoncentrowane na personelu może wyglądać zupełnie inaczej niż skierowane na uczestnika.

Wybierz typy wydarzeń, które będziesz wspierać

Typ wydarzenia zmienia czas wejścia, wzorce przepływu i reguły walidacji:

• Koncerty / wydarzenia jednoseansowe: jedno duże okno napływu, liczy się szybkość skanowania.
• Konferencje: wiele skanowań identyfikatorów, dostęp do sesji, dostęp oparty na rolach.
• Festiwale wielodniowe: reguły ponownego wejścia, opaski kontra bilety, tryb offline jest krytyczny.

Zdefiniuj, co oznacza „sukces”

Wybierz mierzalne wyniki, które możesz śledzić:

• Mediana czasu skanu (np. mniej niż 2 sekundy)
• Skrócenie czasu oczekiwania w godzinach szczytu
• Liczba zgłoszeń do wsparcia na 1 000 uczestników
• Wskaźnik nieprawidłowych/duplikowanych skanów

Te cele pokierują każdą dalszą decyzją produktową.

Zmapuj podróż biletu i odprawy

Zanim wybierzesz funkcje lub ekrany, zmapuj rzeczywistą podróż z trzech perspektyw: uczestnika, personelu i organizatora. Jasna mapa zapobiegnie niespodziankom „działa w biurze, zawodzi przy bramie”.

Przepływ uczestnika: od biletu do wejścia

Zacznij od najprostszej ścieżki, jakiej oczekuje uczestnik:

Kup/otrzymaj bilet → otwórz aplikację (lub mail/portfel) → szybko znajdź bilet → pokaż kod QR → wejście.

Wypisz każde przekazanie i potencjalne opóźnienie: tworzenie konta, dostarczenie maila, niski poziom baterii, brak sygnału oraz to, jak szybko ktoś może znaleźć właściwy bilet stojąc w kolejce. Zadecyduj, czy uczestnicy muszą się logować, czy wystarczy magic link/tryb gościa.

Przepływ personelu: skanuj, potwierdź, rozwiązuj

Personel potrzebuje powtarzalnej pętli:

Otwórz skaner → zeskanuj → natychmiastowy wynik (ważny/nieprawidłowy/już użyty) → potwierdź wejście → obsłuż wyjątki.

Zmapuj, co personel widzi dla każdego wyniku. „Nieprawidłowy” powinien wyjaśniać powód (zły dzień, zła bramka, anulowane, nie znaleziono) i dalsze kroki. Zmapuj też scenariusze nieudanego skanowania: pęknięte ekrany, odblaski, drukowany kod rozmazany.

Przepływ organizatora: konfiguruj i monitoruj

Organizatorzy zwykle idą tą ścieżką:

Stwórz wydarzenie → ustaw typy biletów i reguły → przypisz role/urządzenia personelu → monitoruj wejścia w czasie rzeczywistym.

Uwzględnij momenty raportowania: oczekiwani vs. zameldowani, czasy szczytu i alerty o nietypowych wzorcach.

Wczesne wyłuskuj przypadki brzegowe

Wypisz przypadki brzegowe teraz, żeby późniejsze decyzje projektowe je wspierały: późne przybycia, ponowne wejście, bilety wielodniowe, VIP/press, lista gości, transfery biletów i odzyskiwanie „zagubionego telefonu”. Każdy przypadek powinien mieć właściciela (personel vs. wsparcie) i jasną ścieżkę rozwiązania.

Wybierz model biletu i reguły walidacji

Zanim zaprojektujesz ekrany lub wybierzesz SDK skanera, zdecyduj, co oznacza „ważny bilet” dla twojego wydarzenia. Jasne modele i reguły zmniejszają ilość zgłoszeń, przyspieszają wejście i utrudniają oszustwa.

Wybierz format biletu

Większość aplikacji używa biletów z kodami QR, bo są szybko wyświetlane, łatwe do zeskanowania i dobrze sprawdzają się przy odprawach offline.

• Kody 1D (barcody) mogą być użyteczne, gdy działają starsze skanery, ale zwykle są wolniejsze i bardziej podatne na błędy na małych ekranach.
• Przepustki NFC (dotknięcie portfela) dają premium-owe wrażenie i mogą być bardzo szybkie, ale wymagają kompatybilnych urządzeń i dodatkowej konfiguracji; najlepiej, gdy kontrolujesz sprzęt na miejscu lub chcesz doświadczenia „tap-in”.

Zdefiniuj, jak działa walidacja

Zacznij od najprostszych reguł dopasowanych do rzeczywistości:

• Jednorazowe vs. wielokrotne użycie (re-entry): Jednorazowe = „zeskanuj raz i potem nieważne.” Wielokrotne wspiera ponowny wjazd, ale warto ustawić reguły typu „jedno aktywne wejście na raz” lub cooldown między skanami, aby ograniczyć przekazywanie przepustki.
• Wydarzenia wielodniowe: dodaj ważność na konkretny dzień (np. ważne tylko w Dzień 2) lub flagę „ważne przez wszystkie dni”. Wynik skanu powinien jasno pokazywać, które dni pozostały.
• Bilety miejscowe vs. wejście ogólne: bilety na miejsca muszą walidować sekcję/rząd/miejsce (opcjonalnie bramkę). Wejście ogólne zwykle waliduje tylko typ biletu i okno czasowe.

Utrzymuj spójność zmian stanu

Bilety przechodzą przez stany — zdefiniuj je z wyprzedzeniem:

• Przeniesiony: zdecyduj, czy oryginalny QR unieważnia się natychmiast i czy transfery są odwracalne.
• Zwrócony/anulowany: skan zawsze powinien wyświetlać jasny powód „nieważne”.
• Anulowane zamówienie vs. anulowany uczestnik: obsłuż oba przypadki, żeby personel widział właściwy komunikat przy bramie.

Zapisz te reguły prostym językiem dla personelu i odwzoruj je w odpowiedziach skanera w aplikacji.

Zdefiniuj funkcje MVP (uczestnik, personel, admin)

MVP aplikacji biletowej to najkrótszy zestaw funkcji, który pozwala prawdziwym ludziom sprawnie wejść — i daje organizatorom pewność co do zliczeń i kontroli.

Niezbędne dla uczestnika (moment „mój bilet”)

Twoje doświadczenie uczestnika powinno szybko odpowiadać na trzy pytania: Co mam za bilet? Gdzie iść? Co muszę dziś wiedzieć?

Dołącz:

• Portfel biletowy pokazujący każdy bilet (imię, wydarzenie, data/godzina, info o wejściu).
• Szczegóły wydarzenia: adres, harmonogram, zasady wejścia i podstawowa pomoc/kontakt.
• Dodaj do Apple Wallet / Google Wallet, aby uczestnicy mogli dostać się do biletów nawet bez logowania.

Utrzymaj tworzenie konta jako opcjonalne, jeśli to możliwe. Dla wielu wydarzeń „otwórz maila → zobacz bilet” działa lepiej niż „zakładaj hasło”.

Niezbędne dla personelu (szybkość + pewność)

Personel potrzebuje jednego celu: weryfikować bilety szybko i bez wątpliwości.

Priorytety:

• Dedykowany ekran skanowania, który otwiera się natychmiast.
• Przełącznik latarki dla słabo oświetlonych wejść.
• Duże informacje o stanie (wyraźne stany sukcesu/nieważności/już użyte z kolorem i tekstem).
• Ręczne wyszukiwanie po imieniu, mailu lub kodzie zamówienia dla uszkodzonych ekranów i przypadków brzegowych.

Niezbędne dla administratora (kontrola w czasie rzeczywistym)

Narzędzia administracyjne powinny zmniejszyć komunikację radiową i domysły:

• Dashboard w czasie rzeczywistym: odprawy w czasie, wg bramki, wg typu biletu.
• Liczniki pojemności (wewnątrz/na zewnątrz) dla decyzji o bezpieczeństwie i obsadzie.
• Dziennik incydentów dla nadpisów (np. „VIP escort”, „wymiana biletu”, „problem z urządzeniem”).

Miłe dodatki (jeśli MVP jest stabilne)

Gdy wejście działa niezawodnie, rozważ pushy, mapy, harmonogramy i listy wystawców — przydatne, ale nie krytyczne na pierwszy dzień.

Zaprojektuj bilet QR i doświadczenie skanowania

Świetna aplikacja odprawowa daje wrażenie natychmiastowości: skieruj aparat, otrzymaj czytelną odpowiedź, przejdź do następnej osoby. To działa tylko wtedy, gdy projekt QR, UI skanera i logika walidacji są zaplanowane razem.

Co powinien zawierać kod QR?

Masz zwykle dwie opcje:

• Token losowy (zalecane): QR zawiera krótki, losowy ciąg (lub UUID). Aplikacja wysyła go do serwera (lub sprawdza w lokalnej pamięci podręcznej), aby potwierdzić ważność.
• Zakodowane dane biletu: QR zawiera szczegóły jak ID biletu, ID wydarzenia, miejsce lub nawet dane uczestnika.

Wybieraj tokeny, bo są bezpieczniejsze i łatwiejsze do rotacji. Jeśli ktoś zrobi zrzut ekranu i udostępni kod, możesz unieważnić token bez ujawniania danych osobowych. Zakodowane dane przydają się przy pełnym braku sieci, ale zwiększają ryzyko prywatności i komplikują unieważnianie, chyba że dodatkowo weryfikujesz podpis i prowadzisz listy unieważnień.

Spraw, by skanowanie było szybkie i jednoznaczne

Szybkość to głównie zmniejszenie tarcia aparatu i czasu decyzji:

• Optymalizuj szybkie ustawianie ostrości i działanie w słabym świetle (używaj sterowania latarką urządzenia, gdy potrzeba).
• Utrzymuj widok skanowania prosty: duża ramka, brak bałaganu, jasne instrukcje („Trzymaj stabilnie nad kodem QR”).
• Pokaż natychmiastowy, kontrastowy stan: Ważny (zielony) vs. Nieważny (czerwony) oraz krótki powód.

Obsługuj duplikaty łagodnie

Duplikaty się zdarzają — zrzuty ekranu, wiele bramek czy błąd personelu. Praktyczna zasada:

• Pierwszy skan = ważny i oznacza bilet jako użyty.
• Późniejsze skany = „Już użyte” i pokaż czas oraz lokalizację/bramkę pierwszego skanu, żeby personel mógł szybko wyjaśnić sytuację.

Dodaj ręczne obejście na wypadek uszkodzeń ekranu

Nie każdy QR się zeskanuje. Zbuduj szybkie „Znajdź bilet”:

• Wyszukiwanie po imię, email lub ID zamówienia.
• Pokaż minimalną kartę wyniku ze statusem (nieużyty/użyty) i jednoczesnym przyciskiem „Zamelduj”.

To trzyma kolejki w ruchu, gdy uczestnicy mają wydrukowane bilety, pęknięte telefony lub ciemne ekrany.

Wspieraj odprawy offline i niezawodną synchronizację

Tłumy nie czekają na Wi‑Fi. Jeśli aplikacja zależy od idealnego połączenia, stworzysz kolejki, chaos i improwizacje personelu. Tryb offline-first to mniej technicznego bajeru, a więcej jasnych reguł: co skaner może zrobić bez sieci i jak „mówi prawdę” po ponownym połączeniu.

Określ zachowanie offline

Zdefiniuj, co urządzenie pobiera przed otwarciem drzwi: lista uczestników (lub ID biletów), typy biletów, reguły walidacji (okna czasowe, limity wejść) oraz lista zbanowanych/zwróconych biletów.

Gdy sieć zniknie, aplikacja powinna nadal:

• Walidować bilety przy użyciu zcache’owanych reguł
• Rejestrować skany lokalnie z timestampem i ID urządzenia
• Pokazywać wyraźny status „Zameldowano (offline)”

Zdefiniuj reguły synchronizacji i konfliktów

Konflikty występują, gdy ten sam bilet zostanie zeskanowany na dwóch urządzeniach przed synchronizacją. Wybierz politykę i pokaż ją:

• Pierwszy skan wygrywa: najwcześniejszy timestamp jest ważny; późniejsze skany to duplikaty.
• Nadpisanie przez przełożonego: pozwól supervisorom oznaczyć wyjątek (przydatne dla transferów VIP).

Synchronizacja powinna być inkrementalna i niezawodna: automatyczne ponawianie, widoczny czas ostatniej synchronizacji i gwarancja, że lokalna historia skanów nie zaginie.

Zaplanuj konfigurację urządzeń dla personelu

Zmniejsz chaos poranny krótkim flow konfiguracji:

1. Logowanie personelu (lub PIN)
2. Wybór wydarzenia (lub auto-przypisanie)
3. Pobranie listy skanów + reguł (potwierdź „Gotowy do pracy offline”)

Komunikaty „brak sieci” i krótka lista kontrolna

Unikaj niejasnych błędów. Używaj prostych komunikatów: „Brak połączenia — skanowanie będzie kontynuowane offline.” Dodaj jednorazową listę kontrolną dla personelu: włącz/wyłącz tryb samolotowy, sprawdź Wi‑Fi venue, potwierdź czas urządzenia, zweryfikuj wybrane wydarzenie i skontaktuj się z liderem, jeśli duplikaty rosną.