ok. 6 minut czytania - polub, linkuj, komentuj!

Czy dokładamy forum, czy nie? Jak robimy nawigację po kursie? Co dodajemy, co usuwamy? Co powinno być na ekranie szkolenia?

Projektując usługi cyfrowe często stajemy przed dylematem co powinno znaleźć się w produkcie szkoleniowym, a co nie. Dotyczy to zarówno konfiguracji platformy jak i decyzji, jakiego rodzaju treści umieszczamy, a z jakich rezygnujemy.

Na początku wieku realizowałem wiele projektów na Moodle i właściwie wszędzie pojawiał się schemat:

• namawiam klienta, żeby wybrał kluczowe funkcjonalności platformy;

• klient chce, żeby włączyć możliwie wszystkie „ficzery” (w końcu za nie płaci);

• uczestnicy się gubią w dostępnych okienkach i opcjach;

• wyłączamy większość ficzerów pozostawiając kluczowe.

Bo w produkcie cyfrowym łatwo ulec pokusie włączenia wszystkiego, co możemy, ale liczy się odpowiedni dobór – to on decyduje o wartości projektu. Nie wierzysz? Spójrz na dobre aplikacje, które używasz albo choćby na chyba najpopularniejszą stronę na świecie google.com.

Rzecz nie dotyczy tylko platform edukacyjnych, bo nawet zwykłe e-szkolenie może mieć mniej lub więcej „ficzerów”.

Dobór odpowiedniego zestawu funkcjonalności w morzu możliwości cyfrowej edukacji nie jest łatwe. Ja sobie wyrobiłem kilka kategorii, które pozwalają mi nieco uporządkować projektowanie kolejnych produktów cyfrowych.

MUST HAVE – niezbędne lub mocno uzasadnione dla procesu

Są rzeczy, które są po prostu niezbędne dla procesu. Nie zawsze od razu wiadomo które, ale poprzez skupienie się na celach i procesie w myśleniu projektanta lub w rozmowie osób zajmujących się projektem (w moim przypadku ja + jedna lub kilka osób od klienta) pozwala wyłonić te kluczowe elementy do implementacji.

W relacji klient (może być wewnętrzny) – projektant, zwykle klient, określa co niezbędne, ale można go pokierować dopytując po co chce coś mieć lub jakie jest metodyczne uzasadnienie.

Wiadomo, że to, co niezbędne trzeba zrobić.

Jeśli jest coś niezbędnego, ale drogiego, to można poszukać alternatyw.

NICE TO HAVE – fajnie mieć, ale świat się nie zawali

To rzeczy, które są wartościowe dla procesu, ale nie są niezbędne. Zwykle jest to część rzeczy, które na początku wydawały się niezbędne, ale po bliższym przyjrzeniu okazało się, że nie są.

To warto wycenić (w monetach, pracochłonności) jako opcje i pozostawić decyzji interesariuszy.

Zwykle wtedy pojawia się myślenie w kategoriach stosunku wartości do ceny. Jeśli można wnieść niezbyt drogo wartość, to wdrażamy.  

NIEPOTRZEBNE – potrzebne jak rybie ręcznik

Określenie niepotrzebne sugeruje neutralność. Jednak zarówno w edukacji jak i w myśleniu UX wiemy, że rzeczy niepotrzebne przeszkadzają – stąd lubię je sobie wyobrażać i komunikować rozmówcom jako ręcznik dla ryby. Zwykle zaśmiecają ekran i są jak te okienka Moodle, które na początku wieku powodowały, że ludzie się gubili w morzu opcji.

Nie jest łatwo je rozpoznać. Zwykle są kalką z czegoś, co ktoś kiedyś gdzieś widział i bez głębszej refleksji chce stosować. Warto takie pomysły konfrontować z myśleniem o uzasadnieniu metodycznym w szkoleniu. To, że coś się sprawdza w jednym projekcie nie znaczy, że sprawdzi się w innym.

CORNER CASE - teoretycznie się przydadzą

To grupa oczekiwań, które charakteryzują się jedną cechą – są jakby wydumane. Co jakiś czas ktoś rozkminia mało prawdopodobny scenariusz typu „Jak komuś wyłączą prąd, ale akurat będzie przechodził z ekranu A na ekran B…”.

Zwykle nie opłaca się budowanie jakiejś funkcjonalności dla takiego, mało prawdopodobnego przypadku. Warto wtedy rozważyć „ręczne rozwiązanie”, czyli przyjąć, że jak takie zdarzenie wystąpi, to obsłużymy je ręcznie. Pewnie wyższym nakładem pracy, ale biorąc pod uwagę prawdopodobieństwo wystąpienia to i tak się opłaci bardziej niż inwestycja w mało prawdopodbny scenariusz (wartość oczekiwana i takie tam).

Uwaga! To nie może dotyczyć bezpieczeństwa, bo wtedy potencjalne straty zupełnie zmienią wszystkie obliczenia. 

MUZEUM LOTNICTWA – klient chce i koniec

Czasami klienci wchodzą w rolę dziecka i po prostu chcą. Świadomi kosztów podejmują decyzję, że ma być, choć nie widać logicznego uzasadnienia. To trochę jak z budyniem czekoladowym – nie powinno się go jeść po 22.00, chyba, że bardzo, bardzo, baaardzo się chce – to wtedy można.

Na użytek swojego zespołu, który co jakiś czas marudził, że klient chce, a to „nie ma sensu” przyjąłem nazwę muzeum lotnictwa. Puściłem zespołowi fragment komedii „Chłopaki nie płaczą”, w której Bohdan Łazuka w roli mafioso poucza syna jak ma przyjąć jego gości. Na końcu pojawia się tekst zirytowanego mafioso „A jeżeli będą chcieli pójść do muzeum lotnictwa, to zabierzesz ich do muzeum lotnictwa…”.

W tym przypadku strategia jest prosta: nie dyskutujemy, robimy najlepiej jak umiemy i co najwyżej minimalizujemy straty.

NIEPOROZUMIENIA – sprawdzaj

Nieporozumienia nie są kategorią funkcjonalności. Jednak w pracy nad projektowaniem produktu, szczególnie, gdy mamy dużą kontrolę po stronie interesariuszy, przekonałem się, że dochodzi do nieporozumień.

Ludzie mają tendencję do zakładania, że wszyscy mamy to samo na myśli – jednak często tak nie jest. Rzeczy oczywiste dla mnie nie są oczywiste dla kogoś innego, szczególnie jeśli zawodowo nie zajmuje się projektowaniem systemu. Warto wtedy mieć swoje pytania. Jak mawia Piotr Maczuga „bądź władcą briefu”, bo to zwykle ty ponosisz koszty, w najlepszym przypadku emocjonalne, nieporozumień.

Najbardziej ekstremalnym przypadkiem u mnie w firmie była rezygnacja klienta z „wersji mobilnej”. Platforma, którą zbudowaliśmy była dostosowana do urządzeń mobilnych, ale nie była aplikacją. Łatwo więc zrozumieć osłupienie szefa zespołu deweloperskiego gdy usłyszał, że klient chce usunąć wersję mobilną z działającego portalu. Szczerze mówiąc, to zastanawiał się jak to właściwie zrobić – zepsuć arkusze stylów? Poprosiłem go, żeby zadzwonił do klienta i poprosił o wskazanie tej „części mobilnej” (tak klient się wyraził). Okazało się, że chodzi o usunięcie tak zwanego slideshow, który w rzeczy samej był jedynym elementem animowanym na stronie, więc od biedy nazwa mobilny miała uzasadnienie.

Lepiej dopytać niż się zaangażować w rozwiązywanie nieistniejącego problemu.

Świadomie decyduj co akceptujesz, a czego nie

Składniki produktu cyfrowego to kluczowa sprawa. Dobrze dobrane stanowią podstawę wartości produktu i budzą zachwyt. Źle dobrane mogą albo obniżyć wartość produktu albo uczynić go niepotrzebnie kosztownym, a nawet czasami niewykonalnym w rozsądnym czasie.

Jeżeli pracujesz w zespole mającym wpływ na konstrukcję produktów cyfrowych, to warto mieć swój sposób na zapanowanie nad doborem komponentów do budowy własnych produktów. Wtedy ich kompozycja może się okazać bardzo trafna i wartościowa, a przy tym efektywna kosztowo.

Trudno jest powiedzieć, że coś jest obiektywnie bardziej wartościowe a coś nie. Dlatego warto posortować klocki przy każdym projekcie.

Sławomir Łais – edukator, projektant aplikacji uczących, autor publikacji, bloger praktykatrenera.pl, prelegent wielu konferencji. Prezes OSI CompuTrain, współtwórca metody i narzędzi Learning Battle Cards. Trener, konsultant w stosowaniu nowoczesnych technologii w uczeniu. Członek rady Fundacji Digital Creators. Ambasador EPALE

Zobacz także:

Job Aid - metoda rozwojowa, która wnosi zmianę

Format – świadoma walka z bałaganem w projekcie e-learning

Trzy inspiracje od projektanta gier takich jak PacMan World