PICK’EM nie potrzebował bardziej skomplikowanego typowania. Potrzebował ciągłości — systemu, w którym wybór prowadzi do wyniku, wynik do statystyki, statystyka do rywalizacji, a rywalizacja do historii.
Mechanika Pick’em jest niemal brutalnie prosta. Użytkownik wybiera zwycięzcę meczu. Za poprawny typ dostaje jeden punkt. Potem czeka na wynik i sprawdza tabelę. To wystarcza, żeby prowadzić rozgrywkę, ale nie wystarcza, żeby zbudować doświadczenie, do którego chce się wracać także pomiędzy kolejkami.
Największy problem nie pojawia się więc w momencie wyboru. Pojawia się chwilę później. Kliknięcie trwa kilka sekund, natomiast sezon trwa miesiące. Jeżeli produkt pokazuje wyłącznie listę meczów, zaznaczone picki i aktualny ranking, ogromna część emocji żyje poza produktem: w rozmowach między graczami, pamięci o spektakularnej porażce, serii dobrych typów, zmianie lidera i oczekiwaniu na następną kolejkę.
Klasyczny interfejs potrafi zapisać wynik. Gorzej radzi sobie z odpowiedzią na pytanie, dlaczego ten wynik był ważny.
W typowej grze sezonowej występuje naturalny rytm: typowanie, oczekiwanie, wynik, tabela. Pomiędzy tymi punktami powstaje jednak dużo „martwego czasu”, w którym produkt nie ma nic nowego do powiedzenia.
To właśnie tam istnieje największy niewykorzystany potencjał. Gracz może już nie mieć żadnej decyzji do podjęcia, ale nadal chce wiedzieć, czy traci pozycję, kto go dogania, kto wygrał tydzień, jaki wynik zmienił tabelę i co ta zmiana oznacza przed następną kolejką.
Projekt nie miał więc zwiększać liczby kliknięć. Miał zwiększyć znaczenie tego, co już się wydarzyło.
Tabela końcowa jest niezbędna, ale redukuje sezon do stanu bieżącego. Pokazuje „teraz”, nie pokazuje drogi.
Jeżeli dwóch graczy ma po 17 punktów, tabela nie mówi, że jeden z nich przez trzy tygodnie prowadził, potem spadł po fatalnej kolejce, a drugi odrabiał po jednym punkcie i właśnie go dogonił. Te dane mogą być identyczne na końcu tygodnia, ale historie są zupełnie inne.
Dlatego główne pytanie projektowe zostało przesunięte z funkcji na dramaturgię:
Jak sprawić, żeby każdy tydzień ligi miał początek, napięcie, wynik i konsekwencję — jak kolejny odcinek sezonu?
| Obszar | Zakres |
|---|---|
| Doświadczenie | 12 ekranów |
| Punktacja | 1 punkt za poprawny typ |
| Dane | integracja z TheSportsDB + lokalny Schedule |
| Warstwa gry | picks, scoring, standings, historia tygodni |
| Statystyki | league standings, week-by-week battle, season moments |
| Narracja | 1 230 elementów tekstowych |
| Interakcje | Press Conference, Trash Talk, komentarze |
| Typografia | IBM Plex Sans + IBM Plex Mono |
Najważniejsza decyzja nie dotyczyła koloru ani pojedynczego ekranu. Dotyczyła tego, czym produkt ma być w głowie użytkownika.
Zamiast projektować kolejny sports dashboard, potraktowaliśmy ligę jak własną stację transmisyjną. Nie taką, która tylko pokazuje wynik meczu, lecz taką, która ma program, segmenty, rytm i pamięć wydarzeń.
To przesunięcie rozwiązało kilka problemów jednocześnie. Dało produktowi język, którym może prowadzić użytkownika przez tydzień. Pozwoliło połączyć dane z emocją. Uzasadniło obecność komentarza, artykułów, konferencji i sezonowych podsumowań. Co najważniejsze, stworzyło strukturę, w której statystyka nie musi udawać rozrywki — może pozostać statystyką, ale zostaje osadzona w szerszej opowieści.
TODAY ON THE NETWORK działa jak plansza otwierająca transmisję. To moment wejścia do świata ligi.
MAKE YOUR PICKS jest główną akcją użytkownika: wybór musi pozostać prosty, szybki i czytelny. Nie chcieliśmy komplikować rdzenia gry tylko dlatego, że reszta produktu jest bogata.
THE BROADCAST otwiera warstwę komentarza i życia ligi. Tutaj wyniki zaczynają mieć głos.
LEAGUE STANDINGS pokazuje aktualny układ sił.
WEEK-BY-WEEK BATTLE pokazuje zmianę w czasie i pozwala zobaczyć, jak ranking powstał.
SEASON MOMENTS traktuje dane jak materiał archiwalny i analityczny — jako rozdział sezonu, nie kolejną tabelę.
Całość liczy 12 ekranów. Część z nich jest segmentami narracyjnymi, część obsługuje mechanikę gry i stan ligi. Wspólnym mianownikiem pozostaje zasada, że użytkownik nie powinien czuć przechodzenia przez przypadkowy zestaw podstron. Powinien czuć przechodzenie przez program.
Wczesny, naturalny kierunek polegał na silniejszym użyciu kolorów drużyn. Szybko okazało się jednak, że im więcej klubowych kolorów przejmuje layout, tym mniej własnej tożsamości zostaje produktowi.
Kolory zespołów zostały więc zdegradowane do roli detalu, sygnału i lokalnego akcentu. System wizualny dostał własną paletę: bardzo ciemny granat jako przestrzeń transmisji, czerwone światło jako napięcie, neutralne typograficzne pola oraz chłodniejsze niebieskie akcenty pojawiające się tylko wtedy, gdy komunikują dane, status albo techniczną warstwę systemu.
Ta decyzja była ważniejsza niż sama estetyka. Dzięki niej użytkownik ogląda sezon przez jeden spójny interfejs, a drużyny pojawiają się jako treść ligi, nie jako konkurujące ze sobą mini-brandingi.
Projekt konsekwentnie odsuwał się od trzech łatwych kierunków.
Pierwszym był klasyczny fantasy dashboard: wiele małych kart, badge’y, wykresów i kolorów walczących o uwagę. Był funkcjonalny, ale nie dawał żadnej własnej dramaturgii.
Drugim był agresywny fan-service: dużo logotypów, pełne barwy drużyn, efekty stadionowe i dekoracja bez hierarchii. Taki język szybko zamieniał produkt w wizualny hałas.
Trzecim był „telewizyjny kostium”: udawanie konkretnej stacji poprzez kopiowanie istniejących opraw. Broadcast miał być logiką doświadczenia, nie cosplayem.
API nie jest tutaj niewidocznym dodatkiem dla developera. Jest punktem, w którym prawdziwy sezon wchodzi do produktu.
Dane meczowe zmieniają stan kolejki. Stan kolejki wpływa na scoring. Scoring zmienia standings i statystyki. Zmiana statystyk tworzy nowy kontekst dla narrative engine. Jedna aktualizacja potrafi więc przejść przez kilka warstw produktu.
API → STATE → SCORING → STATISTICS → NARRATIVE
To dlatego integracja z danymi musi być projektowana równie świadomie jak interfejs. Nadmierne odpytywanie źródła jest niepotrzebne. Zbyt wczesne sprawdzanie meczu nie daje użytecznej informacji. Równoległe synchronizacje mogą wykonywać tę samą pracę kilka razy. Brak lokalnego stanu powoduje, że zewnętrzne API zaczyna decydować o wszystkim.
Pierwszą zasadą jest sprawdzanie lokalnego Schedule przed wykonaniem requestu do TheSportsDB.
System wie, jakie mecze istnieją, kiedy mają kickoff i które wyniki zostały już zapisane jako finalne. Zewnętrzne API jest używane dopiero wtedy, gdy lokalny stan mówi, że naprawdę istnieje coś do sprawdzenia.
To zmienia integrację z modelu „pytaj API i zobacz, co odpowie” na model „wiem, czego potrzebuję, więc pytam tylko wtedy, kiedy ma to sens”.
Nie każdy rozpoczęty mecz kwalifikuje się do sprawdzenia.
W docelowym mechanizmie synchronizacji system bierze pod uwagę tylko spotkania, dla których minęło co najmniej kickoff + 2h45. Ten bufor ogranicza sytuacje, w których API jest pytane o wynik, zanim mecz ma realną szansę być zakończony.
Jeżeli lokalny Schedule nie zawiera żadnego meczu spełniającego ten warunek, synchronizacja kończy się bez requestu do zewnętrznego źródła.
Jeżeli wszystkie rozegrane mecze mają już wynik finalny, a następne spotkanie jest dopiero później, system również nie wykonuje pustej pracy.
Synchronizacja może zostać uruchomiona przez obecność dowolnego aktywnego użytkownika na stronie — również zalogowanego administratora. Nie wymaga osobnego ręcznego procesu tylko po stronie admina.
Pierwszy aktywny użytkownik może uruchomić sprawdzanie. Kolejni nie mogą jednak wystartować drugiego identycznego procesu równolegle.
Służy do tego lock syncInProgress.
Jeżeli synchronizacja już trwa, następne wejście nie generuje kolejnego zestawu requestów. Po zakończeniu zapisuje się również lastSyncAt.
Druga bariera to cooldown: jeżeli od ostatniego sprawdzenia minęło mniej niż 15 minut, system nie pyta API ponownie.
Te dwie zasady rozwiązują dwa różne problemy. syncInProgress chroni przed równoległością. lastSyncAt chroni przed zbyt częstym powtarzaniem tej samej pracy.
Kolejność działania jest celowo konserwatywna:
syncInProgress;lastSyncAt i 15-minutowy cooldown;Schedule;kickoff + 2h45 bez potwierdzonego wyniku końcowego;W tej architekturze zewnętrzne API nie jest zegarem całego produktu. Jest źródłem danych używanym wtedy, gdy produkt wie, że dane mogą coś realnie zmienić.
Użytkownik nie widzi locka ani cooldownu. Widzi natomiast konsekwencję ich działania: produkt nie „mieli” bez powodu, standings nie są aktualizowane chaotycznie, a wiele aktywnych osób nie powoduje lawiny identycznych requestów.
Dobra integracja API jest niewidoczna w interfejsie, ale widoczna w zachowaniu systemu.
Rdzeń gry pozostaje prosty: jeden punkt za poprawny typ. Ta prostota jest strategiczna. Produkt nie potrzebuje skomplikowanego systemu wag, bonusów i wyjątków, żeby generować napięcie. Złożoność powstaje z konsekwencji wyniku, nie z samego formularza typowania.
Ekran typowania ma jedno zadanie: pozwolić użytkownikowi szybko podjąć decyzje przed kolejką.
Dlatego visual pass nie mógł zamienić tej części w plakat. Efektowna kompozycja musiała nadal respektować logikę picków, stany wyboru i czytelność zestawień. Duży headline MAKE YOUR PICKS., oznaczenie WEEK 01 i krótka zasada ONE POINT PER CORRECT PICK. budują kontekst bez konkurowania z właściwą akcją.
To ważna zasada całego projektu: spektakularny charakter pojawia się wokół mechaniki, nie zamiast mechaniki.
Po zamknięciu meczu wynik uruchamia kolejną warstwę systemu. Pick użytkownika może zostać oznaczony jako poprawny albo błędny. Punkty zmieniają jego pozycję. Pozycja wpływa na standings. Historia kolejnych standings buduje week-by-week battle. Zmiany mogą zostać wykorzystane w Season Moments i narrative engine.
W praktyce jedna informacja — finalny wynik meczu — może zmienić kilka ekranów jednocześnie.
To jest podstawowa różnica między zwykłym scoreboardem a doświadczeniem sezonowym. Scoreboard przechowuje wynik. PICK’EM przechowuje jego konsekwencje.
Standings odpowiada na najprostsze i najważniejsze pytanie: kto prowadzi?
Tabela musi być czytelna natychmiast. Visual language może dodawać napięcie, ale nie może ukrywać porządku. Pozycja, gracz i wynik sezonowy tworzą podstawowy obraz ligi.
W projekcie ważne było również to, żeby tabela nie była odseparowanym „widgetem”. Może wchodzić w relację z ilustracją, kaskiem czy światłem, ale jej dane pozostają nadrzędne wobec dekoracji.
Aktualne standings pokazuje rezultat. Week-by-week pokazuje proces.
Ten ekran pozwala zobaczyć, jak zmieniała się rywalizacja pomiędzy kolejnymi tygodniami. Dzięki temu można odczytać serie, odrabianie strat, spadki i momenty, w których zmieniała się hierarchia ligi.
To właśnie tutaj statystyka zaczyna pełnić funkcję pamięci. Użytkownik przestaje patrzeć wyłącznie na liczbę punktów. Widzi trajektorię sezonu.
Season Moments jest jeszcze jednym krokiem dalej. Nie chodzi o kolejną tabelę, lecz o wybranie z danych takich zdarzeń, które nadają sezonowi strukturę.
W języku projektu ten obszar został potraktowany jako DATA / ANALYSIS CHAPTER. To ważne: produkt nie udaje, że każda liczba jest emocją. Najpierw pokazuje dane. Dopiero potem pozwala warstwie narracyjnej nadać im znaczenie.
Jednym z ryzyk było stworzenie typowego panelu sportowego, w którym każda metryka dostaje osobną kartę, ikonę i kolor. Taki system szybko robi się informacyjnie ciężki, a jednocześnie wizualnie banalny.
Dlatego statystyki zostały osadzone w dramaturgii strony: duża liczba może funkcjonować jak headline, historia tygodni jak linia narracyjna, tabela jak główny obraz, a drobne metadane jak warstwa broadcastowa.
Nie każda informacja potrzebuje własnego komponentu. Potrzebuje właściwej hierarchii.
Projekt rozdziela dwie rzeczy, które w wielu produktach sportowych są wrzucane do jednego widoku: stan bieżący i historię zmiany.
Standings powinno być bezwzględnie szybkie. Użytkownik ma w kilka sekund zobaczyć pozycję, wynik i różnicę wobec rywali. To ekran operacyjny.
Week-by-week battle ma inne zadanie. Nie służy do sprawdzania „kto jest pierwszy teraz”, tylko do odtworzenia przebiegu rywalizacji. Dlatego może pozwolić sobie na większą warstwę analityczną: kolejne tygodnie, zmianę trajektorii i momenty, w których układ sił przestał być oczywisty.
To rozdzielenie jest ważne także dla narracji. Narrative engine nie musi próbować wyczytać historii z jednej końcowej liczby. Może korzystać z różnicy pomiędzy stanem obecnym a wcześniejszym przebiegiem sezonu.
Dobrze zaprojektowana statystyka nie kończy rozmowy. Otwiera ją.
Jeżeli gracz awansował o kilka pozycji, naturalne pytanie brzmi: co spowodowało ten ruch? Jeżeli lider utrzymuje przewagę przez wiele tygodni, ważniejsze od samego wyniku staje się pytanie, jak długo trwa seria. Jeżeli dwóch graczy porusza się niemal równolegle, dane sugerują bezpośrednią rywalizację nawet wtedy, gdy produkt nie musi nazywać jej ręcznie.
W ten sposób liczby stają się generatorem kontekstu dla Commentatora, artykułów i Press Conference.
Nie chcieliśmy dodawać wskaźników tylko dlatego, że „sportowe aplikacje mają dużo statystyk”. Każda liczba powinna odpowiadać na konkretne pytanie użytkownika albo dostarczać materiał kolejnej warstwie systemu.
Jeżeli metryka nie zmienia decyzji, nie pomaga zrozumieć rankingu i nie daje wartości narracyjnej, nie zasługuje na osobny moduł.
To ograniczenie chroni produkt przed dashboard fatigue i pozwala zachować moc większych, naprawdę istotnych danych.
Warstwa narracyjna zawiera 1 230 elementów tekstowych powiązanych z wynikami, tabelą, historią tygodni i zachowaniem graczy.
Najważniejsze nie jest jednak samo „1 230”. To nie jest magazyn losowych żartów, z którego aplikacja wyciąga jedno zdanie po zakończeniu kolejki. Biblioteka została zbudowana jak system redakcyjny: najpierw powstają fakty, potem system rozpoznaje rodzaj wydarzenia, następnie jego konkretny stan, a dopiero na końcu wybiera pasujący wariant językowy.
Dlatego jedna kategoria może zawierać kilka zupełnie różnych sytuacji. „Lider” nie oznacza jednego komentarza o liderze. „Pick behavior” nie oznacza jednego tekstu o odważnym wyborze. Ten sam obszar rozpada się na mniejsze stany, które niosą inne znaczenie dla ligi.
Narrative engine nie zaczyna od pisania. Zaczyna od tego, co naprawdę wydarzyło się w grze.
System zna wyniki meczów, poprawność picków, punktację tygodnia, standings, zmianę pozycji względem poprzedniego tygodnia, serie, rekordy, Joker, rozkład wyborów i historię wcześniejszych kolejek.
Na tej podstawie wykrywa zdarzenia. Dopiero zdarzenie może dostać narrację.
To fundamentalna zasada: tekst może przesadzić znaczenie faktu, ale nie może wymyślić faktu.
Najprostszy sposób zrozumienia systemu to spojrzeć na jedną kategorię.
LEADER STATES nie jest jedną szufladą pod tytułem „lider”. W środku znajduje się pięć różnych stanów:
LEADER_STAYS — lider utrzymuje pierwsze miejsce;LEADER_EXTENDS_GAP — prowadzenie rośnie;LEADER_LOSES_GROUND — nadal jest pierwszy, ale przewaga topnieje;LEADER_RETURNS — gracz wraca na szczyt;LEADER_FALLS — dotychczasowy lider traci prowadzenie.To pięć odmian pozornie tej samej informacji. W tabeli każda z nich dotyczy pozycji numer jeden. W narracji oznaczają jednak pięć zupełnie innych historii: stabilność, dominację, presję, powrót albo upadek.
Podobnie działa biblioteka opisująca zachowanie przy typowaniu.
LONE_WOLF_WIN — jeden gracz idzie pod prąd i jako jedyny trafia;LONE_WOLF_FAIL — samotny wybór kończy się porażką;CONTRARIAN_PICK — gracz świadomie znajduje się po przeciwnej stronie niż większość ligi;CONSENSUS_WIN — grupa miała rację;CONSENSUS_FAIL — prawie wszyscy wybierają ten sam kierunek i prawie wszyscy płacą za niego punktami.Interfejs nadal pokazuje zwykły pick. Narrative engine widzi jego relację z decyzjami pozostałych graczy. Dzięki temu ten sam klik może zostać później odczytany jako rozsądny konsensus, samotna odwaga albo spektakularne samobójstwo taktyczne.
Nie wszystkie historie należą do jednego gracza. Czasem bohaterem jest cała tabela.
Biblioteka TABLE SITUATIONS rozróżnia między innymi:
CLOSE_TITLE_RACE — walka o tytuł robi się ciasna;RUNAWAY_LEADER — lider zaczyna odjeżdżać reszcie;LAST_PLACE_CHANGE — zmienia się ostatnie miejsce;LAST_PLACE_STAYS — dół tabeli zastyga;PACK_COMPRESSES — stawka się ściska;PACK_STRETCHES — różnice między graczami rosną.Dzięki temu komentator nie musi zawsze szukać „bohatera tygodnia”. Czasem najważniejszą historią jest po prostu układ sił.
System patrzy też na ciągłość. Pojedynczy słaby tydzień nie jest jeszcze kryzysem. Dwa lub trzy kolejne mogą już nim być.
STREAKS rozróżnia dobrą serię, złą serię i moment jej przerwania. COLLAPSE jest mocniejszym stanem: wymaga realnego upadku albo dłuższego kryzysu. RECOVERY nie jest automatycznie wielkim comebackiem — może oznaczać dopiero pierwsze oznaki odbudowy. COMEBACK pojawia się wtedy, kiedy dane naprawdę pokazują powrót do walki.
To ważne, bo bez takiego rozróżnienia liga bardzo szybko zaczęłaby nazywać każdy lepszy tydzień „historycznym powrotem”, a każde potknięcie „katastrofą”. System potrzebuje skali.
Rekordy mają osobną bibliotekę, ale sam rekord nie dostaje automatycznie pierwszego miejsca w Broadcast.
System rozpoznaje m.in. RECORD_BROKEN, RECORD_TIED, BEST_WEEK_SEASON, WORST_WEEK_SEASON oraz jednorazowy FIRST_PERFECT_WEEK.
Jeżeli ktoś poprawia własny rekord minimalnie kolejny tydzień z rzędu, wynik powinien zostać zapisany w danych, ale nie musi znowu przejmować komentarza. Narracja nie ma czytać arkusza. Ma wybierać to, co naprawdę zmienia temperaturę ligi.
Po warstwie faktów zaczyna się fikcyjny komentarz. PLAYER MINDSET jest satyrycznym mini-reportażem o tym, jak zawodnik „radzi sobie” z tym, co właśnie wydarzyło się w lidze.
Biblioteka rozróżnia między innymi stany:
CONFIDENT / DELUSIONAL / UNDER PRESSURE / RATTLED / BROKEN / PLOTTING / LUCKY / CURSED / CHAOTIC / MEDIA DARLING / PUBLIC ENEMY / FORGOTTEN
To nie są informacje o prawdziwym życiu ani rzeczywistym stanie psychicznym uczestnika. To czysta konwencja sportowego show. Gracz, który przegrał trzy tygodnie z rzędu, może zostać przedstawiony jako ktoś „pod presją”. Ten, który długo milczy i zaczyna odrabiać straty, może dostać stan PLOTTING. Lider może zostać chwilowo „media darling”, a człowiek seryjnie idący przeciwko reszcie — „public enemy”.
W efekcie tabela przestaje składać się wyłącznie z nazw i punktów. Zaczyna produkować postacie.
HOLLYWOOD bierze realne wydarzenie z prywatnej ligi i udaje, że właśnie zainteresował się nim cały przemysł filmowy.
W tej bibliotece znajdują się różne stany i formaty: CASTING, BIOPIC, PRESTIGE TV, DOCUMENTARY, TRUE CRIME, OSCAR BAIT, DIRECTOR, AUTEUR, AGENT, STUDIO WAR, TRAILER, METHOD ACTING, FRANCHISE, AWARDS czy INDIE.
To jedna z najbardziej charakterystycznych warstw systemu, bo wykorzystuje świadomą dysproporcję skali. Im bardziej zwyczajny jest realny fakt — ktoś awansował o jedno miejsce, wygrał tydzień albo przegrał Jokera — tym zabawniej działa język globalnego show-biznesu opisujący go jak wydarzenie kulturowe.
WORLD REACTIONS eskaluje jeszcze dalej. Liga zaczyna fikcyjnie wpływać na rzeczywistość poza sportem.
Warstwa może reagować przez kulturę, gospodarkę, miasta, sztukę, muzykę, turystykę, reklamę, modę, food culture, teorie spiskowe, fandom albo kompletnie apokaliptyczną przesadę.
Znów: fakt pozostaje prawdziwy. Fałszywe są tylko konsekwencje. Ktoś naprawdę objął prowadzenie. To, że lokalna gospodarka rzekomo zareagowała na jego dominację, jest już częścią fikcyjnego świata Broadcast.
Inne biblioteki zmieniają punkt widzenia, nie sam fakt.
CROWD REACTIONS opisuje reakcję fikcyjnej publiczności tu i teraz: cheers, boos, ciszę, śmiech, skandowanie, nagłą zmianę sympatii albo podzielone trybuny.
BOOKMAKERS udają reakcję rynku: przesuwające się kursy, nerwowość po Jokerze, zmianę oceny lidera, comeback, collapse albo nagłą popularność lone wolfa.
PRIZE POOL buduje absurdalną fantazję przyszłego bogactwa: jacht, Monako, wcześniejszą emeryturę, rozmowy z księgowym, inwestycje, podatki i rodzinę planującą podział pieniędzy, których nikt jeszcze nie wygrał.
Każda z tych bibliotek patrzy na ten sam sezon innymi oczami. Dzięki temu produkt może wracać do tej samej sytuacji bez powtarzania tej samej perspektywy.
Po wykryciu wydarzeń system musi zdecydować, które z nich rzeczywiście zasługują na komentarz.
Nie chodzi o raportowanie wszystkiego. Jeżeli w jednym tygodniu wydarzyło się siedem interesujących rzeczy, Broadcast nadal potrzebuje hierarchii.
Najmocniejsze wydarzenie staje się Main Story. Obok niego mogą pojawić się maksymalnie dwie historie drugorzędne. Potem dochodzi jedna reakcja świata albo tłumu i ewentualne foreshadowing — mały sygnał tego, co może eksplodować za tydzień.
Dzięki temu Commentator zachowuje się bardziej jak redaktor sportowy niż generator podsumowania.
Osobna biblioteka BRIDGES nie opisuje żadnego wydarzenia. Jej zadaniem jest łączenie beatów.
To drobna, ale ważna warstwa. Bez niej komentarz mógłby brzmieć jak pięć osobnych kart ustawionych jedna pod drugą: zwycięzca, lider, Joker, Hollywood, koniec.
Bridge pozwala przejść od jednego tematu do drugiego i złożyć z kilku bibliotek jeden płynny monolog. Użytkownik nie powinien widzieć mechanizmu. Powinien słyszeć jednego prowadzącego.
System pamięta wcześniejsze historie. Jeżeli kilka tygodni temu Commentator zasugerował, że ktoś „coś planuje”, a później ten gracz naprawdę wygrywa tydzień, poprzedni motyw może wrócić jako callback.
Ta sama zasada pozwala prowadzić running jokes: klątwę Jokera, wieczny kryzys konkretnego gracza, obsesję na punkcie jachtu z Prize Pool albo Hollywood próbujące kolejny raz kupić prawa do jego sezonu.
Żart nie powinien jednak wracać co tydzień. Biblioteki mają cooldowny, żeby świat ligi pamiętał swoje motywy, ale nie zamieniał ich w refren.
Engine nie wymyśla fałszywego dramatu.
Jeżeli standings prawie się nie zmieniło, system może wybrać mniejszy event, zbudować mocniejszą reakcję świata, wykorzystać Player Mindset albo zakończyć odcinek foreshadowingiem.
Nudny tydzień nadal może dostać charakter. Nie może dostać nieprawdziwego wyniku.
Wtedy działa odwrotna zasada: nie próbujemy zmieścić wszystkiego.
Najważniejsze fakty idą na antenę. Pozostałe mogą zostać zapisane do pamięci, wrócić w Week History, zostać wykorzystane jako callback albo po prostu pozostać w statystykach.
To ważny element systemu: narracja wybiera, dane pamiętają wszystko.
Kiedy tydzień zostaje zamknięty, komentarz powstaje raz i staje się częścią historii ligi.
Odświeżenie strony nie powinno za każdym razem losować innego „oficjalnego” podsumowania tego samego tygodnia. Dzięki zapisaniu gotowej wersji każdy gracz widzi tę samą historię, callbacki zachowują sens, a Screen 09 może później odtworzyć dokładnie ten Broadcast, który naprawdę zamknął daną kolejkę.
System może być absurdalny, złośliwy, filmowy i przesadnie pompatyczny. Ale jego fundament jest bardzo prosty:
DATA = prawda. RULES = dramaturgia. COPY = głos.
1 230 elementów ma wartość nie dlatego, że jest ich dużo. Mają wartość dlatego, że znajdują się w strukturze, która wie kiedy, dlaczego i z jakiej perspektywy należy ich użyć.
A PICK CREATES A RESULT. DATA CREATES CONTEXT. NARRATIVE TURNS IT INTO A SEASON.
Główne doświadczenie ligi zostało zbudowane jako jeden długi program złożony z 12 ekranów. Każdy ma własną funkcję, ale wszystkie należą do tej samej transmisji.
Nie chodzi o dwanaście dekoracyjnych scen. Architektura prowadzi użytkownika od wejścia na antenę, przez typowanie i wynik, do analizy, pamięci sezonu, komentarza, konferencji i finałowego wyciszenia.
Pierwszy ekran po wejściu do ligi ma wyglądać jak początek dużej transmisji sportowej, nie dashboard.
Pokazuje aktualny Week, datę, mocno widoczny countdown do najbliższego kickoffu i wszystkie mecze rozgrywane danego dnia jako jeden zwarty broadcast roster. Każdy matchup pokazuje drużyny, logotypy i godzinę rozpoczęcia.
Kluczowa zasada: jeden mecz nie oznacza jednego ekranu. Nawet jeżeli danego dnia rozgrywane jest kilka spotkań, użytkownik widzi je razem jako program dnia.
To ekran ustawiający ton całego produktu: prywatna liga ma przez chwilę zachowywać się jak największe sportowe wydarzenie na świecie.
To główny ekran interaktywny i najważniejszy kontrakt UX w całej aplikacji.
Użytkownik uczy się jednej Week Table. Układ nie jest podmieniany zależnie od fazy kolejki — zmieniają się wyłącznie dane i stany.
Przed kickoffem w kolumnie YOUR PICK wybiera jedną z dwóch drużyn. Picki przeciwników pozostają ukryte jako HIDDEN UNTIL KICKOFF. Joker może być przypisany wyłącznie do już wykonanego własnego typu.
Każdy mecz działa niezależnie. Dokładnie przy kickoffie danego spotkania picki dla niego mogą zostać ujawnione, podczas gdy późniejsze mecze pozostają zamknięte. Po statusie FINAL własny wybór przechodzi w stan CORRECT albo WRONG, a nagłówki graczy aktualizują wynik tygodnia.
Ścieżka jest stała:
OPEN → PICKED → LOCKED → PICKS REVEALED → FINAL / CORRECT OR WRONG
Najważniejsza zasada: użytkownik uczy się jednej tabeli; zmienia się stan, nie interfejs.
To pełnoekranowy tygodniowy komentarz ligi.
Na ekranie pojawia się mały znak GLOBAL PICK’EM NETWORK, status kolejki, ogromny headline wybrany z Main Story oraz jeden płynny monolog Commentatora.
Pod spodem może pracować znacznie więcej: wyniki tygodnia, ruch w standings, Joker, forma, media, crowd, Hollywood, bookmakers, Prize Pool i world reactions. Użytkownik nie widzi jednak nazw bibliotek ani struktury engine’u. Widzi gotowy program.
To ekran, na którym narrative engine przestaje być zapleczem i staje się głosem ligi.
Standings nie zostało potraktowane jak klasyczna tabela.
Każdy gracz ma pozycję, identity marker, nazwę, zmianę względem poprzedniego tygodnia, poziomy progress bar, sumę punktów i dystans do lidera. Na końcu toru może pojawić się marker ulubionej drużyny.
Najważniejsze jest natychmiastowe odczytanie trzech informacji: kto prowadzi, kto awansował lub spadł i jak duże są różnice.
Lider dostaje jasny status LEADER. Pozostali mogą być opisani relacją do niego, np. 3 PTS BEHIND. Dzięki temu ranking działa bardziej jak race board niż arkusz wyników.
Ten ekran pokazuje punkty zdobywane przez każdego gracza w każdym tygodniu osobno.
Osiemnaście kolejnych kolumn tworzy wizualny rytm sezonu. W każdej kolejce widać bary graczy, ich wynik tygodnia i zwycięzcę danej rundy.
To ekran do czytania formy: mocnych i słabych tygodni, krótkich serii i momentów, w których ktoś wygrał konkretną kolejkę, nawet jeśli nie prowadzi całego sezonu.
Podsumowanie może pokazywać tylko najmocniejsze statystyki, np. BEST WEEK, WORST WEEK, JOKER HITS czy WEEKLY WINS. Nie chodzi o stworzenie ściany metryk, tylko o pokazanie rytmu rywalizacji.
Jeżeli poprzedni ekran pokazuje tydzień po tygodniu, ten pokazuje, jak te tygodnie zbudowały cały sezon.
Głównym elementem jest wykres CUMULATIVE POINTS OVER SEASON. Oś X prowadzi od Week 01 do Week 18, oś Y pokazuje skumulowane punkty, a jedna linia odpowiada jednemu graczowi.
Na wykresie zaznaczane są wyłącznie wydarzenia wynikające z realnych danych: NEW LEADER, PERFECT WEEK, JOKER FAIL, COLLAPSE, COMEBACK, BIGGEST JUMP czy TITLE RACE.
To najczystsze połączenie statystyki z narracją. Screen 05 mówi: co wydarzyło się w kolejnych tygodniach. Screen 06 mówi: jak te tygodnie zmieniły przebieg sezonu.
Siódmy ekran świadomie wychodzi poza własną tabelę ligi i działa jak pełnoekranowy mini-artykuł.
Każdy materiał ma story-specific headline, bohatera, rolę lub zespół, pełny tekst około 60–100 słów oraz widoczne, klikalne źródło. To nie jest mała karta trivia.
Tematy idą w stronę rzeczy, które brzmią jak fragment dokumentu albo true crime: przestępstwa, narkotyki, imprezy, utracone fortuny, bankructwa, skandale i najbardziej absurdalne historie NFL.
Równie ważny jest system obrazu. Czasem działa portret. Innym razem stadion, tunel, sąd, policyjny samochód, Vegas, lotnisko, łódź, pieniądze, dokument bankructwa, pusty locker room czy inny kontekst wydarzenia.
Ten ekran poszerza świat produktu: PICK’EM nie tylko komentuje własną ligę, ale ma też własną warstwę editorialową wokół futbolu.
Week Browser pozwala przeglądać cały sezon bez budowania drugiego systemu picków.
Używa dokładnie tej samej Week Table co Screen 02. Zmienia się tylko wybrany tydzień i stan tabeli.
CURRENT może być interaktywny. PAST jest kompletny, pokazuje finalne wyniki, odkryte picki, Jokery i końcowy wynik tygodnia. FUTURE pokazuje zaplanowane matchup’y i godziny kickoffów, ale nie pozwala jeszcze typować, jeżeli dana kolejka nie jest aktywna.
Nawigacja typu ← WEEK 04 / WEEK 05 / WEEK 06 → pozwala oglądać sezon jak archiwum i przyszły terminarz jednocześnie.
Jedna tabela. Trzy stany. Zero duplikowania interfejsu.
Screen 09 jest narracyjnym odpowiednikiem Week Browsera.
Jeżeli Screen 08 odpowiada na pytanie „co się wydarzyło?”, History / Broadcast odpowiada „jak PICK’EM opowiedział ten tydzień?”.
Dla zakończonej kolejki użytkownik dostaje oryginalny zapisany headline i monolog Commentatora. Historyczny komentarz nie jest generowany ponownie — archiwum odtwarza dokładnie tę wersję, która zamknęła tydzień.
Jeżeli w Week Browser wybrany zostanie przyszły tydzień, Screen 09 nie fabrykuje historii. Pokazuje stan niedostępności, np. BROADCAST AVAILABLE AFTER WEEK 12 IS FINAL.
Press Conference jest jednym modułem, ale posiada trzy wyraźne momenty: status zamkniętego pokoju, Attack Shop i właściwy Live Press Feed.
Przed otwarciem konferencji ekran pokazuje numer wydarzenia, warunek wejścia, countdown, identity graczy, ich rank i — tam, gdzie ma to sens — aktualne KD.
W Attack Shop gracz wybiera target i rodzaj ataku. Dostępne poziomy to m.in. CHEAP SHOT — 5 KD, PRESS QUESTION — 10 KD, PERSONAL FOUL — 20 KD, PRIME TIME HIT — 35 KD i NUCLEAR — 50 KD.
System buduje kontekst targetu i losuje dokładnie trzy różne statementy dla tego samego przeciwnika, rodzaju ataku i ceny. Gracz wybiera jeden, ogląda preview i dopiero wtedy publikuje. W MVP nie ma darmowego rerolla ani free-text insults.
Live Press Feed nie wygląda jak Messenger. To szerokie poziome pole rozmowy. Starsze wypowiedzi zostają po lewej, nowsze wchodzą z prawej, a rebuttal pojawia się blisko ataku, na który odpowiada. Osobna warstwa Twitter-like reactions buduje fikcyjny szum mediów i publiczności, ale nie zastępuje właściwych statementów graczy.
Ten ekran pokazuje dwie ekonomie, które celowo pozostają od siebie oddzielone.
Na górze znajduje się realny Prize Pool sezonu: jedna duża kwota, jeden zwycięzca po Week 18. Nie jest rozdawana co tydzień i nie powinna wyglądać jak kolejny licznik punktów.
Niżej działa fikcyjna ekonomia Kilo Dollars. Punkty zdobywane w lidze mogą budować KD, a KD może być później wydawane w Press Conference. Wydanie KD nigdy nie usuwa punktów sezonowych.
Środkowa część może pokazywać oś w rodzaju:
W01 +8 KD → W02 +11 KD → PRESS 01 -35 KD → ... → W10 +9 KD → PRESS 02 -20 KD
Na dole zostają tylko 2–3 najmocniejsze statystyki sezonowej ekonomii: BIGGEST SPENDER, TOTAL KD BURNED, MOST ACTIVE ATTACKER, MOST ATTACKED czy BANKRUPT BUT LOUD.
To ma wyglądać jak absurdalna sportowa relacja z pieniędzy i ego, nie jak banking albo crypto dashboard.
Ostatni ekran celowo wyhamowuje cały program.
Po tabelach, wynikach, statystykach, editorialu, konferencji i pieniądzach zostaje stadion, bramka i jeden cytat.
Reguła kompozycyjna jest niezmienna: THE QUOTE ALWAYS SITS PHYSICALLY BETWEEN THE TWO UPRIGHTS. Słupki same stają się ramą typograficzną.
Kadr może się zmieniać: frontalny, niski, 3/4, nocny stadion, zachód słońca, pusty obiekt, mgła, deszcz, śnieg albo piłka przelatująca nad poprzeczką. Cytat zawsze zostaje pomiędzy słupkami i pozostaje głównym elementem.
To świadomie cichy finał:
goalpost + quote + stadium + silence after the game
W prywatnej lidze wynik jest tylko częścią zabawy. Druga część to relacja pomiędzy ludźmi.
Dlatego użytkownik nie powinien być wyłącznie wierszem w standings. Produkt daje mu wynik, pozycję, historię tygodni i możliwość wejścia w kolejne role narracyjne.
Press Conference jest minigame’em i jednocześnie rozszerzeniem narracji.
Po wydarzeniach kolejki gracz może zostać potraktowany jak postać, której wynik ma konsekwencje. Zamiast kolejnego automatycznego komunikatu pojawia się interakcja stylizowana na konferencję po meczu.
Ta funkcja działa dlatego, że nie jest doklejona do abstrakcyjnego profilu użytkownika. Jest osadzona w świeżym kontekście ligi.
Trash Talk daje rywalizacji bardziej bezpośredni język. To przestrzeń dla emocji, które normalnie uciekłyby do osobnego komunikatora.
Projekt nie próbuje zastąpić pełnej platformy społecznościowej. Chodzi o zachowanie takich interakcji, które wzmacniają sens ligi i wracają do broadcastowej narracji.
Najciekawsze komentarze nie są przypadkowe. Pojawiają się wtedy, kiedy wynik tworzy sytuację wartą rozmowy: zmianę lidera, nieudany tydzień, serię albo bezpośredni pojedynek.
Dzięki temu social layer nie jest osobnym modułem „community”. Jest kolejną reakcją produktu na dane.
Kiedy wynik, historia pozycji, komentarz i konferencja zaczynają odnosić się do tej samej osoby, liga zyskuje pamięć personalną.
Użytkownik nie jest już tylko kontem z liczbą punktów. Staje się kimś, o kim produkt potrafi coś powiedzieć.
Visual pass miał bardzo konkretny kontrakt: nie zmieniać silnika gry tylko dlatego, że nowa kompozycja wygląda lepiej.
Warstwa wizualna musiała respektować istniejący scoring, picki, Commentatora, Press Conference, JSON-y, modele, routing i backend.
To ograniczenie było kluczowe. Oddzielało redesign działającego produktu od projektowania atrakcyjnych makiet bez zobowiązań.
Nowy ekran mógł zmienić pozycję tabeli, skalę headline’u, ilość oddechu i sposób przejścia między segmentami. Nie mógł jednak wymagać innego modelu danych tylko dlatego, że w mockupie byłoby wygodniej.
Jeżeli tabela ma określoną strukturę, projekt musi ją unieść. Jeżeli Press Conference ma własny stan, layout musi go obsłużyć. Jeżeli Commentator korzysta z JSON-u, wizualna warstwa nie może zastąpić go statycznym tekstem.
To zmuszało do projektowania do realnego produktu.
Najłatwiejszy sposób na zrobienie efektownego redesignu polega na wybraniu jednego idealnego stanu danych i zaprojektowaniu pod niego całego ekranu. To działa na Behance. Gorzej działa w produkcie.
PICK’EM musi unieść różne tygodnie, różne wyniki i różną liczbę znaczących wydarzeń. Tabela może zmienić układ. Komentarz może być krótszy albo dłuższy. Press Conference może pojawić się w innym kontekście. Dane kolejki nigdy nie są tak estetycznie posłuszne jak mockup.
Dlatego visual pass był oceniany nie tylko na jednym „hero stanie”, ale jako system zdolny przyjąć zmienną treść bez utraty hierarchii.
Zmiana pozycji elementu może wyglądać niewinnie, ale w aplikacji bywa zmianą znaczenia. Jeżeli status przestaje być kojarzony z konkretnym meczem, jeżeli pick wygląda jak zwykły label albo komentarz zaczyna dominować nad wynikiem, projekt wizualny wprowadza błąd nawet wtedy, gdy wszystko wygląda lepiej.
Dlatego kolejne iteracje były sprawdzane przez pryzmat kontraktów: co jest akcją, co wynikiem, co stanem, co komentarzem i co tylko oprawą.
Architektura uwzględnia ENTRY / LOBBY jako warstwę wejściową, ale po wejściu użytkownik trafia do właściwego doświadczenia ligi. Projekt nie próbował przy tej okazji budować pełnego systemu autoryzacji od zera.
To był świadomy zakres: najważniejszym obszarem pozostawała liga, jej dane, scoring, narracja i broadcast.
Zmiana mechanizmu synchronizacji wyników również musiała respektować istniejący model produktu.
Celem nie było stworzenie agresywnego pollingu. Obecność aktywnego użytkownika ma wystarczyć do uruchomienia sprawdzenia wtedy, kiedy istnieje realna potrzeba. Lock syncInProgress, lastSyncAt, lokalny Schedule, 15-minutowy cooldown i próg kickoff + 2h45 tworzą razem kontrolowany mechanizm.
To jest przykład tego samego sposobu myślenia co visual pass: nie dokładamy efektu. Budujemy zachowanie wynikające z warunków systemu.
W trakcie visual pass logika została potraktowana jak warstwa zamrożona. Można było poprawiać hierarchię, typografię, światło, przejścia ekranów i sposób prezentacji tabel. Nie można było bez potrzeby przepisywać scoringu ani modeli.
Dzięki temu iteracja wizualna pozostawała iteracją wizualną, a nie niekontrolowanym refaktorem całej aplikacji.
Najbardziej charakterystyczne problemy nie dotyczyły „ładnego koloru”. Dotyczyły relacji pomiędzy elementami.
Na jednym z ekranów tabela wchodziła w konflikt z dużym niebieskim prostokątem i kaskiem. Rozwiązaniem nie było usunięcie tabeli, tylko przebudowanie warstw i proporcji.
Przejście pomiędzy ekranami 01 i 02 było początkowo zbyt twarde. Zamiast dodawać kolejny efekt, trzeba było pozwolić obrazowi i światłu przejść przez granicę segmentu.
W kilku miejscach było zbyt dużo pustego tła. Problemem nie była sama biel czy granat, ale brak wizualnej informacji, że segmenty należą do jednej transmisji.
To były decyzje kompozycyjne, nie dekoracyjne.
Po visual pass nadal działa ten sam rdzeń:
Nowa warstwa wizualna miała zwiększyć czytelność i emocję bez łamania kontraktów, na których opiera się produkt.
Dopiero działający produkt pokazuje, czy broadcastowa metafora naprawdę jest systemem.
Jeżeli ekran wygląda dobrze wyłącznie przy jednym zestawie nazw i wyników, to nie jest system. Jeżeli nowy komentarz rozsypuje kompozycję, to nie jest system. Jeżeli tabela przestaje być czytelna na mniejszym ekranie, art direction przegrywa z użyciem.
Dlatego końcowe decyzje wizualne trzeba traktować razem z zachowaniem danych i responsywnością. Im bardziej ekspresyjna jest forma, tym większej dyscypliny potrzebuje w stanie produkcyjnym.
Finalny kierunek nie komplikuje podstawowej mechaniki. Nadal można wejść, zrobić picki i zdobywać punkty.
Zmienia się natomiast wszystko, co dzieje się wokół tego prostego gestu.
Dla gracza wybór ma dłuższe życie. Wraca w wyniku, standings, historii tygodni, komentarzu i kolejnych segmentach narracji.
Dla ligi sezon przestaje być zbiorem odizolowanych weekendów. Week-by-week battle i season moments budują ciągłość, a 1 230 elementów narracyjnych nadaje zmianom własny język.
Dla produktu API, lokalny Schedule, scoring, statystyki i narrative engine przestają być oddzielnymi funkcjami. Tworzą przepływ.
Dla identyfikacji broadcast nie jest dekoracją. Organizuje wejście, akcję, analizę, komentarz i podsumowanie.
Najprostszy opis całego produktu brzmi:
DATA mówi, co się wydarzyło.
GAME mówi, co to zmieniło.
STORY mówi, dlaczego warto to pamiętać.
Żadna z tych warstw nie wystarczyłaby sama.
Bez danych narracja byłaby fikcją. Bez mechaniki dane byłyby scoreboardem. Bez narracji gra kończyłaby się na tabeli.
Case study dokumentuje architekturę produktu, visual pass, integrację danych, system synchronizacji, statystyki i warstwę narracyjną.
Nie przypisuje projektowi wzrostu retencji, czasu sesji ani zaangażowania bez wiarygodnych danych z pełnego użytkowania. Jeżeli produkt zbierze taki materiał po sezonie, może on zostać dodany jako kolejna warstwa case study.
Prosta mechanika nie oznacza prostego produktu. Jeden punkt za poprawny typ może zasilać bardzo bogate doświadczenie, jeśli konsekwencje są projektowane świadomie.
API powinno być odpytywane z intencją. Lokalny stan, cooldown i lock są tak samo ważne jak sam request.
Statystyki potrzebują czasu, nie tylko wartości. Aktualna tabela mówi mniej niż historia zmian, które do niej doprowadziły.
Narracja działa tylko wtedy, kiedy wynika z systemu. Biblioteka 1 230 tekstów ma sens dlatego, że reaguje na realny stan ligi.
Broadcast jest strukturą, nie skórką. Największa wartość tej metafory polega na tym, że porządkuje produkt od wejścia do podsumowania sezonu.
Visual pass powinien respektować działający silnik. Nowa forma jest silniejsza, kiedy nie wymaga poświęcenia logiki, którą produkt już posiada.
PICK’EM jest projektem, w którym cotygodniowa mechanika wyboru została rozbudowana w doświadczenie sezonowe oparte na przepływie DATA → GAME → STORY.
TheSportsDB dostarcza dane meczowe wtedy, kiedy lokalny stan rzeczywiście ich potrzebuje. Scoring zamienia wynik w konsekwencję dla gracza. Standings i week-by-week battle budują pamięć. Narrative engine interpretuje zmianę. Broadcast nadaje całości rytm i formę.
Najważniejszym rezultatem nie jest liczba ekranów ani liczba tekstów.
Jest nim ciągłość.
Użytkownik dokonuje wyboru raz. Produkt pamięta jego konsekwencje przez cały sezon.
DATA BECOMES RIVALRY. RIVALRY BECOMES STORY.