Nazywam się Michał Dziedziniewicz i od marca tego roku wspomagam Expansio w kwestiach UX Designu przy projekcie chatbota do nauki programowania: CodeAll (więcej o początkach projektu przeczytacie tutaj). A co to znaczy? Otóż właśnie taki miałem zamiar, żeby w paru słowach opowiedzieć o co chodzi z tym całym projektowaniem UX.

UX Design, czyli User Experience Design to projektowanie doświadczeń użytkownika usługi, czy produktu cyfrowego. Innymi słowy, to pojęcie zbiorcze wielu wątków, którymi trzeba zająć się aby użytkownik – na co dzień z krwi i kości, funkcjonujący w przestrzeni 3D – miał poczucie pewności, kierunku, bezpieczeństwa, poczucia sprawczości, kiedy korzysta z interfejsu cyfrowego.

Dla niezorientowanych, “interfejs” pochodzi od angielskiego “interface” i oznacza punkty styku – czyli sposób komunikacji – pomiędzy człowiekiem a komputerem, innym urządzeniem cyfrowym, czy usługą do której dostęp uzyskaliśmy właśnie za pośrednictwem tych urządzeń. Na przykład, Siri w telefonie jest interfejsem do obsługi telefonu i usług oferowanych przez Apple, a strona internetowa Twojego banku jest interfejsem do obsługi usług przez ów bank oferowanych.

Bardzo dużo tutaj słów, ale najprościej rzecz ujmując, moim zadaniem jest upewnić się, że przy dostępnym stanie techniki i zasobów użytkownik nie będzie niepotrzebnie się frustrował, kiedy za pomocą myszki komputera lub na ekranie urządzenia mobilnego próbuje wykonać zadanie, które (prawdopodobnie) do połowy XX wieku trzeba było wykonywać ręcznie lub z udziałem innych ludzi.

Wagę zadania możemy zaobserwować patrząc na naszych dziadków, którzy często mają trudności z dostosowaniem się do technologii, które dla młodszych pokoleń są czymś naturalnym. To właśnie sprawką (między innymi) projektanta UX będzie, że czujemy się z tym względnie komfortowo; że łatwo i szybko jesteśmy w stanie nauczyć się jak używać najnowszej aplikacji.

Na udany interfejs składa się wiele czynników począwszy od doboru słów/języka, komunikatów w nim zawartych, rozmieszczenia i rozmiaru jego elementów, doboru kolorystyki i grupowania funkcji i tym podobne. Ogólnie, użytkownik ma mieć poczucie sprawczości, konsekwencji i harmonii w tym co robi. Potrzebuje informacji zwrotnej na temat postępu i efektywności podejmowanych działań.
UX Designer “przewiduje” i rozwiązuje problemy, na które napotka użytkownik korzystając z produktu, jeszcze nim produkt zostanie zrealizowany, tym samym oszczędzając czas wszystkich zainteresowanych stron – w tym programistów, którzy mają dzięki temu o wiele mniej poprawek do zaimplementowania. Spójrzmy na to na przykładzie CodeAll.

UX x CodeAll

Projektowanie UX ma dużą wartość już na etapie koncepcyjnym projektu. Powód jest prosty. Pomiędzy narodzinami początkowej idei a momentem rozpoczęcia prac i, wreszcie, wdrożenia, pomysły i potrzeby potrafią mnożyć się w sposób niekontrolowany… Więcej, trzeba im na to pozwolić.

Funkcjonalności niezbędne dla projektu sugerują lub wymagają wręcz kolejnych funkcji aplikacji, aby produkt nadawał się do użytku. Na przykład, jeżeli możemy pisać programy komputerowe, dobrze byłoby zapisać je w pamięci urządzenia, a skoro tak to gdzieś w aplikacji musi być miejsce, gdzie będziemy mogli te programy znaleźć i skąd będziemy mogli je załadować.

Równolegle, do projektu wpływają pomysły z zewnętrznych źródeł i inspiracji. Na przykład, na rynku jest już aplikacja do nauki programowania bez chatbota albo chatbot, który nie uczy programować… Koniecznym dla dobra projektu jest zapoznać się z tymi rozwiązaniami i “podglądać”, “pożyczać”, “brać” co się da… aby wreszcie dobrać taki zestaw idei, który będzie “nic dodać, nic ująć” dla naszego produktu.

Uproszczony schemat mnożenia się i porządkowania pomysłów w procesie rozwoju produktu.

W przypadku CodeAll wśród pomysłów zapożyczonych od konkurencji, a których ostatecznie trzeba było się pozbyć lub odsunąć w czasie (przynajmniej na etapie początkowego wdrożenia) były, między innymi, ranking postępów użytkownika CodeAll w zestawieniu z innymi użytkownikami oraz menu projektów do wykonania. Choć nie wykluczamy, że pewnego dnia, niektóre z rozwiązań wrócą do CodeAll, uznaliśmy, że nie są niezbędne do tego aby aplikacja mogła pełnić swoją rolę i stanowić zamkniętą całość (podniosłyby więc niepotrzebnie koszty i odsunęły w czasie wejście na rynek). Inne mogły po prostu nie pasować do modelu biznesowego.

Wszystko czego byśmy chcieli, ale może nie od razu… a może nie tym razem:)

Jedną z ważnych czynników do uwzględnienia w CodeAll są czujniki, czyli komponent fizyczny, który ma wpływ zarówno na sposób przedstawiania treści (lekcje powinny w intuicyjny sposób poprowadzić zarówno użytkownika, który korzysta z czujników, jak i użytkownika korzystającego z CodeAll w wersji freemium – bez czujników), jak i na sam interfejs aplikacji, w którym musi znaleźć się miejsce by czujniki dodać, znaleźć, zaplanować reakcję aplikacji na podłączenie centralki (która z kolei steruje czujnikami).

Jedną z ważnych czynników do uwzględnienia w CodeAll są czujniki, czyli komponent fizyczny, który ma wpływ zarówno na formatowanie treści (powinny być atrakcyjne zarówno dla użytkowników, którzy mają dostęp, jak i dla tych, którzy nie mają dostępu do zestawu czujników CodeAll), jak i na sam interfejs aplikacji, w którym musi znaleźć się miejsce by czujniki dodać, znaleźć, zaplanować reakcję aplikacji na podłączenie centralki (która z kolei steruje czujnikami) i tym podobne.

Czujniki CodeAll

Co więcej, czujniki i związane z nimi ograniczenia, wpłynęły również na strukturę nauczanych treści i sposób funkcjonowania edytora kodu, co dobrze widać na przykładzie dwóch prostych programów, które chcemy aby użytkownik mógł napisać. Program numer jeden – nazwijmy go A – to “zmierz temperaturę”. Program numer dwa – nazwijmy go B – to “Jeżeli temperatura wzrośnie powyżej 30 stopni Celsjusza, zapal LED” (czyli światełko LED – Light Emitting Diode z języka angielskiego).

Użytkownik aplikacji powinien w miarę szybko nauczyć się jak napisać obydwa z powyższych programów, ale program B stanowi problem, ponieważ “tak naprawdę” oznacza, że chcemy aby program sprawdzał temperaturę do momentu przerwania przez nas programu, a nie w ułamku sekundy, szybko sprawdził temperaturę raz i z radością zakończył działanie. Z jednej strony w programie nauczania wcześnie musimy w związku z tym przedstawić pojęcie pętli w języku programowania. Z drugiej strony, w interfejsie musi pojawić się przycisk do przerywania zapętlonych programów. W przeciwnym wypadku program mógłby wykonywać się w nieskończoność, a użytkownik nie miałby możliwości jego przerwania.

Tak samo uruchamiamy program, ale interfejs musi dostosować się do możliwych różnic w jego zachowaniu

Ustalmy MVP, czyli Minimum Viable Product…

Mam nadzieję, że udało mi się pokazać w jaki sposób w projekcie rozmiaru CodeAll (i z pewną złożonością technologiczną) byty potrafią mnożyć się na prawo i lewo. Tym samym jest to najlepsza pora by napisać parę słów o Minimal Viable Product (MVP), czyli najmniejszej wersji produktu, która będzie nadawała się do użytku i dawała poczucie pełni (którą – rzecz jasna – będzie można potem rozwijać).

Z reguły projektant UX w takiej sytuacji – w oparciu o badanie rynku, badanie grupy docelowej użytkowników, konsultację z klientem – tworzy persony użytkowników i proponuje ścieżki ich interakcji z produktem. W jaki sposób z CodeAll używać będzie nastolatek/-tka, a w jaki osoba po 30tce, która postanowiła przebranżowić się i dowiedzieć więcej o programowaniu? W jaki sposób CodeAll może być narzędziem dla użytkownika, który użyje czujników w celach wyłącznie edukacyjnych, a co będzie niezbędne dla kogoś, kto z czujników stworzy dla siebie instalację typu Smart Home?

Tak zwane “User flows” stają się kluczem, po którym możemy zaplanować ścieżki rozwoju produktu (co jest możliwe już dziś, a co z pół roku/rok?), ale też znaleźć minimalną możliwą wersję produktu, która może być wyjściem do spełnienia kluczowych oczekiwań 95% naszej grupy docelowej użytkowników. Piszę o 95% bo z założenia nie chcemy i nie jesteśmy w stanie stworzyć kombajnu do zbierania wiśni (czegoś co miałoby służyć do robienia wszystkiego po trochu… a przez to niczego do końca).

MVP jest ważne, ponieważ pozwala opracować plan działania na najbliższe pół roku/rok/dwa lata i w realistyczny sposób oszacować koszty i ramy czasowe wypuszczenia aplikacji. Jednocześnie, dla takiego MVP możemy nareszcie zrobić prostą mapę produktu (Product Map) – instrukcję obsługi oraz określenie celu działania wszystkich zaangażowanych zespołów w postaci ilustracji. Takie 1000 słów w obrazku, na którym szybciej niż na 30 stronach dokumentów wspólnie możemy zobaczyć całokształt produktu i konteksty wszystkich ekranów, po których będziemy się przemieszczać.

Tak w pewnym momencie wyglądała mapa dla MVP CodeAll

Warto pamiętać, że jako UX Designer, pełnię na swój sposób rolę akuszerki i wszystkie to diagramy mają za cel uspójnienie i zagwarantowanie sprawnej komunikacji reszcie zespołu, tj. czym się zajmujemy, jak to wygląda i jakie są konsekwencje dla reszty projektu jeżeli wprowadzimy zmianę “o tutaj”. Moim zadaniem jest upewnić się, że w miarę możliwości wszystko widzimy czarno na białym (a czasem i w kolorze:)) .

Czas na prototyp – o makietowaniu słów kilka)…

Wiemy już jak powinien funkcjonować nasz produkt. Pora określić jego kształt możliwie “szerokim pędzlem”, czyli zacząć prototypowanie ekranów aplikacji. Aby zachować wysoki poziom ogólności rysujemy funkcje, a nie wygląd (czy “feel”) rozwiązania. Rysuje się klikalne makiety – tzw. Wireframes – które mają neutralny wygląd i pozwalają ocenić bez debaty “na temat kolorów” czy interfejs działa poprawnie.

Sieć połączeń między ekranami dla wyjątkowo złożonych klikalnych makiet, przygotowanych pod testy chatbota CodeAll.

W przypadku CodeAll makietowanie było bardzo dużym wyzwaniem, ponieważ dołączyłem do dojrzałego już produktu z dużą ilością opracowanych wizualnie materiałów – i.e. spójna prezentacja projektu była ważniejsza od prostoty makiet (testujący nie powinien rozpraszać się pytaniem czemu czasem makieta wygląda jak gotowy produkt, a czasem szkic na serwetce), oraz ponieważ makiety musiały symulować zachowanie chatbota – ładować tekst i przewijać się automatycznie.

Tak wyglądała symulacja chatbota i przewijanego ekranu…

Klikalne makiety pozwalają szukać wewnętrznych i zewnętrznych testerów, dzięki którym możemy zebrać feedback i zobaczyć co przegapiliśmy; czego możemy nauczyć się na temat starcia naszego wyobrażenia o działającym produkcie z rzeczywistością. Niekiedy robi się tak zwany “paper prototyping”. Użytkownik z grupy docelowej klika i opisuje co robi na papierze, a testujący podkłada “kolejne ekrany” w reakcji na działania testującego.

Przykład przygotowań do paper prototypingu dla jednego z moich wcześniejszych projektów.

Szczegóły, szczegóły, szczegóły… i oczekiwania użytkownika

Samo przygotowanie makiet do testów już było dla nas źródłem informacji na temat CodeAll. Szybko okazało się, że gdzieniegdzie treść scenariuszy będziemy musieli przeredagować ponieważ fragmenty lekcji wypowiadanych przez chatbota są zbyt długie (!). Kiedy rozmawiamy z drugą osobą za pośrednictwem komunikatorów “tasiemce”, które rozciągają się na całą wysokość ekranu, są trudne do przyswojenia. Podobnie, kiedy mamy do czynienia z treściami dydaktycznymi.

Mogliśmy też potwierdzić niektóre z naszych oczekiwań, na przykład, że format rozmowy jako nośnika informacji nie zwalnia nas z jednej z najstarszych prawd w edukacji: kiedy uczymy nowych pojęć czy podajemy proste przykłady programu komputerowego, korzystanie z grafik i prostych animacji pozostaje niezbędnym narzędziem.

Ściana tekstu jest “ciężka” w odbiorze w porównaniu z mniejszymi chmurkami i pytaniami/prośbami o reakcję ze strony chatbota.

Niektóre z decyzji projektowych podobnie jak przykłady powyżej zawsze będą związane z budowaniem na oczekiwaniach i przyzwyczajeniach użytkowników. Rozpoznawalne i zrozumiałe środowisko działań redukuje stres i uwalnia moce obliczeniowe mózgu pod działanie w określonym celu (mniej kombinowania “o co tu chodzi”). Po co wyważać już otwarte drzwi?

Nie wymyślajmy WSZYTKIEGO od nowa. Okna “zawsze” zamykamy klikając w narożnik.

… i przypadki, w których budujemy “od zera”

Projekt rozmiaru CodeAll to morze szczegółów do “obsłużenia”: wielowymiarowa i wielorozmiarowa ukadanka. Ponieważ to rozwiązanie unikatowe – przynajmniej jedno z pierwszych rozwiązań swojego typu – stawia też przed nami problemy, które nie mają precedensu wśród istniejących rozwiązań. Analiza rynku chatbotów, którą wykonaliśmy przy okazji Huawei Startup Challenge pokazała jasno, że wśród konkurencji mamy rozwiązania do nauki programowania, które nie są oparte o chatboty… oraz chatboty o zastosowaniach innych niż edukacyjne.

Co w trawie piszczy na rynku chatbotów.

Brak bezpośredniej konkurencji nie powstrzymał nas przed staraniami by nauczyć się z cudzych rozwiązań wszystkiego co się da. Zwróciliśmy uwagę na chatbota terapeutycznego – WYSA, który obraliśmy za benchmark (wzorzec) płynności rozmowy z chatbotem i właśnie w ramach Huawei Startup Challenge wykonaliśmy serię analiz sposobu, w który prowadził rozmowę. Zestawiliśmy je z User Flow, którego będzie wymagało prowadzenie rozmowy przerywanej pisaniem krótkich zadań – programów, które CodeAll będzie analizował i w oparciu o nie udzielał dalszych instrukcji.

U góry rozmowa z WYSA. Na dole strony rozmowa/nauka z CodeAll.

Szczegóły interakcji z CodeAll będą miały kluczowe znaczenie dla sukcesu produktu. Poczucie swobody, komfortu rozmowy, sprawczości mają szansę pojawić się, gdy użytkownik nie będzie rozpraszał się niepotrzebnymi detalami. Nadal wypracowujemy kolejne warianty interakcji z chatbotem i podejmujemy decyzje projektowe z uwzględnieniem ich konsekwencji.

W “Opcja B” testujemy User Flow aplikacji, jeżeli programowanie mogłoby odbywać się w kontekście ekranu rozmowy z chatbotem.

Na powyższej ilustracji widzimy dwie opcje wykonywania krótkich zadań programistycznych w trakcie rozmowy z chatbotem, które dobrze ilustrują rolę UX Designera w procesie projektowym.W Opcji A zawsze kiedy mamy program do napisania opuszczamy ekran rozmowy. W takim przypadku ikona chatu wewnątrz edytora przyjmuje rolę podpowiedzi na czym polegać ma zadanie do wykonania (tj. nie muszę opuścić kontekstu edytora, aby upewnić się, że o wszystkim pamiętam). Implementacja tego rozwiązania zajmie określoną ilość roboczogodzin. W Opcji B mogę “przescrollować” ponad edytor kodu i przeczytać całość wcześniejszej rozmowy po czym wrócić do układania programu. W tym przypadku kliknięcie na ikonkę chatu zamknie edytor i sprowokuje chatbota do zadania mi pytania czy wszystko zrozumiałem, bo przerwałem zadanie nie pisząc ani linijki. Ta opcja również wiąże się z określonymi ograniczeniami technicznymi i kosztowymi.

Ze stosownie przygotowaną dokumentacją jesteśmy w stanie skutecznie omówić o czym konkretnie rozmawiamy, jakie zespół deweloperski widzi tu wyzwania i wreszcie w jaki sposób te rozwiązania odnoszą się do szerszej wizji produktu. Czy zależy nam na tym aby użytkownik szybko oswoił się ze spędzaniem czasu w kontekście edytora? Jak te dwa warianty mogą wpłynąć na jakość komunikacji z chatbotem? Wogóle Mateusz chciał, abym napisał też parę słów o samych chatbotach, więc może teraz Wam o nich opowiem. W sumie, zacząłem pisać z intencją, by opowiedzieć również parę słów o samych chatbotach, więc może teraz Wam o nich opowiem.

Tentative ending…

Więcej o chatbotach

Chatboty nikogo już chyba nie dziwią i wszyscy możemy zgodzić się, że na przestrzeni ostatnich lat bardzo wyraźnie dało się odczuć postępy w tej technologii. Miarą postępu jest iluzja prawdziwej osoby “po drugiej stronie” (mierzona prędkością, z którą orientujemy się, że to tylko chatbot) oraz skuteczność komunikacji. Miarą tej ostatniej jest czy w skutek interakcji uda mi się uzyskać pożądane informacje/zamierzony efekt.

Królująca do tej pory technologią są chatboty oparte na tak zwanych intentach. To technologia gromadzenia możliwych odpowiedzi pasujących do pytań użytkownika w danym kontekście, czyli z uwzględnieniem informacji, że na przykład, do tej pory rozmawialiśmy o pogodzie. Uzbrojony w informację, że kontekstem rozmowy jest pogoda i zapytany “Jak będzie jutro?” chatbot zerknie na listę odpowiedzi i zobaczy czy są jakieś otagowane (oznaczone kategorią) “pogoda”. Z nich być może wybierze “Kto wie? Mam nadzieję, że nie będzie padać”. W innym kontekście powiedziałby być może “Jutro będzie futro”. Przykładowy schemat działanie ilustruję poniżej:

Tak “myśli chatbot” intencyjny.

Dobrze zaprojektowany system intentów decyduje o sukcesie chatbota. Łatwo można wyobrazić sobie błędy, które doprowadzą do szybkiej realizacji użytkownika, że chatbot umie powiedzieć tylko “trzy zdania na krzyż”. Równie łatwo można wyobrazić sobie jak wiele pracy kosztuje zaplanowanie i przygotowanie intentów, które sprawią, że konwersacja będzie “płynąć”. Tu, jako benchmark gorąco polecam wypróbowanie WYSA wspomnianej wcześniej w tym poście.

Przebieg przykładowej konwersacji z WYSA.

Chatboty przyszłości, czyli czym jest GPT-3?

CodeAll proponuje nową formę edukacji poprzez chatbota jako wątek dodatkowy dla dotychczasowych sposobów zdobywania wiedzy – inspirację, alternatywne źródło, uzupełnienie dla informacji, które wynosimy i będziemy wynosić ze szkoły… Po części motywacją naszą jest, że w horyzoncie czasowym pięciu do dziesięciu lat będzie to dla nas wszystkich rozwiązaniem oczywistym… tak jak nikogo nie dziwi już, że sztuczna inteligencja może pokonać człowieka w szachach (począwszy od Deep Blue w 1997 roku) i w go (Alpha Go w 2017).

Kasparov vs Deep Blue (źródło)

Choć chatboty intencyjne przy odpowiednim nakładzie energii już potrafią skutecznie stworzyć iluzję, na przykład, zespołu wsparcia technicznego, to już widzimy jak nowe technologie – oparte o nauczanie maszynowe (z angielskiego Machine Learning) – doprowadzą jakość komunikacji ze sztuczną inteligencją (AI) do poziomu, na którym nie korzystanie z chatbotów będzie próba bezskutecznej walki z duchem czasu (tak jak wolimy wybrać się w godzinną podróż samolotem, niż dwutygodniową eskapadę dorożką).

Pierwszą jaskółką jest GPT-3, czyli Generative Pre-trained Transformer 3: model sztucznej inteligencji OpenAi (firmy Elona Muska), służący do automatycznego tworzenia treści w oparciu o sieć neuronową, która na dobrą sprawę została “nakarmiona” internetem. To nie będzie post o sposobie funkcjonowania sieci neuronowych, ale dosyć powiedzieć, że rezultatem treningu sieci jest przewidywanie co wypadałoby teraz dopisać. Trochę tak jak każde z nas, w oparciu o zestaw parametrów (np. “Piszę list do znajomej mi osoby na temat…”) model dobiera następne najlepiej pasujące słowo do już skreślonych i tak krok po kroku powstaje gotowy tekst, którego nierzadko nie sposób już odróżnić od treści stworzonej przez człowieka.

Choć w tej chwili operujemy jeszcze – jak większość rynku – na chatbotach intencyjnych, wkrótce będziemy mogli zacząć budować własny silnik w oparciu o sztuczną inteligencję i GPT-3 dowodzi, że jest o co walczyć; już w tej chwili sprawnie buduje automatycznie proste strony internetowe, pisze kod, wiersze, posty na bloga, itp. Inni tech-giganci też nie pozostają bierni i rozwijają własne chatboty, na przykład Google LaMDA. Wraz z rozwojem rynku jakość produktów opartych o chatboty będzie tylko rosła, a poczucie prawdziwej rozmowy będzie łatwiejsze do uzyskania. To kluczowe dla sukcesu CodeAll, ale też dowód na to, że idziemy z duchem czasu, jednocześnie starając się zaoferować użytkownikom po prostu dobrze zredagowaną wiedzę i poczucie sprawczości oraz zrozumienia technologii wokół nas.

Jesteśmy na pograniczu technologicznych możliwości, aby dostosować poziom wiedzy oraz sam dobór słów do potrzeb użytkownika. Wkrótce będziemy w stanie sprawić, aby rozmowa z chatbotem była zabawą i przyjemnością… a budując dalej na rozwiązaniu CodeAll uzupełniać i czynić dostępną dla szerszej społeczności wiedzę również z innych dyscyplin niż programowanie… i w każdym żywym (i martwym?) języku na Ziemi. Takie czasy:). Przy odrobinie szczęścia już niedługo czytelnik sam będzie mógł ocenić na ile proponowany przez CodeAll model pracy spełnia ich oczekiwania.