UNIA EUROPEJSKA
EUROPEJSKI FUNDUSZ
ROZWOJU REGIONALNEGO
Projektowanie użytecznych
produktów
Jakub Andrzejewski
Autor:
Jakub Andrzejewski
Janmedia Interactive
Wydawca:
Polska Agencja Rozwoju Przedsiębiorczości (PARP)
ul. Pańska 81/83
00-834 Warszawa
www.parp.gov.pl
Skład:
Marcin May
PARP
Wydanie I
Publikacja bezpłatna
Publikacja powstała w ramach projektu „Uruchomienie wielofunkcyjnej platformy komunikacji inter-
netowej wspierającej realizację działań 8.1 i 8.2 PO IG”, realizowanego przez Polską Agencję Rozwoju
Przedsiębiorczości, współfinansowanego ze środków Unii Europejskiej w ramach Europejskiego
Funduszu Rozwoju Regionalnego.
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Rozwoju
Regionalnego
Wspieramy e-biznes www.web.gov.pl
Copyright © by Polska Agencja Rozwoju Przedsiębiorczości Warszawa 2009, Wszelkie prawa zastrze-
żone. Żaden fragment nie może być wykorzystywany w jakiejkolwiek formie ani przekładany na język
mechaniczny bez zgody PARP.
3
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
Spis treści
1. Jak to się zaczęło
4
2. Użyteczność
4
3. Projektowanie zorientowane na użytkownika (User-Centered Design)
5
3.1 Projektowanie
6
3.2 Tworzenie prototypów 7
3.3 Testowanie
7
4. Podsumowanie
9
4
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
1. Jak to się zaczęło
Zanim przejdziemy do pojęcia użyteczności warto przedstawić określenie czynnika ludzkiego. Czynnik
ludzki to fizyczna lub psychiczna cecha człowieka, która ma wpływ na funkcjonowanie maszyn i urządzeń
(np. systemów informatycznych). Są to zatem predyspozycje i ograniczenia umysłu jak i zdolności moto-
ryczne człowieka. Branie pod uwagę wspomnianego czynnika w projektowaniu urządzeń i systemów
sprawia, że korzystanie z nich jest efektywne, bezpieczne i satysfakcjonujące.
Do lat 70-tych wszelkie wyniki badań nad czynnikiem ludzkim były wykorzystywane do projektowania
systemów i urządzeń w lotnictwie (szczególnie wojskowym), z których bezpośrednio korzysta człowiek
(np. optymalne dla pilota rozplanowanie kokpitu samolotu).
Zainteresowanie wykorzystaniem wiedzy o czynniku ludzkim w systemach komputerowych zaczęło się
podczas konferencji w 1982r. w Gaithersburgu, USA, gdzie tematem był „Czynnik ludzki w systemach
komputerowych”. Tak też zrodziło się pojęcie HCI (Human-Computer Interaction), czyli interakcja człowiek-
komputer. Zaczęły powstawać publikacje naukowe opisujące dobre praktyki i wskazówki projektowania
systemów, lecz miały one wyłącznie charakter eksperymentów naukowych.
W późnych latach 80-tych przełomem okazało się zaadaptowanie istniejących metod i narzędzi badaw-
czych do procesu wdrażania systemów komputerowych. Optymalizacja ich nie była już skomplikowanym
badaniem naukowym a praktycznym i efektywnym podejściem do ich projektowania. Od tej pory jednym
z atrybutów produktu była użyteczność, która nie była przypadkowym elementem a przemyślaną częścią
całości procesu projektowego. Przez kolejne lata optymalizowano i tworzono metody ewaluacji użytecz-
ności systemów interaktywnych.
Duży wpływ na popularyzację użyteczności miało wprowadzenie na rynek komputera osobistego Apple
Macintosh, który udowodnił, że łatwość i intuicyjność użytkowania jest kluczowym komponentem pro-
duktu interaktywnego. Przekonanie o wartości użyteczności produktu nie było już tylko teorią. Popchnęło
to dalej chęć integracji zespołów ds. użyteczności z istniejącym cyklem produkcyjnym i nie traktowano
ich już jako element spowalniający proces ale jako wartość dodaną i integralny element procesu. Po roku
1993 użyteczność wkroczyła do świata Internetu.
2. Użyteczność
Użyteczność (ang. Usability) ma wiele definicji. Jedną z nich jest definicja ISO 9241-11, która definiuje
użyteczność jako miarę efektywności, wydajności i satysfakcji z jaką można korzystać z produktu przez
danych użytkowników, aby osiągnąć określone cele w danym kontekście użycia.
Innymi słowy, produkt jest użyteczny , gdy korzystanie z niego jest efektywne, wydajne i satysfakcjonu-
jące, czyli np. gdy:
Łatwo można się go nauczyć obsługiwać
•
Jest skuteczny
•
Jest intuicyjny
•
Ułatwia wyszukiwanie informacji
•
Nie zaskakuje swoim zachowaniem
•
Budzi zaufanie
•
Jest atrakcyjny wizualnie
•
5
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
3. Projektowanie zorientowane na użytkownika (User-Centered Design)
Projektowanie zorientowane na użytkownika to filozofia projektowania, w której stawiamy użytkownika
i jego cele na pierwszym miejscu. Koncentrując się przede wszystkim na odbiorcy produktu, wszel-
kie decyzje projektowe oparte są na rzeczywistych potrzebach osób, które będą z produktu korzystać.
W rezultacie jesteśmy w stanie zapewnić wysoką użyteczność produktu, który będzie spełniać oczekiwa-
nia użytkowników docelowych.
Poniżej znajduje się uproszczony schemat procesu UCD:
UCD to projektowanie iteracyjne, co obrazuje powyżej pętla tworzenia prototypu i ewaluacji.
Etap analizy to pierwszy krok procesu. W etapie tym definiujemy cele biznesowe produktu oraz do kogo
go kierujemy. Nie jest jednak wystarczające poznanie demograficznych informacji na temat użytkow-
ników końcowych (wiek, wykształcenie itd.). Najistotniejszym elementem poznania użytkowników jest
zrozumienie ich potrzeb, celów i kontekstu użycia produktu, który chcemy im dostarczyć. Jakie cele będą
zaspokajane za pomocą tego produktu? Co motywuje użytkowników do korzystania z niego? Jakie są ich
potrzeby? W jakim środowisku będą korzystać z produktu? Czy użytkownicy są obyci z komputerami i czy
czują się pewnie w korzystaniu z nich? Na te i wiele innych pytań odpowiadamy sobie na etapie analizy.
Informacje o użytkownikach mogą pochodzić z kilku źródeł: od nich samych, z działu marketingu, który
monitoruje grupę docelową, czy ze statystyk serwisu. Do technik badawczych wykorzystywanych przy
analizie użytkownika należą m.in. sondaże, kwestionariusze, wywiady z użytkownikami, badania tere-
nowe. Wybór poszczególnych technik uzależniony jest od możliwości czasowych i łatwości dostępu do
grupy docelowej, jednakże wiele z nich można stosować komplementarnie.
Inna część pracy analitycznej dotyczy tzw. kontekstu użycia. Głównym celem analizy kontekstu użycia jest
charakterystyka kluczowych dla produktu właściwości środowiska fizycznego, organizacyjnego i technicz-
nego, w którym produkt jest używany oraz zdobycie wiedzy na temat procesu przepływu zadań i infor-
macji. Pozwala ona poznać prawdziwe warunki, w jakich użytkownicy wykonują zadania i sytuacje, które
towarzyszą ich korzystaniu z systemu. Cele te realizowane są w oparciu o badania obserwacyjne, czasem
wzbogacone wywiadami bądź kwestionariuszami ankietowymi.
Standardowo obserwacja użytkowników odbywa się w ich naturalnym środowisku pracy, gdzie badacze
identyfikują czynniki mające wpływ na używanie produktu, a w szczególności warunki:
Techniczne (np. sprzęt i oprogramowanie, pozostałe urządzenia, potencjalne ograniczenia)
•
Organizacyjne (np. współpracownicy, osoby mające dostęp do produktu)
•
Fizyczne (np. lokalizacja miejsca pracy z produktem, natura i liczba zakłóceń)
•
W czasie obserwacji działania użytkowników są rejestrowane, np. w formie odręcznych notatek, nagrań
audio czy video. Obserwatorzy notują czas trwania czynności, rodzaj i liczbę wykonywanych działań,
wystąpienie błędów i trudności z użytkowaniem systemu, kontaktowanie się z współpracownikami
w sytuacji trudnej itp.
6
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
Tego typu badania potrzebują dużego nakładu czasowego oraz umiejętności wyselekcjonowania najistot-
niejszych informacji spośród wielu przekazywanych przez użytkowników. Pomimo tych trudności dzięki
tej procedurze można zdobyć nietypowe, cenne informacje dotyczące pracy użytkowników, które mogą
być kluczowe dla projektowania interfejsu.
Prace analityczne obejmują również przegląd konkurencyjnych rozwiązań pod kątem ich użyteczności.
Celem analizy konkurencji jest określenie słabych i mocnych stron produktów z branży oraz stworzenie
listy swoich rozwiązań, które będą rywalizować z konkurencyjnymi.
Badanie obejmuje od trzech do dziesięciu głównych produktów konkurencyjnych. Na wstępie tworzy się
listę kryteriów do analizy. Mogą one dotyczyć m.in. informacji zawartych w systemie, funkcjonalności,
czy formy prezentacji danych. Dobrze, gdy wynikają z zasad użyteczności. Następnie analizuje się strony
konkurencyjne pod kątem tych kryteriów.
Analiza konkurencji stanowi dobre źródło interesujących i sprawdzonych rozwiązań oraz inspiracji do two-
rzenia nowych. Nie zawsze jednak dysponuje się łatwym dostępem do produktów konkurencji.
Kluczem do sukcesu w fazie analitycznej jest systematyczne i ustrukturyzowane podejście do zdobywa-
nia informacji o użytkowniku i od użytkownika. Ważne jest, by analitycy zajmujący się tematem posiadali
wysokie umiejętności interpersonalne i byli wolni od odgórnych założeń. W przeciwnym wypadku rezul-
taty mogą okazać się nierzetelne i zniekształcone.
Nie wcześniej niż po zakończeniu etapu analitycznego (mając wszystkie informacje wstępne) jesteśmy
w stanie rozpocząć projektowanie produktu, czyli przejść do kolejnej fazy procesu UCD.
3.1 Projektowanie
Połączenie potrzeb biznesowych z potrzebami użytkownika oraz usystematyzowanie ich w spójny, jasny
i logiczny system skutkuje opracowaniem optymalnego produktu na potrzeby grupy docelowej.
Z kolei wykorzystanie wiedzy zdobytej w fazie analitycznej zapewnia trafny dobór funkcjonalności i roz-
wiązań oraz pozwala wyeliminować ryzyko związane z zaprojektowaniem produktu nie odpowiadającego
potrzebom użytkowników.
W każdym z działań w ramach tego etapu grupa projektowa odwołuje się do wyników wcześniejszych
analiz. W skład prac projektowych wchodzą:
Analiza zadań użytkownika – identyfikacja celów użytkownika oraz zadań, które będą prowa-
1.
dzić do ich osiągnięcia. W tym stadium wykorzystuje się metodę analizy zadań oraz diagramy ich
przepływu. Zadania mogą być dekomponowane na podzadania, na podstawie których tworzy się
diagramy zadań. Zadania można dekomponować na różnych poziomach szczegółowości. Technika
ta daje dobry wgląd w zadania, które użytkownik wykonuje, musi lub powinien wykonywać, aby zre-
alizować swoje cele.
Tworzenie specyfikacji funkcjonalnej systemu – na podstawie scenariuszy użycia oraz wiedzy
2.
ekspertów, opracowywana jest specyfikacja funkcjonalna produktu. Scenariusze pokazują kroki,
które trzeba wykonać, żeby zrealizować zadanie. Pozwala to na dobre zrozumienie kontekstu użycia
systemu i zaprojektowanie go tak, aby wspierał realizację celów przez użytkowników. W ten sposób
definiuje się wymagania funkcjonalne systemu (lub weryfikuje już istniejące).
Konstrukcja struktury serwisu (w przypadku stron www) – stworzona ten sposób dokumentacja
3.
funkcjonalna interfejsu przekładana jest następnie na strukturę serwisu. Na bazie metod takich jak
sortowanie kart czy diagramy podobieństwa projektanci ustalają, jak użytkownicy grupują i hierar-
chizują informacje, jakich struktur informacyjnych oczekują i jak je nazywają.
W przypadku sortowania kart ok. 6-12 uczestników badania ma do dyspozycji karteczki z nazwami
elementów badanego serwisu (treści lub funkcjonalności). Ich zadaniem jest pogrupowanie ich tak,
by te kojarzące się ze sobą znalazły się w jednej kategorii. Utworzone w ten sposób grupy również
są sortowane wg podobieństwa (im bliżej siebie leżą, tym silniejszy związek między nimi). Zwykle
też prosi się badanych o nadanie nazw utworzonym kategoriom (by wybrać te najbardziej naturalne
i intuicyjne). Do zalet tej metody należy niewątpliwie angażowanie rzeczywistych użytkowników
systemu, co dostarcza informacji o posiadanych przez nich modelach umysłowych. Jednakże może
się zdarzyć tak, że wypracowana struktura nie będzie użyteczna, jeśli osoba chce wykonać jakieś
konkretne zadanie. Ponadto w wyniku sortowania możemy otrzymać duży rozrzut wyników między
użytkownikami, a więc wiele wariantów organizacji informacji. Mimo to wiedza zdobyta w wyniku
tej techniki jest niezwykle przydatna w procesie tworzenia nowego serwisu, jego części bądź też
przeprojektowaniu.
7
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
Projektowanie interakcji i interfejsu użytkownika – działania w tym etapie są skierowane na uła-
4.
twienie użytkownikom osiągania celów i wykonywanie zadań. Określany jest taki przebieg interakcji
użytkownika z systemem, który maksymalnie wspiera naturalny sposób, w jaki ludzie komunikują się
i działają oraz zapewnia satysfakcję z jego używania.
Oprócz tego w procesie projektowania interakcji bierze się pod uwagę dodatkowe cele wspierające
komunikację użytkownik-system. W celu zaplanowania intuicyjnego i optymalnego z punktu widze-
nia potrzeb użytkownika interfejsu projektanci korzystają ze sprawdzonych standardów. Obejmują
one m.in.:
Efektywne komunikowanie funkcjonalności systemu
•
Informowanie użytkownika o stanie systemu i jego zmianach
•
Dbałość o bezpieczeństwo użycia i zapobieganie powstawaniu błędów
•
Wspieranie autonomii użytkownika i jego poczucia kontroli
•
Umożliwienie eksplorowania i odkrywania nowych rzeczy (jeżeli taka cecha jest wymagana)
•
Szybkie wyuczenie i zapamiętanie reguł pracy z systemem
•
Wydajność użycia systemu i unikanie opóźnień
•
Końcowym wynikiem tego etapu jest opracowanie dokumentacji w zakresie funkcjonalności, podsta-
wowych zadań użytkownika oraz ich dynamiki. Dalsze kroki przewidują tzw. alokację zadań i funkcji.
Dokonanie alokacji zadań i funkcji – projektanci definiują, które z zadań ma być wykonane przez
5.
maszynę a które przez człowieka. Alokacja zadań może wynikać z wielu czynników takich jak bezpie-
czeństwo człowieka, jego możliwości psychomotoryczne, środowisko. Na tym etapie bardzo przy-
datne są wyniki analizy kontekstu użycia.
Końcowym rezultatem etapu projektowego jest przygotowanie dokumentacji specyfikującej warstwę
funkcjonalną oraz strukturę systemu. Spisywane są też cele i oczekiwania użytkownika co do pracy
z produktem oraz wymagania użyteczności, które ten powinien spełnić. Wymagania te posłużą następnie
jako kryteria do weryfikacji, czy opracowany na podstawie dokumentacji prototyp realizuje postawione
założenia.
Zanim projektanci rozpoczną tworzenie prototypów, wyłoniona do tego momentu koncepcja (lub kon-
cepcje) produktu jest weryfikowana na spotkaniach z użytkownikami systemu i zespołem projektowym.
Organizowany jest tzw. storyboarding, na którym prezentowana jest wizualizacja wybranych funkcji, inte-
rakcji, ścieżek nawigacji i zdarzeń w interfejsie. Na bazie wywiadów z użytkownikami, analiz eksperckich
czy np. wędrówki poznawczej oceniana jest trafność zastosowanych rozwiązań, ich dopasowanie do
oczekiwań odbiorcy oraz dostosowanie do standardów użyteczności.
3.2 Tworzenie prototypów
Faza tworzenia prototypu (makiety funkcjonalnej) produktu to nic innego jak przekształcenie wszelkich
informacji zdobytych podczas analizy i wstępnych etapów projektowania na namacalny projekt graficz-
nego interfejsu użytkownika, czyli tego co widzimy, gdy korzystamy z produktu (okno programu, strona
główna strony www itd.)
Zespół projektujący makiety może stosować technikę projektowania równoległego, która zakłada wyge-
nerowanie jak największej liczby różnych koncepcji interfejsu systemu. Projektanci niezależnie od siebie
tworzą różne koncepcje interfejsu systemu (faza dywergencji). W trakcie zabroniona jest jakakolwiek
komunikacja między nimi. Po zakończeniu generowania pomysłów następuje faza konwergencji i zawę-
żanie przestrzeni prototypów aż do wyboru 1 lub 2 głównych kandydatów. Wyłonione koncepcje są ana-
lizowane lub testowane celem określenia najlepszego rozwiązania.
Jeśli chodzi o technikę przygotowywania makiet, to mogą być tworzone w formie odręcznych szkiców
na papierze, bądź przy użyciu oprogramowania. W tym ostatnim przypadku często mają charakter inte-
raktywny, co potem znacznie usprawnia ich testowanie z użytkownikami, co nie oznacza, że prototypów
papierowych nie można testować.
Weryfikacja makiet funkcjonalnych odbywa się podczas testów z udziałem użytkowników oraz analizy
eksperckiej. W ten sposób jeszcze przed wdrożeniem systemu zdobywa się wiedzę na temat prototypowa-
nego produktu pod kątem jego odbioru oraz standardów użyteczności. Taka procedura pozwala przede
wszystkim zidentyfikować problemy we wczesnych fazach pracy nad produktem i uniknąć błędów w póź-
niejszych stadiach, co w konsekwencji prowadzi do znacznych oszczędności finansowych.
3.3 Testowanie
Testy z udziałem użytkowników, w zależności od etapu projektowania, na którym są stosowane, mogą
mieć charakter eksploracyjny, oceniający lub walidacyjny. Ich głównym celem jest zdobycie wiedzy, czy
produkt spełnia stawiane mu założenia (oczywiście z punktu widzenia użytkownika).
8
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
Testy mają charakter behawioralno-poznawczy i powinny angażować reprezentatywnych dla grupy
docelowej użytkowników systemu. To odróżnia tę metodę od innych analiz użyteczności, np. wędrówki
poznawczej czy analizy eksperckiej. Zwykle użytkownicy wykonują zadania (scenariusze) typowe dla sys-
temu. W czasie testu oprócz poziomu realizacji scenariuszy obserwuje się interakcję użytkownika z syste-
mem, jego reakcje behawioralne i emocjonalne.
Wczesne testy można prowadzić już na prototypach w formie szkiców. Z uwagi na brak interakcyjności
takie badanie przybiera raczej formę wywiadu indywidualnego – użytkownicy pytani są o oczekiwania,
zamiary i spostrzeżenia odnośnie poszczególnych odsłon produktu i jego funkcjonalności. W miarę możli-
wości można też wprowadzać elementy zadań-scenariuszy. Należy także pamiętać o legendzie oznaczeń
na makiecie i używaniu symboli zrozumiałych dla użytkownika. Aby usprawnić wprowadzanie zmian na
prototypach, notatki mogą być prowadzone na samych szkicach. W ten sposób łatwo i niedrogo jesteśmy
w stanie sprawdzić poprawność decyzji projektowych.
W przypadku makiet interaktywnych przebieg testu jest zbliżony do standardowych testów użyteczności,
wykonywanych na już działających systemach.
Podstawowe elementy testów z udziałem użytkowników:
Postawienie zagadnień badawczych
•
Wybór reprezentatywnej grupy użytkowników
•
Opracowanie zadań (scenariuszy) reprezentatywnych dla użytkowników i systemu
•
Właściwe badanie
•
Każdy użytkownik dostaje zestawy zadań (kolejność ich prezentacji jest rotowana, by kontro-
−
lować czynnik uczenia się systemu). Zestaw składa się z problemów zamkniętych i otwartych
Użytkownicy proszeni są o tzw. „głośne myślenie” podczas wykonywania zadań
−
Zadania realizowane są w czasie ok. 120 minut
−
Po zakończeniu każdego etapu testowego, użytkownik wypełnia krótki kwestionariusz ewalu-
−
acyjny (oceniający subiektywne wrażenia odnośnie pracy z produktem)
Użytkownik otrzymuje opłatę za udział w testach, nie uzależnioną od przebiegu badania
−
Zebranie ilościowych i jakościowych danych o wykonaniu zadań i preferencjach użytkownika
−
Spisanie rekomendacji do ulepszenia produktu
−
Badania z użytkownikami są przeprowadzone z udziałem od 3 do 12 osób, z ustalonej grupy docelowej.
Taka liczba użytkowników zapewnia zgromadzenie wystarczającej ilości spostrzeżeń dotyczących użytecz-
ności i odbioru systemu. Ze względu na jakościowy charakter badania, nie jest konieczne uczestnictwo
dużej grupy osób. Rekrutacja użytkowników do badań opiera się na standardowych narzędziach rekru-
tacyjnych oraz już zbudowanej bazie testerów. Osoby zaproszone do badań nie powinny być zawodowo
związane z branżą informatyczną, chyba że wymaga tego specyfika testowanego produktu. Mogłoby to
wpłynąć na obiektywność badań, zatem należy dbać o pełną niezależność badanych użytkowników.
W wyniku testów z użytkownikami otrzymuje się dane odnoszące się do:
Wykonania, tj.:
1.
Czas wykonania zadania
•
Ilość i procent zadań poprawnie zakończonych – z pomocą i bez pomocy moderatora testu
•
Ilość i procent niewykonanych zadań
•
Czas potrzebny do realizacji konkretnych czynności, np. wyszukania informacji, naprawienia
•
błędu, przeczytania sekcji tekstu itp.
Preferencji oraz uzasadnienia:
2.
Przydatność produktu
•
Czy produkt spełnia oczekiwania użytkownika?
•
Łatwość użycia
•
Wyuczalność
•
Prototyp A vs prototyp B (który z nich woli lub wybiera użytkownik)
•
Stosowane są cztery główne typy testów użyteczności:
Eksploracyjny – stosowany we wczesnych fazach cyklu projektowania, gdy produkt jest w początkowych
stadiach tworzenia. Celem jest zbadanie ogólnego rozumienia makiet czy prototypów produktu – jego
layoutu, organizacji funkcjonalności. Często ma nieformalny charakter i opiera się na interakcji użytkow-
nik – prowadzący test. Na tym etapie użytkownik raczej komentuje poszczególne elementy, niż wykonuje
zadania.
9
Projektowanie użytecznych produktów
www.parp.gov.pl
www.web.gov.pl
Oceniający – stosowany w pośrednich etapach projektowania, gdy produkt już jest wstępnie stwo-
rzony. Celem jest zbadanie, jaka jest efektywność koncepcji zaimplementowanych we wcześniejszych
fazach cyklu projektowego. Sprawdza się wykonanie zadań (scenariuszy) angażujących poszczególne
funkcjonalności produktu. Większy nacisk położony jest na zachowania użytkownika, niż na jego opinie.
Zaangażowanie prowadzącego badanie jest mniejsze (słabsza interakcja niż w testach eksploracyjnych).
Można zbierać dane ilościowe, np. czas wykonania zadania, ilość błędów itp.
Walidacyjny – stosowany w końcowych etapach tworzenia produktu / systemu. Pomaga w weryfikacji
gotowego produktu przed jego wyemitowaniem. Celem jest sprawdzenie, czy komponenty produktu
współgrają ze sobą, czy produkt spełnia standardy użyteczności oraz czy spełnia założenia
Porównawczy – może być stosowany do porównywania radykalnie różnych interfejsów danego pro-
duktu, mierzenia efektywności kilku pojedynczych rozwiązań, porównywania produktu z produktami
konkurencji. Celem jest określenie, które rozwiązanie jest łatwiejsze, bardziej zrozumiałe, bardziej intu-
icyjne, prostsze do wyuczenia itp. Ten rodzaj testu może być łączony z trzema pozostałymi.
Na bazie przeprowadzonych badań z użytkownikami makiety funkcjonalne są modyfikowane tak, by lepiej
spełniać oczekiwania użytkowników. Po modyfikacji następuje kolejna iteracja – testy i kolejne modyfika-
cje. Wynikiem badań i modyfikacji jest ostateczna wersja makiet funkcjonalnych serwisu. Na bazie makiet
powstaje dokumentacja produkcyjna (wdrożeniowa) serwisu. Dokumentacja opisuje kluczowe makiety,
oraz działanie poszczególnych funkcji produktu. Jest to też moment rozpoczęcia kolejnego etapu, czyli
wdrożenia produktu.
Warto także dodać, że testowanie niekoniecznie musi być przeprowadzane w sposób ściśle kontrolowany
i formalny. Są też tzw. testy korytarzowe, czyli bardzo szybkie, kilkuminutowe testy wybranych funkcji pro-
jektowanego systemu z udziałem współpracowników nie związanych z projektem przewrotnie mówiąc
„wziętych prosto z korytarza firmy”. Wyniki takiego testowania może nie będą tak pełne i reprezentatywne
jak testy formalne, lecz spojrzenie osoby z „zewnątrz” jest dużo bardziej cenne, niż kompletny brak infor-
macji zwrotnej.
4. Podsumowanie
Użyteczność to jedna z kluczowych cech produktu, która przekłada się na efektywność i wydajność wyko-
nywanych zadań, a także sprawia satysfakcję z jego korzystania. Stosowanie metodyki UCD pozwala na
zaprojektowanie wysoce użytecznego produktu, który będzie realizował potrzeby i cele użytkowników
docelowych. Wiedza na temat odbiorców produktu, a także wczesne i częste testowanie prototypu prze-
kłada się na zmniejszenie ryzyka wytworzenia produktu, który nie spełnia oczekiwań.