UX: Analiza danych

0:00Kolejną metodą na weryfikację tego, czy zrobiliśmy dobrą robotę,

0:04jest analiza ruchu. Takie narzędzie jak Google Analytics, jak Hotjar

0:08pozwalają nam na sprawdzenie ścieżek użytkowników. Możemy

0:12sprawdzić, gdzie wchodzą, na jakie strony wchodzą nasi użytkownicy, jakie

0:18informacje wyszukują, żeby wejść na tę stronę, jakich informacji wyszukują

0:22w ogóle w ramach serwisu. Więc możemy sprawdzić, które informacje są

0:26najczęściej wyszukiwane, których być może nie widać w nawigacji i zamiast

0:31użytkownik klikać, po prostu wpisuje do wyszukiwarki daną frazę. Może

0:35wtedy trzeba coś zmienić w strukturze. Może trzeba coś tam jednak poprawić. Może te nazwy

0:39nie są zbyt intuicyjne. Takie informacje możemy wyśledzić również, właśnie

0:44wykorzystując takie narzędzia do analityki. To, co jest

0:48jednak ważne w tych narzędziach, to to, że muszą być podpięte, żeby zbierać dane. Więc

0:52jeżeli pracujemy nad nowym projektem, jeżeli dopiero będziemy zbierać te

0:56dane, to warto zadbać o to, żeby klient

1:00wiedział, żeby deweloperzy wiedzieli, że takie narzędzia trzeba podpiąć na samym

1:04początku, bo za jakiś czas, kiedy będziemy chcieli sprawdzić, kiedy

1:09będziemy chcieli coś poprawić, możemy również wykorzystać te narzędzia analityczne

1:13w naszej pracy. I poza takimi jakościowymi testami jak testy cardsortingowe

1:18czy wywiady, czy i testy z użytkownikami, możemy również wykorzystywać

1:23wtedy takie metody ilościowe i sprawdzać te dane zastane,

1:28które zbierają się gdzieś tam z tyłu naszej strony czy aplikacji. To,

1:33co jest najważniejsze w tym wszystkim, to tak naprawdę iteracyjny charakter prac

1:37nad architekturą informacji. Trzeba pamiętać o tym, że to nie jest tak,

1:41że my sobie zbudujemy strukturę i zamykamy program, kończymy naszą pracę,

1:45oddajemy tę strukturę dalej do projektantów i w ogóle zapominamy o projekcie, nie ma

1:49nas w tym. Fajnie by było jednak uczestniczyć w pracach związanych z prototypowaniem. Fajnie

1:54uczestniczyć w pracach związanych z testowaniem i cały

1:58czas poprawiać tą architekturę, cały czas szukać tych rzeczy, które można poprawić,

2:02cały czas zastanawiać się nad tym, czy są jeszcze w ogóle pola

2:07do poprawy. Po prostu sprawdzajmy możliwie często, jak ten nasz projekt

2:11przekłada się na oczekiwania użytkowników. I oczywiście

2:15mówiłam o weryfikowaniu, mówiłam o testowaniu... Być może jako projektanci nie

2:19czujecie się najlepiej jako badacze, jako obserwatorzy. Może nie

2:23chcecie organizować sami testów. Nie bójcie się prosić o pomoc innych

2:28badaczy researcherów czy analityków. Wy nie musicie robić tego wszystkiego samodzielnie. To

2:33jest praca, którą można podzielić na kilka osób, możecie pracować w zespole i to

2:37oni mogą dostarczać wam tych informacji, których potrzebujecie. Badacz może

2:41przebadać użytkownika i znaleźć luki w rozwiązaniu konkurencyjnym. I

2:46zarekomendować pewne działania, aby potem w rozmowie z tym badaczem, w

2:51oparciu o te wnioski z card sortingu, z badań

2:55z użytkownikami czy z analizy ruchu możecie wypracować jakieś swoje rozwiązania. I

3:00potem również skonsultować się z tymi analitykami i z tymi badaczami. Więc

3:04pamiętajcie o tym, że proces pracy nad projektem strony, nad

3:08projektem serwisu, im większego, tym to jest ważniejsze, to

3:12jest praca wspólna, praca kilku osób, to jest zespół. Więc

3:18mówmy o tym, czego potrzebujemy, jakich informacji potrzebujemy, żeby te rozwiązania

3:22były lepsze, a na pewno to będzie prowadziło do tego, że

3:26te produkty będą mądrzejsze i lepsze dla naszych użytkowników. Teraz

3:31przejdziemy do krótkiego podsumowania. Opowiem wam o tym. co

3:37na nas czyha jako projektantów, jako architektów informacji i o czym warto

3:41pamiętać, kiedy pracujemy nad architekturą informacji.