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. Znali Design Thinking, ale nie mieli sposobu, żeby myśleć o danych.
- Co zrobiłem: Poprowadziłem pro bono autorski warsztat dla ~20 zespołów (40–60 studentów) na własnych kartach pracy.
- Wynik: Uczestnicy bardzo dobrze ocenili warsztat, a studenci byli przygotowani 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 poznawali kolejne etapy po kolei i nie widzieli całego procesu od razu.
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 to był pierwszy kontakt 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.
- Uczestnicy bardzo dobrze ocenili warsztat.
- Studenci byli przygotowani do weekendowego hackathonu UX.
- Metodę z Berlina przełożyłem na własne karty pracy.
Problem
Dlaczego studenci potrzebowali warsztatu przed hackathonem?
Bo znali Design Thinking, ale nie mieli sposobu, żeby pomyśleć, jakie dane mają do dyspozycji i jak je wykorzystać. Bez tego wiele zespołów weszłoby w hackathon od razu z pomysłem na interfejs. Nie zastanowiłyby się, na jakich danych w ogóle opiera się decyzja, którą projektują.
Dlaczego nie użyć gotowego szablonu Data Innovation Board?
Bo gdybym pokazał cały szablon na starcie, uczestnicy przeskakiwaliby do końca procesu. 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.
- Dopasowanie do grupy: etapy odsłaniane po kolei.
- 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. Zaprojektowanie ich od zera zajęło mi sporo czasu. W zamian mogłem odsłaniać etapy po kolei i dopasować tempo do długości warsztatu. Gotowy szablon by na to nie pozwolił.
| Podejście | Trade-off | Decyzja |
|---|---|---|
| Gotowy Data Innovation Board | szybciej gotowy, cały proces widoczny od razu | odrzucone |
| Własne karty pracy | więcej pracy, kontrola nad tempem | wybrane |
- Wspólny scenariusz dla wszystkich zespołów. Zespoły nie mogły wybrać własnego tematu. Za to wszystkie startowały z tego samego miejsca, więc łatwiej było porównywać podejścia i pomagać tym, które utknęły.
- Warsztat odbył się tylko raz. Muszę przyznać, że przy pracy na etacie i formule pro bono zabrakło mi czasu, żeby zrobić z niego cykl.
Jak to się skończyło
Warsztat odbył się raz, latem 2023, i uczestnicy bardzo dobrze go ocenili. Dziś, kiedy są narzędzia do vibe-codingu, dodałbym piąty moduł. Studenci przechodziliby w nim od karty pracy z pomysłem na AI/ML do działającego prototypu w Google AI Studio albo podobnym narzędziu. Zobaczyliby wtedy, jak blisko jest od pomysłu do czegoś, w co można kliknąć.
Co z tego wyniosłem
- Etapy lepiej odsłaniać po kolei. Uczestnicy myślą wtedy o kroku, na którym są, i nie próbują 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ął.
- Metodę da się przenieść na inną grupę. Sprawdza się i w firmie, i ze studentami. Zmienia się tylko scenariusz.
- Według mnie ten format dobrze pasuje do pracy z AI. Kiedy połączy się źródła danych z agentami AI, budowę narzędzia, testy i monitoring można w dużej części zautomatyzować. UX-owiec może wtedy prowadzić całość, od badania potrzeb po wdrożenie.