Читать книгу Badania jako podstawa projektowania user experience - Iga Mościchowska - Страница 11

Cechą wspólną zarówno zagadnień użyteczności, jak i user experience, jest niewątpliwie skupienie na użytkowniku i jego potrzebach. Jest to również podstawowe założenie procesu tworzenia produktu zwanego projektowaniem zorientowanym na użytkownika (user–centered design) czy też na człowieka (human–centered design).

Jesse James Garret:

Idea projektowania zorientowanego na użytkownika jest bardzo prosta. Bierz użytkownika pod uwagę na każdym kroku tworzenia produktu. Implikacje tej prostej idei są jednak zaskakująco złożone 15.

Proces UCD jest z definicji iteracyjny – każde z tworzonych rozwiązań powinno być weryfikowane i ulepszane. Z góry zakłada się, iż w drodze tworzenia produktu mogą być podejmowane nie najlepsze decyzje projektowe, których naprawa jest możliwa tylko dzięki zderzeniu go z użytkownikiem końcowym. Analiza różnych modeli procesu zorientowanego na użytkownika pozwala wyróżnić trzy podstawowe fazy w każdej iteracji. Ich terminy w różnych modelach mogą się od siebie różnić, jednak cel jest ten sam.

1. Analiza – to etap bliższego poznania problemu, analiza kontekstu użytkownika, eksplorowanie i odkrywanie, badanie potrzeb.

2. Projektowanie, czyli najbardziej kreatywny etap konceptualizacji, kreacji i tworzenia rozwiązań.

3. Weryfikacja – to z kolei ewaluacja i ocena stworzonego rozwiązania oraz wprowadzanie do niego ulepszeń, poprawek, zmian i modyfikacji.

Ten trzyskładnikowy schemat procesu jest powtarzany, tak aby w każdym kolejnym cyklu stosować wyniki weryfikacji poprzedniego rozwiązania. Model ten zakłada udoskonalanie produktu w kolejnych cyklach, aż do osiągnięcia pożądanego stanu. Nie jest powiedziane, ile powinno być tych iteracji, choć w domyśle proces ten może trwać bez końca. Zawsze pojawiają się jakieś nowe wymagania, zjawiska, a technologia ewoluuje, tak jak potrzeby użytkownika.

Ilustracja 3

Diagram iteracyjnego procesu UCD – projektowania zorientowanego na użytkownika – synteza wybranych modeli

Źródło: opracowanie własne

1.2.1. MIEJSCE UX W WODOSPADOWYM PROWADZENIU PROJEKTÓW

Projektowanie zorientowane na użytkownika można łączyć z tradycyjnym, wodospadowym procesem rozwijania produktu interaktywnego. W takim procesie poszczególne działania z dziedziny user experience następują kolejno jedna po drugiej, a iteracje występują wewnątrz danej fazy procesu. Wszelkie działania wdrożeniowe muszą być poprzedzone zamknięciem prac konceptualizacyjnych i projektowych. Przykładowy proces może wyglądać następująco:

1. Analiza

Faza zbierania wymagań od strony klienta oraz badania potrzeb użytkownika. Im więcej informacji uda się zgromadzić na tym etapie, tym lepsze będzie przygotowanie zespołu do realizacji dalszych kroków. W perspektywie UCD jest to faza kluczowa.

2. Modelowanie

Na podstawie wniosków z badań z poprzedniego etapu tworzona jest koncepcja rozwiązania. Definiowane są założenia i ramy, wewnątrz których powstać ma projekt.

3. Projektowanie

Strategia przekładana jest na projekt funkcjonalny, składający się z konkretnych ekranów. Tak powstaje dokumentacja projektowa.

4. Ewaluacja

Opracowane w poprzedniej fazie rozwiązania, jeszcze przed fazą implementacyjną, są weryfikowane w testach z użytkownikami, po których nanoszone są poprawki do projektu. Etapy projektowania i ewaluacji mogą występować po sobie cyklicznie w 2 lub 3 turach, zanim zespół rozpocznie kolejną fazę.

5. Implementacja

Dopiero po zakończeniu ewaluacji i naniesieniu poprawek projekt jest realizowany przez dział programistyczny. Następuje implementacja wcześniej zaprojektowanego rozwiązania, zgodnego z analizą potrzeb użytkowników i wypracowaną strategią.

6. Rozwój

Na tym etapie prowadzone są działania optymalizacyjne, na bieżąco są monitorowane i weryfikowane wybrane elementy produktu, a w przypadku wystąpienia takiej potrzeby są wdrażane ewentualne modyfikacje i ulepszenia.

1.2.2. MIEJSCE UX W METODYKACH ZWINNYCH

Nieco więcej ekwilibrystyki wymaga planowanie działań z obszaru projektowania user experience w przypadku projektów prowadzonych zgodnie z metodykami zwinnymi, takimi jak scrum. Ogólne założenia metodyk zwinnych są bardzo bliskie założeniom projektowania zorientowanego na użytkownika – nastawienie na iteracyjny model pracy, zmienność wymagań, częste inspekcje rozwiązań i stała adaptacja do zmian. Jednak w przypadku bardziej ustrukturyzowanych procesów, z ograniczonymi czasowo, dość krótkimi sprintami (czyli iteracjami), prace UX wymagają bardzo dokładnego planowania uwzględniającego także pracę programistów.

Ilustracja 4

Schemat podziału zadań zespołu w metodyce scrum (w podziale na role badacza, projektanta i programistów)

Źródło: opracowanie własne

W przypadku metod zwinnych badacze i projektanci UX pracują w tym samym czasie, w którym wdrażany jest projekt, nie zawsze jednak nad tymi samymi częściami co programiści. Zwykle prace projektowe – czyli planowanie działania danych elementów interfejsu – odbywają się w sprincie poprzedzającym implementację tego rozwiązania. Tak aby programista rozpoczynający swój sprint miał już przygotowaną dokumentację, np. makiety wybranych ekranów. W trakcie wdrażania tego rozwiązania projektant pozostaje w stałym kontakcie z deweloperem, rozwiązując na bieżąco wszelkie wątpliwości, a jednocześnie zajmuje się zaprojektowaniem rozwiązań potrzebnych do kolejnego sprintu programistycznego.

Najtrudniej w metodykach jest zaplanować zwinne badania. W większych zespołach, w których inne osoby zajmują się badaniem potrzeb i ewaluacją użyteczności, a inne projektowaniem, badania potrzeb powinny się odbywać w sprincie poprzedzającym projektowanie (czyli dwa sprinty przed oprogramowaniem). Testy ewaluacyjne mogą się odbywać w tym samym sprincie co projektowanie, tak aby szybko przetestować rozwiązanie i jeszcze w tym samym sprincie wprowadzić poprawki. Dzięki temu do zespołu wdrożeniowego trafia zweryfikowany projekt.

W mniejszym zespole osoba odpowiedzialna za projektowanie user experience zajmuje się także analizą wymagań do kolejnej iteracji i testuje z użytkownikami zaprojektowane przez siebie wcześniej rozwiązania. W efekcie w jednym sprincie powinna dzielić swoje obowiązki między projektowaniem rozwiązań, ich ewaluacją, konsultowaniem ich z programistami a badaniem potrzeb. W praktyce jest to bardzo trudne i często badania schodzą na dalszy plan lub wykonuje się je na początku całego procesu, przed rozpoczęciem pierwszego sprintu. Nawet jeśli badania są wykonywane, to zwykle ograniczenie czasowe odbija się negatywnie na zakresie badań, liczbie respondentów czy stopniu formalizmu w procesie badawczym (np. rezygnuje się z pisania raportu badawczego na rzecz prezentacji wyników przed zespołem).

1.2.3. BADANIA Z UŻYTKOWNIKAMI W UCD

Zarówno na etapie analizy potrzeb, jak i na etapie weryfikacji projektu jest wymagany udział użytkowników produktu, aby móc mówić o procesie zorientowanym na użytkownika. Wynika to z faktu, iż projektanci nie posiadają kompletnej wiedzy na temat odbiorców swojego systemu ani nie są w stanie w pełni przewidzieć wszystkich jego zachowań i reakcji. W pierwszym etapie, jeszcze przed stworzeniem produktu, przyszły lub potencjalny użytkownik jest potrzebny twórcom do lepszego zrozumienia problemu, który planują rozwiązać. Jest to tak zwana faza zbierania wymagań. W fazie ostatniej projekt jest weryfikowany w czasie jego używania przez realnych odbiorców, aby sprawdzić poprawność rozwiązań w zderzeniu z realnym światem. Podstawowym celem tego etapu jest dbanie o wysoką jakość końcowego produktu, gdyż wszelkie wnioski z badań prowadzą do jego poprawienia. Jak łatwo się domyślić, na różnych etapach tworzenia produktu są potrzebne różne metody badawcze.

Ilustracja 5

Przydatność badań (w podziale na 3 rozdziały z niniejszej książki) na różnych etapach procesu tworzenia produktu interaktywnego

Źródło: opracowanie własne

Na potrzeby książki metody badawcze zostały podzielone na trzy typy, ze względu na cel badania:

1. badania potrzeb, występujące głównie na etapie analizy, w początkowych etapach rozwoju produktu – opisane w rodziale 3,

2. ewaluacja, czyli metody pozwalające zweryfikować stworzony projekt, omówione w rozdziale 4,

3. optymalizacja – także służąca ewaluacji, jednak wymagająca posiadania wdrożonego już projektu, której opis można znaleźć w rozdziale 5.

Jak widać na diagramie procesu tworzenia produktów interaktywnych, metody te stają się przydatne na różnych etapach i są używane do różnych celów. Najlepiej widać to na przykładzie badań kwestionariuszowych, które można stosować zarówno w celu badania potrzeb (np. poznanie cech psychospołecznych potencjalnych użytkowników), ewaluacji (do sprawdzenia poziomu satysfakcji z danego rozwiązania), jak i optymalizacji (np. pytanie użytkowników o przyczynę rezygnacji z produktu).

Rola badacza

Badacz to nie tylko osoba, która konstruuje narzędzie badawcze i przeprowadza sesje z użytkownikami, a później tworzy wykresy z danych. Nie jest jedynie osobą przetwarzającą informacje. Oprócz ogromnej roli, która polega na zapewnieniu trafności i rzetelności przeprowadzanych działań oraz wyciąganych wniosków, pełni on też ważną rolę jako łącznik pomiędzy światem użytkownika a zespołu projektowego. Podstawowe zadanie badacza to właśnie interpretowanie zjawisk i problemów oraz przełożenie ich na konkretne wnioski projektowe, a co za tym idzie – rekomendacje dotyczące produktu: jego strategii, koncepcji, zakresu czy funkcji. Należy uświadomić sobie, iż projektowanie na podstawie badań nie polega na ślepym wdrażaniu zachcianek użytkowników, ale szukaniu wzorców zachowań, przyczyn problemów, nisz do zagospodarowania. Dzięki temu badania pomagają w świadomym podejmowaniu decyzji projektowych, w szukaniu nowych sposobów interakcji – wspomagają kreowanie nowych rozwiązań i tworzenie innowacji. Ważne, aby pamiętać, iż badacz jest osobą z pogranicza świata użytkownika i świata designu, a dane z badań stanowią bazę, która służy do wspólnego, zespołowego wytwarzania rozwiązań. To ogromna odpowiedzialność, dlatego też badacz UX musi nie tylko biegle poruszać się w obszarze metodologii i praktyki badań, lecz także posiadać wiedzę z obszaru tworzenia produktów i projektowania rozwiązań interaktywnych. Tylko wtedy będzie zdolny wystosować trafne rekomendacje, wychwycić inspiracje oraz wraz z zespołem projektowym przełożyć wyniki badań na nowe rozwiązania. Niezwykle istotne jest, aby badacz i projektant mówili tym samym językiem, potrafili wytworzyć narzędzia modelowania i ściśle współpracowali w procesie tworzenia rozwiązań.

DESIGN THINKING A USER-CENTERED DESIGN

W ostatnich kilku latach popularność zyskał kolejny model pracy nad rozwojem produktów, zwany design thinking (termin nie ma odpowiednika w języku polskim i jest powszechnie używany w formie angielskiej). W Polsce powstają kierunki studiów pod tą egidą, coraz bogatsza staje się też oferta wydarzeń i spotkań dla fanów design thinking. Zwolennicy chwalą to „nowe” podejście do tworzenia produktów jako sposób na tworzenie świeżych, innowacyjnych i kreatywnych rozwiązań. Jednocześnie rozwiązania te mają być, zdaniem popularyzatorów tego podejścia, a zarazem wiodącej agencji projektowej IDEO, pożądane przez ludzi, mieszczące się w założeniach biznesu oraz technicznie wykonalne16. Brzmi znajomo?

Proces design thinking zawiera w sobie 3 etapy17, których opis także może się wydawać znajomy.

1. Immersja – czyli zanurzanie się w kontekście problemu, pełne jego poznanie zarówno z perspektywy klienta, jak i użytkowników, zwykle w drodze badań etnograficznych, etap kończy się analizą i syntezą obserwacji i wniosków.

2. Ideacja – wyniki fazy immersji są wykorzystywane do stymulacji kreatywności na etapie tworzenia rozwiązań zdefiniowanych wcześniej problemów, w tej fazie powstaje pomysł projektu.

3. Prototypowanie – podstawowym celem fazy tworzenia prototypu wymyślonego wcześniej rozwiązania jest jego weryfikacja, także przez użytkowników końcowych, co pozwala na ulepszanie rozwiązania.

Czymże jest ten proces, jeśli nie inaczej nazwanym user-centered design, z fazą analizy, projektowania i weryfikacji, łączący potrzeby użytkownika, cele biznesowe i ograniczenia technologii? Ten pogląd zdają się potwierdzać sami twórcy terminu – agencja IDEO – która w kontekście swojej metodologii prowadzenia projektów używa zamiennie określeń design thinking i human-centered design.

15

J.J. Garett, The Elements of User Experience: User-Centered Design for the Web and Beyond, Second Edition, New Riders, Berkeley 2011; tłum. własne.

16

Our Approach: Design Thinking, http://www.ideo.com/about/.

17

Design Thinking: Business Innovation, opracowanie zbiorowe, MJV Press, Rio de Janeiro 2012, dostępne online: http://www.designthinkingbook.co.uk/.