UX: Mapowanie ścieżek

0:00Kolejnymi ćwiczeniami czy zadaniami, które możemy wykonywać

0:04w trakcie warsztatów, jest mapowanie ścieżek, mapowanie doświadczeń

0:08użytkownika. Takie pojęcia jak customer journey map czy user

0:16journey map to pojęcia, z którymi możecie się spotkać lub

0:20już spotkaliście się w jakiejś literaturze związanej z UX. I

0:24jest to bardzo popularny sposób na to, żeby sprawdzić,

0:29w jaki sposób użytkownicy poruszają się po produktach i

0:33usługach, w jakiej kolejności wykonują jakieś zadania. I w zależności

0:37od typu mapowania i sposobu zapisu, który

0:42stosujemy, będziemy też zahaczać o kwestie takie jak pozytywne i

0:46negatywne emocje, problemy, z którymi się spotykamy, lub wręcz przeciwnie - będziemy

0:50podchodzić do tego bardzo technicznie i będziemy zastanawiać się tylko, w jaki sposób

0:54działa system i jak reaguje na działania użytkownika. Modelowanie

0:58ścieżek, mapowanie ścieżek możemy zrobić oczywiście

1:02na różne sposoby. W idealnym świecie mamy wyniki badań,

1:07wiemy, w jaki sposób użytkownicy się poruszają, wiemy dlaczego, w jakim kontekście

1:11pojawiają się problemy, jak na nie reagują i co im się podoba lub co im

1:15się nie podoba. Ale bardzo często też tych badań

1:19i feedbacku od użytkownika mieć nie będziemy. I wtedy możemy

1:23zastanowić się nad tym, w jaki sposób zamodelować

1:27te ścieżki, żeby faktycznie uzyskać jak najwięcej rzetelnych informacji. Jak

1:32do tego podejść, jak sprawić, żeby faktycznie to był jakiś punkt wyjścia

1:37do dalszych prac? Możemy mapować idealne ścieżki użytkownika, czyli takie,

1:41jakie sobie wymarzymy, jakie chcielibyśmy, żeby ci użytkownicy przechodzili,

1:45żeby z sukcesem i zadowoleniem realizowali

1:50jakieś zadania w danym procesie. Możemy mapować

1:54ścieżki, które są aktualne. To znaczy na podstawie rozmów i analityki

1:58jesteśmy w stanie zrozumieć, dlaczego użytkownicy

2:03zaczynają od tego momentu i kończą w tym, co się dzieje przed

2:07tym, jak użytkownik siądzie do naszego systemu i co się dzieje po tym, jak już z tego

2:11systemu skończył korzystać. Więc

2:15takich sposobów na to, w jaki sposób wizualizować te ścieżki jest

2:20bardzo dużo. Natomiast jest to świetne zadanie do realizacji właśnie

2:24z klientem, bo nie jesteśmy w stanie zrobić tego sami, nie będziemy mieć

2:28pewnych informacji, które klient będzie miał. Być może proces

2:32czy te ścieżki wyglądają w ten sposób z takiego powodu, bo

2:37są jakieś ograniczenia techniczne, o których nie wiemy, bo są jakieś ograniczenia prawne, o których

2:41możemy nie wiedzieć. I mając klienta w jednym miejscu, mając

2:46potencjalnych użytkowników czasami w jednym miejscu razem z klientem, możemy przejść

2:50przez takie modele ścieżek i zastanowić się, co jest

2:54dobre, co jest złe, co możemy poprawić, na co mamy wpływ i po

2:58prostu mieć ten punkt wyjścia do dalszej pracy. Jeżeli

3:02zaczynamy z nowym produktem, jeżeli wymyślamy jakąś nową aplikację, to

3:07warto zacząć sobie pracować na takich ścieżkach, żeby zrozumieć, co

3:11tak naprawdę będziemy mieć w dalszych krokach do zaprojektowania. Musimy

3:16zastanowić się, jakie procesy będzie miał do przejścia użytkownik - dajmy na to rejestrację

3:20w serwisie. Jeżeli będziemy użytkownikami, którzy będą korzystać z systemu rezerwacji

3:25hoteli, to żeby przejść przez taką rejestrację, będziemy

3:30musieli wypełnić jakieś informacje. I będą tam

3:34informacje niezbędne dla naszego klienta, żeby móc w

3:38ogóle taki booking zorganizować w hotelu. To

3:43musi być pewnie imię i nazwisko, być może jakiś numer PESEL albo

3:47numer dowodu, albo musi być potwierdzona tożsamość, albo można

3:51zrobić od razu płatność, która będzie potwierdzeniem tej

3:57rezerwacji. Więc można to zrobić na kilka bardzo różnych sposobów. I

4:01razem z klientem możecie zastanowić się wtedy na takim warsztacie, w jaki sposób

4:06dostosować tą ścieżkę, żeby dla tego użytkownika to było szybkie, żeby

4:10było łatwe, żeby było lepsze i fajniejsze niż to, co

4:14zrobiła konkurencja. Więc to jest świetne zadanie do tego, żeby usiąść

4:19z dużymi kartkami papieru, z całą masą karteczek

4:23samoprzylepnych i mazakami i spróbować rozpisać sobie te

4:27procesy na takie poszczególne ścieżki. Co się stanie, jeżeli użytkownik

4:31jest już zarejestrowany i chce zabukować hotel? Co

4:35się stanie, kiedy dopiero ta rejestracja będzie przed nim? Co się

4:39stanie w momencie, gdy na przykład pojawi się jakiś

4:43problem, który jest niezależny od nas? W jaki sposób będziemy te problemy komunikować?

4:47Co się stanie, jeżeli hotel przeliczył się z ilością rezerwacji

4:51i nagle się okazuje, że tej rezerwacji już nie ma? W jaki sposób informujemy o tym naszego

4:56użytkownika? Więc przechodzimy sobie przez takie różne ścieżki, rozklejając

5:02kolejne kartki, na których zapisujemy zadania, które użytkownik

5:06wykonuje. To może być na przykład: wchodzi na stronę

5:10internetową, na stronę główną, potem wchodzi na stronę logowania,

5:14uzupełnia adres e-mail i hasło, potem przechodzi do

5:18zakładki "moje rezerwacje", robi coś innego, robi coś innego i tak dalej,

5:23i tak dalej. Oprócz rozpisywania tych punktów oczywiście możemy stosować szkice. Jeżeli

5:28szybciej i łatwiej nam się szkicuje, to możemy w formie takich ekranów, takich wireflows,

5:32spróbować zamakietować ten proces, zwizualizować

5:37ten proces. Więc tutaj narzędzi macie naprawdę szeroki wybór

5:41i możecie je dostosować do swoich potrzeb. Możecie

5:46też skorzystać z gotowych szablonów. Są gotowe kanwy, które

5:50możecie w dużym formacie wydrukować, one są dostępne za darmo w internecie. Więc

5:55zachęcam was do tego, żeby również z takich materiałów korzystać, bo one po prostu przyspieszają i ułatwiają

6:00naszą pracę. W momencie kiedy będziemy

6:04zajmować się mapowaniem ścieżek, możemy spotkać się z takim pojęciem jak

6:08use case, czyli przypadki użycia. I modelowanie za

6:13pomocą przypadków użycia jest dość charakterystyczne w

6:17pracach związanych nad systemem, nad zastanawianiem się, w jaki

6:21sposób powinien działać system. Bardzo często osoby bardziej

6:25techniczne będą korzystały z tych przypadków użycia, ale warto wiedzieć, że

6:29coś takiego istnieje, możecie się z tym spotkać. Możecie spotkać się z diagramami UML,

6:34czyli diagramami, które po prostu pokazują konkretne ścieżki. Co się stanie,

6:38jeżeli użytkownikowi się uda? Co się stanie, jeżeli się nie uda? Jak reaguje

6:43system na to, co użytkownik zrobi? Czyli jeżeli wpisał użytkownik

6:47imię i wpisał jakieś hasło, i kliknął "zaloguj

6:53się", to system w tym momencie musi sprawdzić, czy hasło jest

6:57poprawne i login jest poprawny, i może albo przekierować do następnej strony, albo

7:01w przypadku gdy pojawił się błąd, pokazać komunikat błędu i użytkownik

7:06w tym momencie jeszcze raz będzie musiał wpisać swoje dane. Więc możemy spotkać się z

7:10takimi przypadkami użycia, które będą rozpisane w formie

7:14słownej, mogą pojawić się w formie diagramów. Nie ma się co bać. To

7:18czasami wygląda dość przerażająco, zwłaszcza jeżeli te diagramy są mocno

7:22rozbudowane, ale spokojnie przejrzyjcie, na czym to polega. Zobaczycie, że to

7:26do odczytania jest dosyć proste i to jest nic innego jak przedstawienie

7:30kolejnych działań systemu, reakcji systemu na działania użytkownika. Więc

7:35może wam się to przydać. Niekoniecznie zawsze będziecie się z tym spotykać, ale jeżeli

7:39już się spotkacie, to będziecie wiedzieć, o co w tym wszystkim chodzi. Za

7:43to w przypadku mapowania doświadczeń, kiedy mówimy bardziej o kwestiach związanych z user

7:47experience, z tym, w jaki sposób użytkownik reaguje, jak

7:52się z tym czuje, czy są jakieś kwestie związane z właśnie

7:56z emocjami. Będziemy bardziej wchodzić w tematy

8:01związane z celami użytkowników, z tym,

8:05jakie mają potrzeby, dlaczego wykonują dane działania i

8:09co za pośrednictwem tych działań chcą osiągnąć. Więc w przypadku mapowania

8:14doświadczeń możecie spotkać się z pojęciem user stories. I

8:18wtedy mówimy o historyjkach, o storyjkach użytkownika. Jest to bardzo charakterystyczny

8:23sposób zapisu funkcji systemu, z

8:28którym spotkacie się, pracując w metodykach zwinnych, zwłaszcza w

8:33scrumie. Więc jeżeli dostaniecie dokumentację

8:37takiego projektu scrumowego, dostęp do jakiejś Jiry, Confluence'a, to

8:41możecie spotkać z zapisem, w którym wyciągnięte

8:45są, oprócz opisu tego, jak działa dana funkcja, pewne storyjki user stories,

8:51które opisują, że jako administrator

8:55systemu chcę dodać nowego

8:59użytkownika, aby dać

9:03dostęp nowemu pracownikowi do naszego systemu. I ten

9:07zapis jako kto, chcę, potrzeba, aby

9:12osiągnąć jakiś cel jest bardzo charakterystyczny właśnie dla storyjek

9:16użytkownika i jeżeli zobaczycie coś zapisanego w tej formie, no

9:20to możecie się spodziewać, że właśnie chodzi o to, żeby przedstawić w formie

9:25takiej storyjki jakąś funkcję, jakąś potrzebę użytkownika,

9:29którą później możemy przekuć na funkcje. I takie storyjki użytkownika,

9:33one mogą mieć bardzo różny poziom szczegółowości, one mogą być bardzo ogólne,

9:37opisywać bardzo ogólne i takie wysokiego

9:41poziomu cele i potrzeby, a z drugiej strony mogą być

9:46bardzo szczegółowe i opisywać już działanie trochę systemu i tego, w jaki sposób wybiera

9:51użytkownik narzędzia czy proces w ogóle - jak

9:55to wszystko wygląda. Więc tutaj poziom szczegółowości może być bardzo różny. To nie jest

9:59błąd, że pojawiają się storyjki o różnym poziomie szczegółowości, więc nawet jeżeli

10:04będziecie je w przyszłości tworzyć, to też zobaczycie, że ten

10:08rozstrzał w detalach związanych z samymi funkcjami potrafi być bardzo

10:12różny. I takie storyjki mogą oczywiście znaleźć się w jakiejkolwiek

10:17dokumentacji, w dokumencie, który zostanie wygenerowany pod

10:21postacią tych kilkudziesięciu czy kilkuset stron. To może

10:25być jakaś tabelka, w której zawarte są te informacje. Bardzo łatwo

10:29stworzyć też takie storyjki w arkuszach kalkulacyjnych w jakimś Excelu,

10:34więc narzędzie tak naprawdę nie jest istotne. Bardziej istotne jest to,

10:38co w tej storyjce się znajduje, a zwłaszcza jaki jest cel, jaka

10:42jest potrzeba użytkownika. Bo potem te storyjki będziemy przekuwać już

10:46na konkretne funkcje naszego systemu.