projektowanie uzytecznych produ Nieznany

background image

UNIA EUROPEJSKA

EUROPEJSKI FUNDUSZ

ROZWOJU REGIONALNEGO

Projektowanie użytecznych

produktów

Jakub Andrzejewski

background image

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.

background image

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

background image

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

background image

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.

background image

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.

background image

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

background image

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.

background image

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

background image

Wyszukiwarka

Podobne podstrony:
9 PROJEKTOWANIE SYSTEMOW PRODU Nieznany
projekty 3 id 400866 Nieznany
kse projekt id 252149 Nieznany
projekt inzynierski wskazowki w Nieznany
projekt29 id 400291 Nieznany
projektMOS id 400412 Nieznany
Projektowanie zwrotnic glosniko Nieznany (3)
Projekt zaliczeniowy Sprawozdan Nieznany
07 projektowanie skladuid 6941 Nieznany (2)
projektowanie 2 id 400443 Nieznany
Projekt 7 A id 398367 Nieznany
projekt0002 id 400180 Nieznany
Projekt 6 id 397770 Nieznany
Omowienie projektu id 335352 Nieznany
projekt z eksploatacji technol Nieznany
projekt mieszalnika Politechnik Nieznany
notatek pl projekt drogi przykl Nieznany
imw w03 narzedzia poprawy produ Nieznany

więcej podobnych podstron