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).
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