Projekt art-tech: od pomysłu do prezentacji

Projekt art-tech na hackathonie nie wygrywa dlatego, że ma najwięcej funkcji. Zwykle wygrywa ten, który w krótkim czasie potrafi połączyć trzy rzeczy: czytelny problem, przekonującą formę artystyczną i prototyp pokazujący, że pomysł nie kończy się na efektownym haśle.

To zasadnicza różnica między koncepcją a projektem gotowym do obrony przed jury. Wydarzenia łączące sztukę i technologię nie wymagają zazwyczaj kompletnego produktu ani w pełni skomercjalizowanego rozwiązania. Oczekują działającego fragmentu oprogramowania, funkcjonalnej makiety, instalacji demonstracyjnej albo projektu graficznego obejmującego podstawowe ekrany. Innymi słowy: trzeba pokazać nie wszystko, lecz dokładnie to, co pozwala zrozumieć sens pomysłu.

W praktyce projekt art-tech na hackathonie przechodzi kilka wyraźnych etapów: od zbudowania zespołu, przez wybór problemu i szybkie prototypowanie, aż po kilkuminutową prezentację. Każdy z nich wymaga innego rodzaju pracy. Najpierw liczy się różnorodność kompetencji, później dyscyplina, a na końcu umiejętność opowiedzenia o rozwiązaniu bez zasłaniania go technicznym szczegółem.

Zespół interdyscyplinarny: nie zbieraj podobnych osób

Najczęstszy błąd pojawia się jeszcze przed rozpoczęciem pracy nad samym pomysłem. Uczestnicy szukają ludzi o podobnych zainteresowaniach albo próbują zbudować zespół wyłącznie wokół jednej kompetencji. Tymczasem w projekcie łączącym sztukę i technologię nie wystarczy ani sam programista, ani sam artysta.

Interdyscyplinarność nie jest ozdobnikiem wpisywanym do opisu wydarzenia. Ma bardzo praktyczny sens. Programista może zbudować działający mechanizm, ale nie zawsze rozpozna, czy użytkownik rozumie interakcję. Artysta potrafi nadać projektowi własny język, ale niekoniecznie przełoży wizję na ograniczony czasowo prototyp. Projektant doświadczeń użytkownika uporządkuje ścieżkę odbiorcy, a badacz kultury pomoże uniknąć uproszczeń dotyczących obiektu, miejsca lub dziedzictwa.

W zespole mogą znaleźć się:

• programista odpowiedzialny za logikę działania, integrację narzędzi i stabilność prototypu;
• artysta lub twórca wizualny, który określa język projektu, atmosferę oraz sposób pracy z materiałem;
• projektant doświadczenia użytkownika, porządkujący kolejne kroki odbiorcy;
• grafik lub projektant interfejsu, przekładający koncepcję na ekrany, obiekty i elementy wizualne;
• projektant dźwięku, gdy dźwięk jest częścią interakcji, a nie jedynie tłem;
• humanista, kurator, historyk sztuki lub badacz, który pomaga osadzić rozwiązanie w kontekście.

Nie oznacza to, że każdy zespół musi mieć sześć osób. W wybranych edycjach Art x Tech Hackathon zespoły liczyły maksymalnie cztery osoby. Przy takim ograniczeniu nie da się obsadzić każdej funkcji osobno. Trzeba więc szukać osób łączących kompetencje, na przykład projektanta, który potrafi przygotować zarówno doświadczenie użytkownika, jak i prosty interfejs, albo programisty zainteresowanego pracą z obrazem, dźwiękiem czy sztuką generatywną.

Kluczowe jest nie tylko to, kto co umie, ale też kto podejmuje decyzje. Już na początku warto ustalić, kto prowadzi pracę nad koncepcją, kto odpowiada za prototyp, kto pilnuje warstwy wizualnej i kto przygotowuje wystąpienie. W przeciwnym razie zespół może spędzić kilka godzin na uzgadnianiu podstaw, zamiast budować rozwiązanie.

W art-techu różnorodność zespołu nie polega na liczbie zawodów w stopce. Polega na tym, że każdy patrzy na ten sam problem z innej strony i potrafi tę perspektywę przełożyć na decyzję projektową.

Dobry zespół nie próbuje od razu rozwiązać całego obszaru kultury. Wybiera jeden konkretny moment kontaktu odbiorcy z dziełem, kolekcją, archiwum lub miejscem. To może być sposób zwiedzania wystawy, dostęp do nieczytelnych materiałów, opowiadanie historii obiektu albo doświadczenie osoby, która nie zna języka specjalistycznego.

Od wyzwania do koncepcji: zawężenie jest częścią pomysłu

Wyzwania hackathonowe dotyczące dziedzictwa kulturowego często brzmią szeroko. Można w nich zmieścić ochronę zbiorów, edukację, dostępność, promocję, dokumentację, pracę z archiwami czy wykorzystanie sztucznej inteligencji. To atrakcyjny punkt wyjścia, ale również pułapka.

Szerokie wyzwanie daje poczucie swobody. Jednocześnie łatwo prowadzi do projektu, który chce być naraz przewodnikiem, platformą edukacyjną, narzędziem dla muzeum i doświadczeniem artystycznym. Po kilkunastu godzinach powstaje wtedy wiele luźnych funkcji, lecz żadna nie działa wystarczająco dobrze.

Dlatego pierwsza burza mózgów powinna zakończyć się nie listą pomysłów, ale wyborem jednego napięcia projektowego. Zamiast pytać, jak wykorzystać sztuczną inteligencję w muzeum, lepiej zapytać:

• czego odbiorca nie może dziś zobaczyć, usłyszeć albo zrozumieć;
• który fragment kontaktu z dziedzictwem jest obecnie zbyt trudny lub pasywny;
• co zmieni się w doświadczeniu użytkownika po zastosowaniu technologii;
• jaki element projektu ma charakter artystyczny, a jaki służy rozwiązaniu problemu;
• po czym poznamy, że prototyp rzeczywiście działa.

To ostatnie pytanie bywa pomijane. Tymczasem pomaga odróżnić funkcję od dekoracji. Jeżeli projekt zakłada interaktywną instalację, trzeba określić, na czym polega interakcja: czy użytkownik porusza się w przestrzeni, reaguje na obraz, wybiera ścieżkę narracji, uruchamia dźwięk, manipuluje obiektem, czy może wpływa na generowaną treść. Sama obecność czujnika, kamery albo modelu sztucznej inteligencji nie tworzy jeszcze doświadczenia.

Jak filtrować pomysły w pierwszych godzinach

Warto przeprowadzić pomysły przez cztery pytania:

1. Czy problem jest konkretny?

Jeśli opis rozwiązania pasuje równie dobrze do muzeum, festiwalu, biblioteki i aplikacji zakupowej, prawdopodobnie nie został jeszcze właściwie określony.

2. Czy technologia wnosi coś więcej niż efekt nowości?

Rozpoznawanie obrazu, generowanie treści lub rozszerzona rzeczywistość powinny zmieniać sposób odbioru dzieła albo dostępu do wiedzy. Nie wystarczy dodać technologię do gotowego pomysłu.

3. Czy da się pokazać działanie w prototypie?

Jeżeli pełna wersja wymaga miesięcy pracy, zespół musi wybrać jeden reprezentatywny fragment. Prototyp nie może być tylko obietnicą przyszłej aplikacji.

4. Czy pomysł da się wyjaśnić bez słownika branżowego?

Jury powinno w kilka sekund zrozumieć, dla kogo jest rozwiązanie i co użytkownik może dzięki niemu zrobić.

W projektach związanych z dziedzictwem kulturowym dochodzi jeszcze kwestia odpowiedzialności. Materiał historyczny, archiwalny lub muzealny nie jest neutralnym surowcem do dowolnego przetworzenia. Zespół powinien wiedzieć, co interpretuje, co rekonstruuje, a co generuje. Jeżeli sztuczna inteligencja tworzy wariant narracji lub obrazu, odbiorca nie powinien być pozostawiony z wrażeniem, że ogląda autentyczny dokument.

Nie trzeba w ciągu hackathonu rozstrzygać wszystkich problemów prawnych, konserwatorskich i etycznych. Trzeba jednak zauważyć te, które wpływają na sens prototypu. Pomysł dotyczący cyfrowej rekonstrukcji, na przykład, powinien jasno oddzielać źródło od warstwy interpretacyjnej. Projekt wykorzystujący wizerunki lub nagrania powinien przynajmniej sygnalizować, że sposób użycia materiału wymaga dalszej weryfikacji.

Prototypowanie: pokaż jeden działający fragment

W projektowaniu prototypu najwięcej czasu traci się na budowanie zaplecza, którego nikt później nie zobaczy. Zespół tworzy rozbudowaną strukturę danych, dopracowuje system kont, projektuje wiele ekranów i planuje kilkanaście ścieżek użytkownika. Na prezentację zostaje niedziałająca makieta albo kilka efektownych slajdów.

Na hackathonie lepiej działa odwrotna kolejność. Najpierw należy ustalić, jaki jeden moment ma zostać zapamiętany przez jury, a dopiero potem dobrać rozwiązania techniczne. Jeśli sednem projektu jest interaktywna instalacja, prototyp powinien przede wszystkim pokazać reakcję na działanie odbiorcy. Jeżeli chodzi o narzędzie do pracy z kolekcją, trzeba pokazać wyszukanie, odkrycie albo interpretację konkretnego obiektu. Gdy projekt dotyczy narracji generowanej przez sztuczną inteligencję, należy zaprezentować relację między materiałem źródłowym, działaniem użytkownika i wynikiem.

Wymagane minimum na muzealnym hackathonie HackArt obejmowało fragment działającego oprogramowania, funkcjonalną makietę albo projekt graficzny złożony z dwóch–trzech podstawowych ekranów. To dobry punkt odniesienia także wtedy, gdy regulamin konkretnego wydarzenia nie podaje identycznych wymogów. Dwa lub trzy dopracowane ekrany mogą powiedzieć więcej niż kilkanaście pustych widoków.

Trzy poziomy prototypu

Nie każdy projekt musi być prototypem aplikacji. Forma powinna wynikać z pomysłu:

W przypadku instalacji interaktywnej hackathon krok po kroku powinien prowadzić do jednego sprawdzalnego przejścia. Odbiorca wykonuje działanie, system reaguje, a zespół potrafi wyjaśnić, dlaczego ta reakcja ma znaczenie. Nie ma potrzeby budować całej przestrzeni wystawienniczej. Można przygotować jeden obiekt, jeden ekran, jeden rodzaj ruchu albo jedną relację między dźwiękiem i obrazem.

Warto również wcześniej ustalić, co stanie się w razie awarii. Prototyp prezentowany na żywo powinien mieć uproszczony tryb demonstracyjny. Jeśli kamera nie rozpozna gestu, prowadzący musi mieć możliwość uruchomienia właściwej sekwencji ręcznie. Jeśli model generatywny potrzebuje zbyt dużo czasu, można przygotować ograniczony zestaw wyników do pokazania, o ile jasno zaznaczy się, co jest demonstracją, a co działaniem systemu.

To nie jest oszustwo ani rezygnacja z technologii. Prototyp ma pokazać logikę rozwiązania, a nie udawać gotowy produkt. Problem pojawia się dopiero wtedy, gdy zespół prezentuje jako działające coś, co istnieje wyłącznie na slajdzie.

Co powinno znaleźć się w minimalnym prototypie

Najmniejsza użyteczna wersja projektu powinna zawierać:

• jasno określonego odbiorcę;
• jeden scenariusz użycia, który można przejść od początku do końca;
• widoczne działanie technologii;
• rezultat, który użytkownik otrzymuje po interakcji;
• informację, z jakiego materiału lub źródła powstał rezultat;
• sposób awaryjnego uruchomienia demonstracji;
• element wizualny lub dźwiękowy spójny z ideą, a nie dodany przypadkowo.

Warto rozdzielić warstwę konieczną od warstwy pożądanej. Konieczna jest ta funkcja, bez której pomysł przestaje być zrozumiały. Warstwa pożądana może wzbogacić doświadczenie, ale nie powinna zabierać czasu potrzebnego na dopracowanie podstawowego scenariusza.

Harmonogram pracy: najpierw decyzje, potem produkcja

Choć hackathony różnią się długością, ich rytm zwykle jest podobny. Najpierw organizatorzy przedstawiają wyzwania, później uczestnicy formują zespoły i rozwijają pomysły. Następnie pojawiają się konsultacje z mentorami, składanie projektu oraz finałowe prezentacje. W wydarzeniach takich jak KreativHack OUTech właściwa część hackathonu trwała 24 godziny, ale nie oznacza to 24 godzin nieprzerwanej produkcji. Najwięcej zależy od kolejności decyzji.

Przy krótkim maratonie sprawdza się podział na pięć odcinków:

1. Rozpoznanie wyzwania – zespół zapisuje problem własnymi słowami i ustala, czego nie będzie próbował rozwiązać.

2. Wybór scenariusza – powstaje jeden opis działania użytkownika, od pierwszego kontaktu z projektem do rezultatu.

3. Projekt rozwiązania – zespół wybiera technologię, formę wizualną i zakres prototypu.

4. Budowa i testowanie – powstaje działający fragment, a następnie ktoś spoza zespołu próbuje go użyć bez dodatkowych objaśnień.

5. Przygotowanie prezentacji – zespół skraca opowieść do najważniejszych decyzji i ćwiczy demonstrację.

Ten układ chroni przed typową sytuacją: projekt jest gotowy technicznie, ale nikt nie wie, jak go przedstawić. Prezentacja nie powinna być ostatnim zadaniem dopisywanym w pośpiechu. Jej konstrukcja wpływa na to, co zespół buduje od początku.

W praktyce warto przyjąć limit funkcji jeszcze przed rozpoczęciem kodowania lub projektowania. Każda nowa funkcja powinna odpowiedzieć na pytanie: czy poprawia główny scenariusz, czy tylko zwiększa wrażenie rozbudowania? Jeżeli nie da się tego rozstrzygnąć, funkcję lepiej odłożyć.

Równie istotne jest wczesne sprawdzenie połączeń technicznych. Projekt może zależeć od dostępu do internetu, konkretnego urządzenia, biblioteki, modelu generatywnego, projektora albo czujnika. W czasie hackathonu nie ma komfortu wielogodzinnego usuwania problemów środowiskowych. Zespół powinien możliwie szybko uruchomić najprostszy wariant działania, a dopiero potem dodawać kolejne elementy.

Mentorzy: nie szukaj potwierdzenia, szukaj ograniczenia

Konsultacja z mentorem nie jest momentem na przedstawienie dopracowanej autopromocji. Największą wartość daje wtedy, gdy zespół przychodzi z konkretnym problemem i gotowością do zmiany kierunku.

Dobre pytania brzmią na przykład:

• czy główny problem jest widoczny bez naszego wyjaśnienia;
• który element prototypu warto usunąć, jeśli zabraknie czasu;
• czy interakcja rzeczywiście wynika z charakteru projektu;
• co może być niezrozumiałe dla odbiorcy spoza świata sztuki i technologii;
• czy demonstracja pokazuje rozwiązanie, czy tylko jego techniczne zaplecze;
• jaki jeden rezultat powinien zapamiętać juror po prezentacji.

Mentor może pomóc w kilku różnych obszarach. Osoba techniczna wskaże prostszy sposób zbudowania funkcji lub ostrzeże przed ryzykowną zależnością. Specjalista od kultury pomoże doprecyzować kontekst i język opisu. Projektant doświadczeń użytkownika zauważy moment, w którym odbiorca nie wie, co zrobić. Ekspert od prezentacji może natomiast wskazać, że zespół zaczyna opowiadać o procesie zamiast o wartości projektu.

Feedback trzeba jednak przetworzyć, a nie tylko zebrać. Po każdej konsultacji warto zapisać trzy decyzje: co zmieniamy, czego nie zmieniamy i dlaczego. Nie każda sugestia pasuje do projektu. Przyjęcie wszystkich uwag prowadzi do rozwiązania bez wyraźnego charakteru, tak samo jak odrzucenie wszystkich uwag z przekonaniem, że zespół wie już wszystko.

Najlepszy feedback na hackathonie nie dodaje projektowi kolejnej funkcji. Pomaga rozpoznać tę, bez której cały pomysł nie ma sensu.

Prezentacja w pięć minut: opowieść podporządkowana demonstracji

W finałowej prezentacji jury nie ocenia wyłącznie tego, co zostało zbudowane. Ocenia również, czy zespół rozumie problem, odbiorcę i ograniczenia własnego rozwiązania. Podczas HackArt w Muzeum Narodowym w Warszawie zespoły miały na wystąpienie około pięciu minut. To wystarczająco dużo, aby pokazać działający prototyp, ale za mało, by opowiedzieć historię całego procesu.

Najbezpieczniejsza konstrukcja prezentacji składa się z kilku krótkich części:

1. Problem – jednoznacznie nazwijcie sytuację, która wymaga zmiany.

2. Odbiorca – pokażcie, kto doświadcza tego problemu i w jakim momencie.

3. Pomysł – wyjaśnijcie, co robicie inaczej niż tradycyjne rozwiązania.

4. Demonstracja – pokażcie jeden scenariusz od działania użytkownika do rezultatu.

5. Znaczenie – powiedzcie, co projekt zmienia i jaki może być jego następny etap.

Nie warto zaczynać od listy wykorzystanych narzędzi. Informacja, że projekt korzysta z określonego modelu, biblioteki czy technologii rozpoznawania obrazu, jest istotna dopiero wtedy, gdy wiadomo, po co została użyta. Technologia powinna pojawić się jako odpowiedź na problem, nie jako główny bohater wystąpienia.

Również warstwa artystyczna wymaga konkretu. Zamiast mówić, że projekt buduje nową relację między odbiorcą a dziedzictwem, lepiej pokazać, co odbiorca robi, co widzi i co zmienia się dzięki jego działaniu. Język prezentacji może być ambitny, ale demonstracja powinna pozostać prosta.

Jak przygotować pokaz na żywo

Próba prezentacji nie powinna polegać na samym odczytaniu tekstu. Trzeba przećwiczyć także przejścia między osobami, uruchomienie prototypu i reakcję na nieprzewidzianą sytuację.

Przed finałem zespół powinien ustalić:

• kto prowadzi narrację;
• kto obsługuje prototyp;
• w którym momencie pojawia się demonstracja;
• co pokazujecie, jeśli funkcja nie uruchomi się automatycznie;
• które slajdy można pominąć bez utraty sensu;
• jak odpowiecie na pytanie o dalszy rozwój projektu.

Warto ograniczyć liczbę elementów potrzebnych do pokazu. Każde dodatkowe urządzenie, przewód, konto, połączenie lub zewnętrzna usługa zwiększa ryzyko. Jeżeli projekt wymaga instalacji interaktywnej, lepiej pokazać stabilny, mniejszy fragment niż pełną wizję działającą tylko w idealnych warunkach.

Nie należy też ukrywać ograniczeń. Prototyp nie musi być kompletnym produktem. Uczciwe wskazanie, które elementy są uproszczone, a które wymagają dalszych prac, działa na korzyść zespołu. Pokazuje, że autorzy odróżniają demonstrację pomysłu od obietnicy gotowego wdrożenia.

Co decyduje o jakości projektu art-tech

Projekt łączący sztukę i technologię ma kilka warstw, ale jury powinno móc zobaczyć ich spójność. Sama atrakcyjność wizualna nie wystarczy, jeśli użytkownik nie wie, co robić. Działający kod nie wystarczy, jeśli nie wiadomo, dlaczego został użyty. Trafny problem nie wystarczy, jeśli zespół nie potrafi przełożyć go na doświadczenie.

Najsilniejsze projekty zwykle mają następujące cechy:

• konkretny punkt wyjścia – problem nie jest opisany jako ogólna potrzeba innowacji;
• wyraźnego odbiorcę – wiadomo, kto korzysta z rozwiązania i w jakiej sytuacji;
• technologię podporządkowaną idei – narzędzie wzmacnia doświadczenie zamiast dominować nad nim;
• jeden dopracowany scenariusz – można przejść go od początku do końca;
• czytelną warstwę artystyczną – forma nie jest dekoracją doklejoną do aplikacji;
• realistyczny zakres – prototyp pokazuje możliwość rozwoju, ale nie udaje gotowego systemu;
• spójną prezentację – problem, rozwiązanie i demonstracja tworzą jedną opowieść.

Warto przy tym pamiętać, że kreatywny hackathon nie jest konkursem na najbardziej futurystyczne hasło. Projekty wykorzystujące sztuczną inteligencję, rozszerzoną rzeczywistość czy generatywną grafikę mogą robić wrażenie, ale szybko ujawniają słabość, jeśli technologia nie poprawia dostępu do kultury ani nie pogłębia doświadczenia odbiorcy.

W kontekście dziedzictwa kulturowego szczególnie ważna jest wiarygodność. Zespół powinien rozumieć, czy jego rozwiązanie pomaga odkrywać materiał, porządkować go, interpretować, chronić czy popularyzować. Te cele nie są wymienne. Narzędzie do edukacji będzie projektowane inaczej niż instalacja przeznaczona do kontemplacji dzieła, a system wspierający pracę z archiwum inaczej niż aplikacja dla zwiedzających.

Od prototypu do dalszego rozwoju

Po zakończeniu hackathonu projekt zwykle wymaga dalszego dopracowania. Prototyp odpowiada na pytanie, czy pomysł da się pokazać i czy ma sens jako doświadczenie. Nie odpowiada jeszcze na wszystkie pytania dotyczące utrzymania, dostępności, bezpieczeństwa, praw do materiałów, skalowania czy wdrożenia w konkretnej instytucji.

Dlatego po prezentacji warto spisać kolejne kroki w kolejności, a nie tworzyć długą listę życzeń. Najpierw należy sprawdzić, czy użytkownicy rozumieją podstawową interakcję. Potem można rozwijać warstwę techniczną, poszerzać zasób materiałów, dopracowywać formę i szukać miejsca, w którym projekt rzeczywiście mógłby działać.

W przypadku narzędzi dla muzeów i instytucji kultury dochodzą kwestie organizacyjne. Kto będzie aktualizował treści? Kto zatwierdzi interpretacje? Czy rozwiązanie zadziała na sprzęcie dostępnym w danej przestrzeni? Czy odbiorca z niepełnosprawnością będzie mógł skorzystać z doświadczenia? Czy projekt wymaga stałego połączenia z internetem? Te pytania nie muszą blokować hackathonu, ale powinny pojawić się w planie dalszej pracy.

Najważniejsze jest zachowanie proporcji między ambicją a demonstracją. Hackathon daje ograniczony czas, więc nie da się w nim rozwiązać całego problemu kultury. Można jednak pokazać jeden trafnie wybrany fragment, który otwiera drogę do większego rozwiązania.

Projekt art-tech na hackathonie przechodzi zatem od pomysłu do prezentacji nie przez dokładanie funkcji, lecz przez kolejne zawężenia. Zespół wybiera konkretny problem, konkretną grupę odbiorców, konkretną interakcję i konkretny rezultat. Dopiero na takiej podstawie technologia oraz forma artystyczna zaczynają pracować razem.

To właśnie powinien pokazać dobry prototyp: nie obietnicę, że kiedyś powstanie interesujący produkt, ale przekonujący dowód, że pomysł ma własną logikę, działa w praktyce i zasługuje na następny etap.