Zaczęłam od praktycznych ustaleń, jeszcze przed wyborem biletu.

Wyjście zaczyna się przed wyborem biletu

Wyniki są podpisane „Wrocław”, ale kilka z nich dotyczy pobliskich miejscowości. Jedno wydarzenie odbywa się o kilku różnych godzinach. Ceny biletu na liście nie ma wcale; pojawia się dopiero krok dalej.

Zanim więc ktokolwiek wybierze miejsce, trzeba podjąć mniejszą decyzję: o którym z tych wieczorów w ogóle warto porozmawiać z osobą, z którą się idzie?

Od tego momentu zaczęłam niezależne studium koncepcyjne. Interesowało mnie, jak interfejs mógłby pomóc przejść od przeglądania wydarzeń do wyboru biletu tak, żeby po drodze nie zgubić ustaleń, dzięki którym plan w ogóle powstał. W działającym prototypie niżej można te ustalenia zmieniać i zobaczyć, co się dzieje, kiedy miejsce przestaje być dostępne.

Wszystko, co tu opisuję, wynika z przeglądu publicznego serwisu i z projektu, który z niego wyrósł. KupBilecik nie zlecił tego studium. Nie miałam dostępu do analityki platformy, danych organizatorów ani badań klientów; persony i krytyka scenariusza są wygenerowane przez AI, a wydarzenia w prototypie są fikcyjne. Nie mam więc wyników wywiadów ani sprzedaży do pokazania.

Co rzeczywiście mogłam zobaczyć

Z publicznych wyników dla Wrocławia przeszłam do jednego wydarzenia i planu sali bez wybranych miejsc. Tam się zatrzymałam: przed wyborem prawdziwych miejsc, utworzeniem rezerwacji i podaniem danych osobowych. Dalsze etapy zakupu zostają poza tym, co widziałam.

Na przejrzanych stronach zwróciłam uwagę na cztery rzeczy:

• Karty wydarzeń pokazywały daty, obiekty i dostępność, ale nie ceny biletów.
• Lista dla Wrocławia obejmowała też okoliczne miejscowości.
• Na telefonie suwak promienia przekazywał do drzewa dostępności wartość 50, choć na ekranie nie pokazywał ani liczby, ani wartości krańcowych.
• Na komputerze wskaźnik postępu rezerwacji nazywał siedem etapów; w mobilnym widoku wyboru miejsc ten sam wskaźnik pokazywał zamiast nazw numery.

Każdą z tych obserwacji potraktowałam jak pytanie. Brak ceny na karcie może utrudniać porównanie, ale może też wynikać z trudności w udostępnianiu danych o dostępnych biletach. Szeroki obszar może zaskoczyć kogoś, kto szuka tylko w mieście, a komuś z samochodem się przydać. Projekt miał pokazać te wybory bez udawania, że już wiem, który z nich jest najważniejszy.

Jak sformułowałam pytanie badawcze

Zakładam, że odbiorcą jest osoba, która od czasu do czasu organizuje wyjście z inną dorosłą osobą i może zacząć od daty albo limitu wydatków, a wydarzenie znaleźć dopiero później.

Przydatnym kontrprzykładem jest stały bywalec, który szuka konkretnego wykonawcy: obowiązkowy formularz planowania tylko dołożyłby mu pracy przed prostym wyszukiwaniem.

Pytanie badawcze oparłam na niedawnym wyjściu: co było już ustalone, zanim wybrano wydarzenie? Wywiad odtworzyłby jedną prawdziwą próbę zaplanowania wieczoru, także taką, z której ktoś zrezygnował, na podstawie własnych linków lub kalendarza uczestnika, jeśli zechce je pokazać. Pytanie, czy filtr budżetu wydaje się przydatny, skłaniałoby do przytakiwania mojemu rozwiązaniu i niewiele mówiłoby o rzeczywistej decyzji.

Sposób prowadzenia badań opieram na zaleceniach GOV.UK dotyczących badań na etapie rozpoznania. Zaprosiłabym osoby spoza grona projektantów i znajomych, uwzględniła różne potrzeby związane z transportem i dostępnością, a to, co ktoś pamięta, oddzielała od tego, co robi podczas sesji. Żadna z tych sesji jeszcze się nie odbyła.

Pierwotny opis projektu wyznacza też warunek, od którego zależy dalsza praca nad formularzem planowania: data lub miejsce muszą wyznaczać plan w co najmniej trzech z sześciu sytuacji odtworzonych przez osoby z głównej grupy uczestników, zanim zostanie wybrane wydarzenie. To decyzja o nakładzie pracy podejmowana na małej, zrekrutowanej próbie, więc nie pozwala oszacować preferencji całej populacji, a scenariusze wygenerowane przez AI nie mogą tego warunku spełnić.

Zastrzeżenie z symulacji zmieniło założenia

Zanim uznałam te kontrolki za pełną odpowiedź, zestawiłam je ze scenariuszem wygenerowanym przez AI: osoba pracująca na zmiany planuje wieczór ze starszym kuzynem, jeździ autobusami i korzysta z małego telefonu z powiększonym tekstem. Nikt prawdziwy w tym nie uczestniczył i niczyjego zachowania nie obserwowałam. Scenariusz miał dostarczyć zastrzeżeń.

Najmocniejsze dotyczyło odległości. Bliski obiekt z niewygodnym późnym powrotem mógłby być gorszym wyborem niż dalszy, do którego jedzie bezpośredni autobus.

Ta sama krytyka zapytała, czy budżet dla dwóch osób obejmuje opłaty i transport i czy „dostępne” oznacza dwa miejsca obok siebie. Warto to sprawdzić, choć symulacja nie powie, w jakiej kolejności ustawiliby te kwestie prawdziwi ludzie.

Trzy struktury i koszt każdej z nich

Rozważyłam trzy struktury, a każda wspiera inny rodzaj pracy:

• czytelniejszy lokalny katalog, który pomaga przeglądać;
• opcjonalny formularz planowania wieczoru, który najpierw pyta o warunki;
• zapisywana lista propozycji, która pozwala porównywać dalej.

Zbudowanie wszystkich trzech schowałoby nierozstrzygnięte pytanie badawcze w większym produkcie.

Niezależnie od tego, która struktura przetrwa, model treści ma znaczenie. Jedno wydarzenie może mieć kilka terminów. Każdy termin należy do obiektu i ma własną pulę biletów, a przedział cenowy nie gwarantuje pary sąsiadujących miejsc. Rozpisanie tych zależności pomogło mi ustalić, co wynik wyszukiwania może obiecać, a co trzeba sprawdzić jeszcze raz przy wyborze miejsc.

Jeśli prawdziwe rozpoznanie potrzeb ujawni różne sposoby grupowania wydarzeń, sortowanie kart mogłoby pomóc dobrać nazwy. Test drzewa sprawdziłby potem ścieżki do innego terminu, informacji o dostępności obiektu albo pomocy w sprawie biletów. Sortowanie kart i testowanie drzewa odpowiadają na różne pytania, a żadna z tych metod nie pokaże, czy plan sali jest czytelny ani czy kwota łączna jest zrozumiała.

Wypróbuj wybór wydarzenia i miejsc

Działający fragment obejmuje niewielki katalog i wybór miejsc. Warto spróbować:

• zmienić odległość i budżet niezależnie od siebie;
• uwzględnić wydarzenia bez pary sąsiadujących miejsc;
• wybrać termin i porównać plan sali z listą.

Interfejs jest po polsku celowo. Propozycja powinna pokazywać język, który ludzie musieliby zrozumieć, podejmując decyzję.

Kwota na karcie to najtańsza dostępna para sąsiadujących miejsc w danych przykładowych plus jedna opłata za zamówienie, więc dwa tanie miejsca, które ze sobą nie sąsiadują, nie mogą być jej podstawą. Po wyborze miejsc podsumowanie podaje oba numery i sumę. Przejście dalej wymaga miejsc obok siebie, mieszczących się w zapisanym budżecie i obszarze wyszukiwania. Jeśli wybór przekracza któryś z tych limitów, interfejs pokazuje komunikat i czeka na świadomą zmianę.

Lista służy do tego samego wyboru

Plan sali i lista mają wspólny stan wyboru. Po zmianie widoku wybrane miejsca i kwota pozostają bez zmian.

• Każda kontrolka podaje sektor, rząd, numer i cenę.
• Lista opisuje dostępność słowami. Na planie niedostępne miejsce ma przekreślony numer.
• Każde miejsce jest standardowym przyciskiem, więc cały wybór da się zrobić bez przeciągania planu.
• Promień można też wpisać w polu liczbowym. Wskazówki W3C dotyczące przeciągania traktują alternatywę dla przeciągania i obsługę klawiaturą jako osobne potrzeby: pole liczbowe zaspokaja pierwszą, a suwak działa też z klawiatury.
• Zmiany wyboru i wyników dostają krótkie potwierdzenie wizualne, a istotne aktualizacje są ogłaszane. Przy ograniczonym ruchu nic się nie przesuwa.

To decyzje podjęte w symulacji o ograniczonym zakresie i nie potwierdzają dostępności całego procesu zakupu. Obsługę czytnikiem ekranu, powiększony tekst i etykiety trzeba jeszcze sprawdzić z osobami, które z nich korzystają.

Co uzasadniałoby dalsze prace

Dalsza praca wymagałaby trzech etapów.

1. Zanim ktokolwiek zobaczy tę propozycję, poprosiłabym ludzi o odtworzenie niedawnego wyjścia. Szukałabym warunków ustalonych z góry, odrzuconych wydarzeń i momentu, w którym do planowania dołączyła druga osoba. Krytyka wygenerowana przez AI daje mi pytania do tej rozmowy, ale nie wyznaczy zakresu badania ani nie udzieli odpowiedzi.
2. Późniejsza sesja z prototypem polegałaby na znalezieniu wieczoru dla dwóch osób, wyjaśnieniu obszaru i sumy, a potem na poradzeniu sobie z utratą miejsca. Zapisywałabym wybrany termin i miejsca, nieporozumienia, udzieloną pomoc i powód zmiany decyzji. Czas mierzony podczas głośnego myślenia służyłby diagnozie. Moderowane sesje z niewielką grupą wskazałyby konkretne poprawki, ale nie określiłyby wpływu na sprzedaż.
3. Wdrożenie wymagałoby informacji o obiektach potwierdzonych przez organizatorów, zasad udostępniania dostępności i cen oraz prawdziwych reguł blokowania miejsc i wygasania blokady. Transport wymaga osobnego rozwiązania.

Celowo pominęłam te obietnice w działającym fragmencie, bo wiarygodnie wyglądającą odpowiedź trudniej zakwestionować niż wyraźnie nazwaną niewiadomą.

Prototyp kończy się dwoma numerami miejsc i kwotą, która wciąż może się zmienić. Wystarczy nacisnąć przycisk symulujący utratę miejsca, a jeden numer znika, podczas gdy pierwotny budżet zostaje obok. Właśnie ten moment chciałabym teraz sprawdzić z prawdziwym uczestnikiem: czy zachowany plan i zmieniony wybór są na tyle jasne, żeby iść dalej.