Warszat Data Thinking dla Uniwersytetu SWPS

TL;DR

• Kontekst: Poznałem metodę Data Thinking na konferencji, potem pojechałem na pełne szkolenie do Berlina, do jej twórcy.
• Problem: Studenci SWPS mieli w weekend hackathon UX i znali Design Thinking, ale nie mieli frameworku do myślenia danymi.
• Co zrobiłem: Poprowadziłem pro bono autorski warsztat dla ~20 zespołów (40–60 studentów), z własnymi kartami pracy zamiast gotowego szablonu.
• Wynik: Bardzo dobry feedback uczestników; warsztat przygotował ich do weekendowego hackathonu.

Diagnoza

Design Thinking uczy projektować wokół potrzeb użytkownika. Data Thinking uczy tego samego, ale wokół danych: jakie już masz, jakich brakuje i jak je wykorzystać, żeby rozwiązać problem. Poznałem tę metodę na konferencji (prezentacja Tiziana Kronsbeina), a potem pojechałem do Berlina na pełne szkolenie u niego. Kiedy Uniwersytet SWPS szykował weekendowy hackathon UX, poprowadziłem pro bono warsztat przygotowawczy dla ~20 zespołów studentów. Nie użyłem gotowego szablonu (Data Innovation Board): zaprojektowałem własne karty pracy, żeby uczestnicy odkrywali kolejne etapy stopniowo, zamiast zobaczyć cały proces na starcie.

flowchart LR
    A["Grupy interesariuszy<br/>i ich zadania"] --> B["Potrzeby<br/>użytkowników"]
    B --> C["Rodzaje danych<br/>czujniki, API, systemy"]
    C --> D["Rozwiązania AI/ML<br/>segmentacja, scoring, anomalie, predykcja"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A,B,C neutral
    class D accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

Co zrobiłem

• Zaprojektowałem scenariusz warsztatu: studenci wcielali się w zarządców nowoczesnego budynku (mieszkania, restauracje, biura, sklepy), a wszystkie zespoły pracowały na tym samym kontekście.
• Zbudowałem własne karty pracy w czterech modułach: grupy interesariuszy i ich zadania, potrzeby użytkowników, rodzaje danych (czujniki, API, systemy wewnętrzne), rozwiązania AI/ML (segmentacja, scoring, wykrywanie anomalii, predykcja).
• Wytłumaczyłem podstawy protokołu HTTP i API: dla wielu studentów pierwsze zetknięcie z tym, jak automatycznie pobierać dane z zewnętrznych źródeł.
• Poprowadziłem warsztat samodzielnie, pro bono, dla ~20 zespołów po 2–3 studentów (~40–60 osób), latem 2023.

Wyniki

• ~20 zespołów studentów (~40–60 osób) przeszło przez cały warsztat.
• Bardzo dobry feedback uczestników.
• Warsztat przygotował studentów do weekendowego hackathonu UX.
• Metoda zaadaptowana z Berlina: własne karty pracy zamiast gotowego Data Innovation Board.

Problem

Dlaczego studenci potrzebowali warsztatu przed hackathonem?

Bo znali Design Thinking, ale nie mieli frameworku do myślenia o tym, jakie dane mają do dyspozycji i jak je wykorzystać w rozwiązaniu. Bez tego wielu zespołów wpadłoby w hackathon prosto z pomysłem na interfejs, bez zastanowienia się, jakie dane w ogóle napędzają decyzję, którą projektują.

Dlaczego nie użyć gotowego szablonu Data Innovation Board?

Bo pokazanie całego template’u na starcie zaburzyłoby proces myślowy, na którym mi zależało. Chciałem, żeby uczestnicy odkrywali kolejne pytania stopniowo: najpierw kto jest w grze i co robi, potem czego potrzebuje, dopiero potem jakie dane i jakie rozwiązania AI/ML mogą pomóc. Własne karty pracy dały mi kontrolę nad tym tempem.

Moja rola / zakres

• Samodzielny prowadzący, pro bono, w trakcie pełnoetatowej pracy (Product Manager w firmie e-commerce).
• Zaprojektowałem scenariusz, karty pracy i cały przebieg warsztatu: od researchu metody u źródła po facylitację na sali.

Proces

• Nauka metody u źródła: konferencja, potem pełne szkolenie w Berlinie u Tiziana Kronsbeina.
• Adaptacja pod grupę: stopniowe odkrywanie etapów zamiast pokazania całego template’u na starcie.
• Wspólny scenariusz (zarządzanie budynkiem) dla wszystkich zespołów, żeby dało się porównać podejścia i łatwiej facylitować.
• Poprowadzenie jednorazowo, latem 2023, tuż przed weekendowym hackathonem.

Kluczowe decyzje i trade-offy

• Własne karty pracy zamiast gotowego Data Innovation Board. Straciłem czas na zaprojektowanie od zera, ale zyskałem stopniowe odkrywanie etapów dopasowane do długości warsztatu, czego gotowy szablon by nie dał.

• Wspólny scenariusz dla wszystkich zespołów. Mniej swobody wyboru własnego tematu, ale każdy zespół startował z tym samym kontekstem, więc łatwiej było porównywać podejścia i pomagać zespołom, które utknęły.
• Szczerze: warsztat nie był powtórzony. Jednorazowy, pro bono, obok pełnoetatowej pracy. Nie było przestrzeni, żeby rozwinąć go w cykliczny format.

Jak to się skończyło

Warsztat odbył się raz, latem 2023, i dostał bardzo dobry feedback od uczestników, ale nigdy nie był powtórzony, bo robiłem go pro bono obok pełnoetatowej pracy. Dziś, z dostępem do narzędzi vibe-codingu, rozwinąłbym go o piąty moduł: przejście od karty pracy AI/ML do działającego prototypu w Google AI Studio albo podobnym narzędziu, żeby studenci zobaczyli, jak blisko jest od pomysłu do czegoś klikalnego.

Co z tego wyniosłem

• Stopniowe odkrywanie etapów działa lepiej niż pokazanie całego frameworku na starcie. Uczestnicy myślą o kroku, w którym są, zamiast próbować przeskoczyć do końca.
• Wspólny scenariusz dla wszystkich grup ułatwia facylitację. Łatwiej pomóc zespołowi, kiedy znasz kontekst, w którym utknął.
• Metoda nauczona u źródła przenosi się dobrze do innej grupy. Od pracowników firmy do studentów: szkielet myślenia danymi jest uniwersalny, zmienia się tylko scenariusz.
• Format pasuje do biznesu w erze AI. Łącząc źródła danych z agentami AI, można niemal zautomatyzować budowę narzędzia, testowanie i monitoring, a UX-owiec prowadzi to od researchu potrzeb po wdrożenie.