UX: Kilka zasad na koniec
w Praktyce
7 godz. 35 min · User Experience · UI, UX i Webdesign
Natalia BieniasHead of Design w Mobee DickCzego się nauczysz
- Narzędzia, które pomogą zbierać wymagania do projektu
- Organizacja i prowadzenie skutecznego spotkania
- Metody warsztatowe, które łatwo wprowadzić do codziennej pracy
- Tworzenie modeli architektury informacji, np. do strony www
- Różnice i zastosowania różnych modeli nawigacji na stronach
- Wybór najlepszego rodzaju prototypu do typu projektu
- I wiele, wiele więcej!
Cały kurs został podzielony na trzy główne części: zbieranie wymagań, architekturę informacji oraz prototypowanie. Czasami jako projektanci będziemy zajmować się w pracy każda z nich, a czasami będziemy odpowiedzialni za wszystkie. Niezależnie od tego, czym ostatecznie będziemy się zajmować, warto znać i rozumieć pozostałe etapy, aby sprawniej współpracować z innymi członkami zespołu projektowego.
Zbieranie wymagań, czyli praca z klientem
To, czego nie uczą z reguły podręczniki to praca z klientem i rozwijanie tak zwanych kompetencji miękkich. W części poświęconej zbieraniu wymagań poznasz metody i narzędzia, które pomogą Ci we współpracy z innymi ludźmi. Dowiesz się min. jak i po co stworzyć brief, jak zorganizować i poprowadzić spotkanie lub warsztat kreatywny, a także jak uporządkować sobie zdobyta wiedze, by wykorzystać ja dalej.
Architektura informacji, czyli porządkujemy treści
W pracy projektowej albo tworzymy struktury architektury informacji lub na takich strukturach, przygotowanych przez architektów informacji pracujemy. Niezależnie od tego, w która stronę pójdziemy, będziemy mieć do czynienia na co dzień z projektowaniem treści. W kursie dowiesz się w jaki sposób porządkujemy treści na stronach, jakie są popularne modele nawigacji i w jaki sposób weryfikować, czy stworzone przez nas modele są zrozumiale dla użytkowników.
Jak wybrać rodzaj prototypu?
Etap prototypowania jest jednym z najbardziej charakterystycznych, do tego stopnia, ze często myli się go z samym projektowaniem UX. Dowiesz się jak wygląda proces powstawania prototypu i jak dobrać najlepszy jego rodzaj do typu projektu, który realizujesz. Nie zawsze bowiem będą potrzebne prototypy o wysokim stopniu szczegółowości i dużej interaktywności!
Dlaczego wybrać właśnie ten kurs?
- Kurs wideo to najbardziej efektywna a zarazem najprzyjemniejsza forma nauki. Jest on tak prowadzony, byś cały czas mógł go śledzić z zainteresowaniem i zaangażowaniem, a także czerpać satysfakcje ze zdobytej wiedzy!
- Wiedza, która otrzymujesz w tym kursie, to nie tylko sucha teoria, ale równiez wskazówki od praktyka z wieloletnim doświadczeniem, dzięki którym dużo łatwiej będzie Ci opanować materiał.
- Uczysz sie na praktycznych przykładach. Kurs, który masz przed sobą to esencja praktycznej wiedzy i doświadczenia a także wzorów, które oszczędzą Ci godziny pracy i poszukiwań.
Dla kogo jest ten kurs?
Z tego kursu skorzystają przede wszystkim osoby, które zaczynają prace zawodowa w obszarze projektowania UX lub chcą się przebranżowić z innych specjalizacji. Jeżeli jesteś osoba zupełnie zielona w temacie projektowania User Experience, sięgnij w pierwszej kolejności po kurs Wprowadzenie do UX. Dzięki temu poznasz podstawowe pojęcia. Z tego kursu skorzystają przede wszystkim: projektanci, którzy chcą poznać inne podejście do wytwarzania produktów cyfrowych; osoby zainteresowane praca w obszarach UX, architektury informacji czy projektowania interfejsów; osoby, które planują przebranżowić się na stanowisko UX albo UI designera; graficy, którzy chcą rozwinąć swoje kompetencje w procesie projektowym.
Okej. To przejdźmy sobie do podsumowania tych wszystkich informacji, które znalazły się na tym
etapie zbierania wymagań. I o czym warto
pamiętać, jeżeli za ten etap się zabieramy. Przede
wszystkim współpraca i zaangażowanie obu stron.
Ważne jest, żeby ten etap zbierania wymagań
nie skończył się tak, że przekażecie ileś wytycznych
klientowi, ileś informacji, które on musi wam dostarczyć,
wyślecie taką listę tych wszystkich rzeczy na maila i będziecie czekać, aż
to wszystko do was spłynie. Bo w momencie kiedy czekacie na dokumentację
do analizy, jeżeli taka jest przygotowywana, jeżeli czekacie na wypełnienie briefu, już
możecie zaangażować się trochę w poszukiwanie informacji właśnie
we wspomnianych desk research. Żeby to nie ograniczało się do takiej
biernej wymiany maili, w których nie jest zbyt dużo treści,
w których nie mamy zbyt dużo informacji. Są jakieś dokumenty, one
są bardzo losowe i nie ma jak tego wszystkiego zebrać w całość. Naprawdę
lepiej poświęcić chwilę na początku na dogadywanie nawet najdrobniejszych
detali, na spotkanie się, na to przewarsztatowanie niż
poświęcać później całą masę czasu na etapie produkcji, bo
okaże się, że gdzieś się rozminęliśmy, gdzieś trochę źle się zrozumieliśmy, klient
przyszedł do nas z zupełnie innymi oczekiwaniami niż nam
się wydawało. Wyobraźmy sobie, że przychodzi do nas babcia i mówi,
żebyśmy kupili bukiet kwiatów dla sąsiadki, bo ma urodziny. Idziemy
do kwiaciarni, kupujemy bukiet kwiatów i wracamy z tym bukietem, i babcia łapie
się za głowę, bo zaczyna mówić, że dlaczego kupiliśmy czerwone
róże kiedy sąsiadka najbardziej lubi żółte tulipany. I dlaczego ten
bukiet jest taki wielki, taki drogi, jak chodziło o to, żeby to był symboliczny
prezent. Więc to są sytuacje, które mogą
pojawić się również w naszym projekcie. Tylko efektem takiego
niedogadania się, niezrozumienia wzajemnych potrzeb będzie
niestety kwestia związana z budżetem. To
znaczy albo my na tym bardzo dużo stracimy, albo straci na tym klient, albo
z czasem, bo gdzieś przeszacowaliśmy, gdzieś
wydawało nam się, że to wszystko zajmie mniej czasu, bo będzie superproste,
a tymczasem okazało się, że z kolejnymi etapami dochodzi coraz więcej
niewiadomych, coraz więcej informacji do zrozumienia, odnalezienia,
i że tracimy ten czas, który moglibyśmy już poświęcić na produkcję, na
dogadywanie rzeczy, które powinny zostać uzgodnione już na samym początku. Więc
nawet jeżeli nie lubicie spotkań, nie lubicie rozmów przez telefon, nie lubicie
się warsztatować z klientami, to warto się przełamać, warto
dogadać się na samym początku, żeby uniknąć tej sytuacji, że gdzieś
na samym końcu pojawia się bardzo dużo niedogadanych kwestii,
dużo zażaleń i może nawet ukończyć
się to niestety zerwaną współpracą. Kolejna kwestia to
ego. I niestety to jest ten moment, kiedy ego musimy schować do
kieszeni. Projektanci są bardzo charakterystyczną grupą zawodową,
można by powiedzieć. Wystarczy zerknąć na popularne grupy czy fora
internetowe, żeby zobaczyć, że no czasem po prostu się między sobą nie
potrafimy dogadać, a na pewno nie potrafimy dogadać się z klientami. Ilość
memów i śmiesznych sytuacji, które pojawiają się z klientami
w tle, może o tym świadczyć. Pamiętajcie, że nie
wszyscy myślą tak, jak projektanci, nie każdy zna się na tym, na czym
zna się projektant i nie możemy zakładać, że jeżeli przyjdziemy
do klienta i zaczniemy opowiadać mu o pewnych rzeczach, to ten klient zrozumie
to w ten sam sposób jak my. Nie stosujmy branżowego słownictwa,
nie stosujmy słownictwa, którego klient nie jest w stanie zrozumieć,
nie kłóćmy się o to, czy to jest font, czcionka czy krój
pisma, bo to nie jest ten etap, kiedy warto się o to kłócić. I po
prostu zacznijmy empatyzować. Zacznijmy myśleć i starać
się myśleć jak ten klient, który nam coś zleca, jak ci użytkownicy, którzy
będą z rozwiązań tego klienta korzystali. I
to na pewno wiąże się z dużą dozą
cierpliwości. Te wszystkie rozmowy, dogadywanie,
spotkania, dokumenty. To wszystko potrafi chwilę potrwać
i warto tę chwilę przeczekać, poczekać, zagryźć
zęby i po prostu po ludzku dogadać się z drugim człowiekiem. Decyzje
projektowe będą bardzo często podejmowane przez osoby, które na projektowaniu się
nie znają, które o projektowaniu nie mają zielonego pojęcia. I z tym musimy się pogodzić,
że te decyzje będą ostatecznie podjęte przez jakiegoś
pana prezesa czy panią prezes, którym daleko jest od tego świata
projektowego, świata tworzenia aplikacji mobilnych i stron
internetowych. I naszą rolą jest edukowanie klienta po
co i w jaki sposób to robimy. Jeżeli podejmujemy pewne decyzje projektowe, to
miejmy w zanadrzu argumenty, dlaczego je podejmujemy. Jeżeli powiemy
deweloperom czy klientowi, że to jest zrobione tak, bo tak,
bo nam się tak wydaje, bo mamy taką intuicję i doświadczenie jako projektanci,
to może być trochę za mało dla takiego klienta, który wywala to całą kupę
kasy czy takiemu deweloperowi, który
może mieć zupełnie inne doświadczenia. Więc starajmy się
zrozumieć inny punkt widzenia. Starajmy się zrozumieć, dlaczego padają
pewne pytania i nie traktujmy od razu tych pytań jako atak, ale
z cierpliwością, na spokojnie, w prosty sposób,
prostym językiem starajmy się wytłumaczyć, o co tak naprawdę chodzi w
naszej pracy, po co my to wszystko robimy - i że ostatecznie gramy do tej samej bramki
i chcemy stworzyć dobry produkt. A to wiąże się oczywiście z
włączaniem innych specjalistów do procesu. Nie możemy
pozwolić sobie na to, że cały produkt powstaje tylko jako jakieś
widzimisię projektanta. Klient sobie siada z projektantem, tworzą zarąbisty
proces rejestracji w banku i nagle się okazuje, że zapomnieliśmy
o dziale prawnym, że zapomnieliśmy o deweloperach, którzy muszą to wdrożyć, muszą to
zoptymalizować. I te wszystkie pomysły, o których myśleliśmy, są po
prostu na tym etapie jeszcze nie do wdrożenia, bo jeszcze pewne technologie
nie są zbyt pewne, jest zbyt duże ryzyko, żeby wprowadzić
pewne rozwiązania i musimy z tym jeszcze poczekać. Im szybciej włączymy
do rozmowy specjalistów z innych obszarów, tym szybciej
dostaniemy podpowiedzi na to, w jaki sposób rozwiązać
pewne problemy projektowe, jak przekuć te nasze koncepcje, te nasze pomysły
na takie działające produkty. Więc otwierajmy się na współpracę z
deweloperami. Otwierajmy się na współpracę z copywriterami, z działem
marketingu. I zobaczycie, że im więcej tych różnych punktów widzenia, tym
też wasze rozumienie branży i projektu będzie dużo szersze. Klient
nie zawsze wie, czego chce. I naprawdę nie ma nic w tym złego, że przychodzi
do was klient, do was jako projektantów, do agencji zajmującej się projektowaniem,
jakiegoś biura projektowego i mówi, że potrzebuje aplikacji
mobilnej, ale zaczyna w sumie rozmawiać o stronie mobilnej i w sumie
trochę gubi wątki, trochę nie rozumie tej technologii, o której rozmawia. I
nagle się okazuje, że on w sumie to nie potrzebuje żadnej aplikacji, ale bardziej przydałby
mu się system do zarządzania produktami na magazynie. I jeżeli
ktoś nie jest specjalistą w danym obszarze, to ciężko będzie wybrać
narzędzia i ciężko będzie wybrać rozwiązania, które będą
rozwiązaniem tych konkretnych problemów. Więc zamiast narzekać na
to, że nasi klienci nie wiedzą, czego chcą i nie rozumieją, o co w tym wszystkim chodzi, postawmy
się w roli takiego klienta i spróbujmy sobie wyobrazić, jak
byśmy czuli się, gdyby ktoś nagle supertechniczne zaczął opowiadać nam
o tym, jak działa jakaś maszyna i zadawał
pytania, które w ogóle wychodzą poza obszar naszych zainteresowań i
wiedzy. Więc jeszcze raz: empatyzujmy. Musimy postawić
się w roli takiej osoby, która nie za bardzo może
wiedzieć, o co chodzi. Cierpliwie tłumaczmy, z czym to się wszystko
wiąże i starajmy się prowadzić tego klienta za rękę, bo to on nam ufa,
on uważa - my jesteśmy specjalistami, którzy będą wiedzieli, jak doradzić temu
klientowi, jak dobrać odpowiednie rozwiązania do
problemów, z którymi do nas przychodzi. I nie bójcie się powiedzieć czasami,
że klient po prostu racji nie ma. Bo tak. Bo klient nie zawsze ma
rację. Jeżeli pomyślimy o tym, że nie zawsze ma wiedzę potrzebną do podejmowania
pewnych decyzji, będzie mógł podejmować decyzje złe. Więc
to powiedzenie "klient nasz pan" potrafi być bardzo szkodliwe w
przypadku produkcji takich produktów, jak
rozbudowane systemy informatyczne, jak
aplikacje, jak strony internetowe. Im mniejszy produkt, im mniejsze
zaangażowanie zespołu, im mniejszy budżet, tym te szkody będą mniejsze. Ale
w przypadku bardzo rozbudowanych systemów, gdzie mówimy o tysiącach,
setkach tysięcy złotych zainwestowanych w tworzenie
takiego oprogramowania, nie możemy sobie pozwolić na podejmowanie
decyzji czy też zgadzanie się na podjęcie pewnych decyzji tylko
dlatego, że ktoś miał takie widzimisię. I czasami będziemy musieli być tymi
osobami, które powiedzą, że to nie ma sensu, że się z tym nie zgadzamy, że
to jest absolutnie nieakceptowalne z punktu widzenia procesu
projektowego. I czasem się trochę pokłócić nawet z tym klientem, żeby
dać tę świadomość tej drugiej osobie,
że to nie jest pomysł, który akceptujemy. Nie chodzi o to, żeby ślepo
realizować koncert życzeń klienta. Jasne, będzie jakiś
zakres takich funkcji, które czasami nie będą miały sensu,
ale będą się pojawiać na liście wymagań, bo klientowi podoba się
jakaś aplikacja, z której korzysta na co dzień, bo Facebook ma takie rozwiązanie, bo Instagram
ma takie rozwiązanie i teraz chcemy takie rozwiązanie w naszym naszym
systemie. I to, co nam będzie pomagać, to, co będzie zawsze
wspierać podejmowanie racjonalnych decyzji na tym
etapie, to po pierwsze badania z użytkownikami, analiza tego, czego
chcą użytkownicy, analiza biznesowa. Czy te
funkcje faktycznie przekładają się na korzyści biznesowe? Czy my będziemy mieć
z tego jakieś pieniądze na przykład? Więc takie szukanie sensownych
argumentów będzie na pewno pomocne w przypadku bardziej
absurdalnych pomysłów. I po prostu trzeba czasem zagryźć zęby i trochę
powalczyć. Oczywiście są sytuacje, w których możemy wyłożyć szereg
argumentów, szereg badań i cały zespół może nie zgadzać się z
decyzją klienta, a ten klient i tak podejmie ją właśnie w ten sposób. Nie
unikniemy tego. Zawsze jest to ryzyko, że spotkamy się ze ścianą,
ale życzę wam tego, żeby spotykać się z taką ścianą jak najmniej. Jeżeli
będziecie poświęcać swój czas i będziecie cierpliwie
podchodzić do takiego procesu, to zawsze jest większa szansa, że unikniemy
takich skrajnych sytuacji i faktycznie będziemy robić coraz
lepsze i mądrzejsze produkty. To,
o czym trzeba pamiętać, to to, że wymagania mogą się zmieniać. Że to nie jest coś stałego
i to jest normalne. Zwłaszcza w przypadku takich zwinnych metodyk. Kiedy
pracujemy w agile'u, kiedy pracujemy scrumowo, kiedy włączamy w to wszystko jeszcze
badania z użytkownikami na poszczególnych etapach, może okazać się, że ten zbiór
wymagań, które mieliśmy na początku po pierwszej fazie testów czy
po badaniach z potrzeb z użytkownikami, okaże
się, że będzie musiał być okrojony, że tam dużo z tych funkcji w ogóle nie ma sensu,
że nam się wydawało, że to są superpotrzebne funkcje dla użytkowników, ale
ci użytkownicy mają inne narzędzia, inne przyzwyczajenia, zupełnie inaczej wyobrażają
sobie działania takiego produktu. Więc gdzieś tam po drodze te zmiany będą wprowadzane
i trzeba się na to przygotować. Zarówno jeżeli chodzi o proces pracy, o
wypracowanie sobie pewnych zachowań, pewnych
procesów, sposobu w jaki, i w którym momencie zamykamy etap
poszukiwania i wypracowujemy, i znowu podchodzimy do testów. Ale
również musimy zadbać o to prawnie. To znaczy w momencie kiedy podpisujemy
umowę z klientem, kiedy podpisujemy umowę z agencją, software house'em czy z kimkolwiek z kim
będziemy pracować, musimy upewnić się, że umowa również zabezpiecza
nas w sytuacji, w której nagle część wymagań się zmieni. Żeby nie
było takiej sytuacji, że one będą zmieniać się do samego końca projektu, ten projekt
będzie bardzo się wydłużał, a ostatecznie my będziemy na tym tracić. Więc myślmy
o takich rzeczach, żeby po prostu nie zaskoczyły nas w nieodpowiednim
momencie. I na koniec: praktyka czyni mistrza. Jeżeli
pomyślę o sobie sprzed kilku lat, kiedy zaczynałam pracę zawodową i na
hasło "spotkanie z klientem" albo "wideokonferencja z
klientem" dosłownie trzęsły mi się ręce i strasznie się stresowałam,
to obiecuję wam, że im więcej takich spotkań,
im więcej warsztatów, im więcej, im częściej, częściej będziecie
przechodzić przez takie wydarzenia, takie sytuacje, będziecie
mieć do zorganizowania takie spotkanie, to zobaczycie, że powtarzają
się pewne schematy, powtarzają się pewne typy pytań, powtarzają się pewne typy
ćwiczeń, które wykonuje się na warsztatach. I to będzie dla was coraz bardziej
naturalne. Będziecie się czuć z tym coraz bardziej swobodnie. I nawet
jeżeli teraz nie wyobrażacie sobie, że moglibyście poprowadzić takie spotkanie
i warsztat, to może się okazać, że za kilka miesięcy, za pół roku, rok
będziecie mistrzami warsztatowania i spotkań. I okaże się, że całkiem
nieźle się w tym odnajdujecie. Więc każde kolejne spotkanie, każdy kolejny
błąd, który popełnicie na spotkaniu i warsztatach to nauczka na kolejne,
na to, żeby przygotować się w jakimś konkretnym zakresie, w jakimś konkretnym obszarze. Zobaczycie,
co sprawia wam największą trudność; czy to planowanie, tworzenie takiej agendy
czy moderowanie, czy może obserwacja. Może nie musicie
być wcale moderatorami. Może będziecie tylko osobami, które będą wymyślać, które
będą organizować i pomagać, ale prowadzić warsztaty będzie zawsze jakaś inna
osoba. Więc to też nie zawsze jest tak, że to każdy projektant musi być moderatorem
spotkania czy warsztatu. Możemy wymieniać się tymi
rolami w zespole. To wcale nie muszą być projektanci. Ale z całą pewnością warto
dbać o to, żeby rozwijać swoje umiejętności miękkie. One się nie tylko
przydają na spotkaniach i warsztatach, więc jest to coś, o czym
warto pamiętać. Nie tylko o tych metodach twardych, narzędziach i rozwiązaniach. Także
to tyle.