UX: Tworzenie nowego modelu

0:00A kiedy już zrobiliśmy sobie ten cały research, pogadaliśmy z naszymi użytkownikami

0:04i rozłożyliśmy wszystko na najmniejsze części, czas przejść do faktycznej

0:08budowy nowego modelu. No i teraz na to, na co

0:13chciałabym zwrócić uwagę to to, że nie zawsze musimy

0:17budować cały model architektury informacji zupełnie od nowa. Może okazać

0:21się bowiem, że tak naprawdę kłopotliwa jest tylko część etykiet, które

0:25znajdują się w nawigacji głównej, a wszystko to, co znajduje się w środku, jest jak najbardziej okej. I

0:29na testach z użytkownikami w przypadku card sortingu

0:33mogło wyjść na przykład, że faktycznie jest jakiś jeden obszar, który tylko

0:38trzeba poprawić. Wtedy zamiast budować nowy model, po prostu zajmujemy się tą

0:42kłopotliwą częścią. Ale w przypadku kiedy nie mamy nic wcześniej,

0:46to znaczy nie robimy rebrandingu, a tworzymy nowy produkt, siłą rzeczy będziemy musieli

0:50stworzyć nowy model. Czeka nas ta praca niestety albo i stety, więc

0:54musimy się też na to odpowiednio przygotować. Na pewno warto pod ręką mieć

0:59te wszystkie inspiracje, benchmarki, rozwiązania konkurencyjne,

1:03które zbieraliśmy wcześniej. Na pewno warto mieć pod ręką wnioski

1:07z badań i warsztatów, które przeprowadziliśmy z użytkownikami. I warto

1:11zaczynać naszą pracę od tej struktury, którą już wcześniej mieliśmy przygotowaną w przypadku

1:15rebrandingu. Jeżeli nie mamy tej struktury wcześniejszej, to

1:19możemy bazować jak najbardziej na strukturach rozwiązań konkurencyjnych.

1:24No i teraz znowu trzeba zastanowić się, w jaki sposób będziemy pracować

1:28nad architekturą informacji, bo nie zawsze jest tak, że będziemy tworzyć ten rozbudowany

1:33model. Czasami będzie on bardzo krótki i bardzo prosty, i wtedy nie

1:37potrzebujemy specjalnych narzędzi, nie potrzebujemy żadnej aplikacji czy specjalnego

1:43programu, w którym tę strukturę będziemy budować, bo w zupełności wystarczy nam kartka

1:48i ołówek. I możemy sobie to szybko nakreślić i na

1:52tym pracować dalej - przejść do prototypowania, przejść do projektów interfejsu. Ale

1:57jeżeli nie pracujemy samodzielnie, jeżeli mamy zespół, z którym musimy podjąć

2:01wspólnie jakieś decyzje, kiedy mamy klienta, który również musi zaakceptować jakieś

2:06decyzje projektowe, niestety zawsze gdzieś ten klient nad

2:10nami jest i dużo bywa, że jest od niego zależnych. Są

2:15jacyś deweloperzy, z którymi musimy przegadać na przykład tematy wspomnianej

2:19wyszukiwarki. Więc im więcej osób jest zaangażowanych

2:23w projekt, im więcej osób z nami będzie nad tym rozwiązaniem

2:27pracowało, tym większa szansa jest, że prędzej czy później będziemy musieli przestawić

2:32się na narzędzia digitalowe, na rozwiązania cyfrowe i wybrać

2:36jakąś aplikację, w której będziemy pracować. Ja bardzo często ostatnio korzystam

2:40z RealtimeBoarda. Mimo że jest dużo więcej mądrzejszych

2:45i specjalistycznych narzędzi do projektowania architektury informacji, akurat RealtimeBoard

2:51jest tym narzędziem, z którego korzystam najczęściej, bo mogę wrzucać tam zarówno

2:55inspiracje, mogę wrzucać tam te analizy z wędrówek poznawczych,

2:59ale z jakiś audytów, które, które robię na stronach

3:03konkurencyjnych. I tak naprawdę wszystko mam pod ręką, wszystko mam w jednym miejscu. Co

3:08więcej w każdej chwili mogę udostępnić takiego boarda drugiej

3:12osobie, innemu projektantowi, który już w międzyczasie może pracować nad jakimiś innymi obszarami

3:16albo klientowi, który może sobie zerknąć i zobaczyć, jak idą

3:20kolejne prace. Więc to, jakie narzędzie wybierzecie,

3:24z jakiego narzędzia będziecie korzystać, tak naprawdę zależy od was. Warto

3:29poznać ich kilka, nie ograniczać się do jednego, bo może okazać się, że przy jednym projekcie będzie

3:33bardziej potrzebny na przykład Draw.io, a przy drugim

3:37będziecie wszystko robić w Axurze, bo takie są założenia projektu, takie

3:42są ograniczenia firmy, dla której będziecie musieli pracować. Więc w przypadku projektowania

3:46w ogóle, nie tylko architektury informacji, ale prototypowania czy projektowania UI,

3:51raczej dobrze jest znać kilka narzędzi i z łatwością się między nimi

3:55przepinać niż przywiązywać się do tylko jednego rozwiązania, ponieważ bywa

4:00i tak, że te rozwiązania przestają być wspierane, że potem ktoś z tych rozwiązań nie

4:04może korzystać, że również mają jakieś swoje ograniczenia. Warto

4:11jeszcze pamiętać o jednej rzeczy: jeżeli zajmujemy się redesignem jakiejś struktury, jeżeli

4:15poprawiamy jakieś obszary z obecnej

4:19strony internetowej albo z aplikacji mobilnej, bardzo ważne

4:23jest, żeby zaznaczać, które rzeczy tak naprawdę zmieniliśmy. Zwłaszcza jeżeli są to drobne

4:28korekty aktualnej struktury. Jeżeli nie robiliśmy wszystkiego od nowa. Takie

4:33zaznaczanie elementów, które zmienialiśmy na przykład przez inny

4:37kolor etykiety czy oznaczenie jakąś kropką, czy jakąś inną

4:41strzałką, obramowaniem (to jest zupełnie dowolne, po prostu w jakiś

4:45sposób wyróżnić te elementy, które poprawiliśmy), to pozwoli

4:49nam na szybszą i łatwiejszą komunikację w zespole. Jeżeli

4:54przekażemy taką poprawioną strukturę klientowi, deweloperom czy innym

4:58projektantom, to oni dużo łatwiej będą mogli się odnaleźć w w takim

5:02systemie oznaczenia treści, będą wiedzieć, co mają ze sobą porównywać,

5:06zamiast przechodzić przez całe rozbudowane grafy. Te drzewka potrafią

5:10być naprawdę bardzo duże, więc nie zawsze wszystkim się będzie chciało i jest ryzyko,

5:14że wyślemy komuś taką strukturę do sprawdzenia, żeby sobie na to zerknął, przejrzy

5:19to pobieżnie i ostatecznie skończy się, że na etapie jakiegoś prototypowania wyjdzie,

5:23że gdzieś tam jednak pojawiły się błędy, jakieś niedomówienia, coś będzie trzeba

5:27poprawić. Więc zwracajcie na to uwagę. W kwestii narzędzi, tak

5:32jak wspominałam, albo kartka papieru, albo sticky notes, ołówek, marker. To

5:37może być flipchart, to może być jakiś papier, który jest przyklejony do

5:41ściany, to może być tablica, ale to mogą być zarówno narzędzia cyfrowe. To,

5:46jakie narzędzia wybierzemy, powinno być podyktowane nie tylko naszymi jakimiś,

5:51naszym widzimisię i tym, co nam się podoba bardziej lub mniej. Raczej

5:56starajmy się dopasowywać narzędzia również do projektu, nad którym pracujemy. Jeżeli pracujemy

6:00samodzielnie, robimy co chcemy, tak naprawdę dobieramy narzędzie do siebie. Jeżeli pracujemy

6:04w zespole, niech to będzie decyzja wspólna dla zespołu, niech ten zespół zaakceptuje

6:08narzędzia, które wybieramy, ponieważ w dalszym etapie przekazujemy

6:13te projekty dalej, przekazujemy wiedzę prototypowania,

6:17przekazujemy je projektantom UI. No i fajnie by było, żeby te struktury

6:22w jakiś sposób mogli łatwy otworzyć, żeby mogli sobie łatwo na

6:26tym pracować, powiększać, zwijać niepotrzebne informacje. Więc

6:31dobrze jest się dogadać między sobą, żeby później nie wychodziły

6:35jakieś problemy, żeby nie okazało się, że trzeba eksportować na różne sposoby, że trzeba zmieniać

6:39nagle narzędzie. Takie decyzje warto podejmować na samym początku, kiedy

6:43zaczynamy współpracę z innymi osobami. I okej, to by było

6:47na tyle, jeżeli chodzi o metody pracy. Teraz przejdziemy do kolejnych lekcji,

6:51w których będę opowiadać o weryfikowaniu naszych projektów i o tym, jak

6:55sprawdzić, czy podjęliśmy dobre decyzje projektowe.