Projekt zorientowany na użytkownika - User-centered design

Projektowanie zorientowane na użytkownika ( UCD ) lub rozwój zorientowany na użytkownika ( UDD ) to struktura procesu (nie ograniczająca się do interfejsów lub technologii), w której podane są cele użyteczności , charakterystyka użytkownika, środowisko , zadania i przepływ pracy produktu , usługi lub procesu dużą uwagę na każdym etapie procesu projektowego . Testy te są przeprowadzane z rzeczywistymi użytkownikami lub bez nich na każdym etapie procesu, od wymagań , modeli przedprodukcyjnych i postprodukcji, kończąc krąg dowodów z powrotem i zapewniając, że „rozwój postępuje z użytkownikiem jako centrum uwagi”. Takie testowanie jest konieczne, ponieważ często bardzo trudno jest projektantom produktu zrozumieć intuicyjnie użytkowników, którzy po raz pierwszy korzystają z ich doświadczeń projektowych oraz jak może wyglądać krzywa uczenia się każdego użytkownika . Projektowanie zorientowane na użytkownika opiera się na zrozumieniu użytkownika, jego potrzebach, priorytetach i doświadczeniach, a kiedy jest używane, prowadzi do zwiększonej użyteczności i użyteczności produktu, ponieważ zapewnia satysfakcję użytkownikowi.

Główną różnicą w porównaniu z innymi filozofiami projektowania produktu jest to, że projektowanie zorientowane na użytkownika próbuje zoptymalizować produkt wokół tego, jak użytkownicy mogą, chcą lub muszą korzystać z produktu, aby użytkownicy nie byli zmuszani do zmiany swojego zachowania i oczekiwań w celu dostosowania produktu. Użytkownicy stoją więc w środku dwóch koncentrycznych kręgów. Krąg wewnętrzny obejmuje kontekst produktu, cele jego rozwoju i środowisko, w którym będzie działał. Krąg zewnętrzny zawiera bardziej szczegółowe szczegóły dotyczące szczegółów zadania, organizacji zadań i przepływu zadań.

Historia

Termin „projekt zorientowany na użytkownika” został ukuty przez Roba Klinga w 1977 roku, a później został przyjęty w laboratorium badawczym Donalda A. Normana na Uniwersytecie Kalifornijskim w San Diego . Koncepcja ta stała się szeroko popularna dzięki opublikowaniu w 1986 roku książki User-Centered System Design: New Perspectives on Human-Computer Interaction . Koncepcja zyskała dalszą uwagę i akceptację w przełomowej książce Normana The Design of Everyday Things (pierwotnie zatytułowanej The Psychologia Rzeczy Codziennych ). W tej książce Norman opisuje na przykładach psychologię stojącą za tym, co uważa za „dobry” i „zły” projekt. Podkreśla znaczenie designu w naszym codziennym życiu i konsekwencje błędów spowodowanych złymi projektami.

Obie książki zawierają zasady budowania dobrze zaprojektowanych produktów. Jego zalecenia opierają się na potrzebach użytkownika, pozostawiając na boku to, co uważa za drugorzędne kwestie, takie jak estetyka. Najważniejsze z nich to:

Uproszczenie struktury zadań tak, aby możliwe działania w dowolnym momencie były intuicyjne.
Uwidaczniaj rzeczy, w tym model koncepcyjny systemu, działania, wyniki działań i informacje zwrotne.
Uzyskiwanie właściwych mapowań między zamierzonymi wynikami a wymaganymi działaniami.
Obejmowanie i wykorzystywanie ograniczeń systemów

W późniejszej książce „ Emotional Design” Norman powraca do niektórych swoich wcześniejszych pomysłów, aby rozwinąć to, co uznał za nadmiernie redukujące.

Modele i podejścia

Na przykład proces projektowania zorientowanego na użytkownika może pomóc projektantom oprogramowania w osiągnięciu celu, jakim jest produkt zaprojektowany dla ich użytkowników. Wymagania użytkownika są brane pod uwagę od samego początku i włączane do całego cyklu produktu. Wymagania te są odnotowywane i dopracowywane za pomocą metod badawczych, w tym: badań etnograficznych, badania kontekstowego , testowania prototypów, testowania użyteczności i innych metod. Można również stosować metody generatywne, w tym: sortowanie kart , diagramowanie powinowactwa i sesje projektowania partycypacyjnego. Ponadto wymagania użytkownika można wywnioskować na podstawie dokładnej analizy użytecznych produktów podobnych do projektowanego produktu.

Design zorientowany na użytkownika czerpie inspirację z następujących modeli:

Projektowanie kooperacyjne : angażowanie projektantów i użytkowników na równych zasadach. To skandynawska tradycja projektowania artefaktów IT, która ewoluuje od 1970 roku. Nazywa się to również Co-design .
Projektowanie partycypacyjne (PD), północnoamerykańskie określenie tej samej koncepcji, inspirowane projektowaniem kooperacyjnym, skupiające się na uczestnictwie użytkowników. Od 1990 roku odbywa się co dwa lata Konferencja Projektowania Partycypacyjnego.
Projektowanie kontekstowe , „projektowanie zorientowane na klienta” w rzeczywistym kontekście, w tym niektóre pomysły z projektu partycypacyjnego

Oto zasady, które pomagają w zapewnieniu, że projekt jest skoncentrowany na użytkowniku:

Projekt opiera się na wyraźnym zrozumieniu użytkowników, zadań i środowisk.
Użytkownicy są zaangażowani w projektowanie i rozwój.
Projekt jest napędzany i udoskonalany przez ocenę skoncentrowaną na użytkowniku.
Proces jest iteracyjny.
Design odnosi się do całego doświadczenia użytkownika.
Zespół projektowy obejmuje multidyscyplinarne umiejętności i perspektywy.

Proces projektowania zorientowany na użytkownika

Celem projektowania User-Centered jest tworzenie produktów o bardzo wysokiej użyteczności . Obejmuje to, jak wygodny jest produkt pod względem jego użytkowania, łatwości zarządzania, skuteczności oraz tego, jak dobrze jest on zmapowany do wymagań użytkownika. Poniżej znajdują się ogólne fazy procesu projektowania zorientowanego na użytkownika:

Określ kontekst użytkowania : określ, kim są główni użytkownicy produktu, dlaczego będą go używać, jakie są ich wymagania i w jakim środowisku będą go używać.
Określ wymagania : Po określeniu kontekstu nadszedł czas na określenie szczegółowych wymagań produktu. Jest to ważna faza, która może jeszcze bardziej ułatwić projektantom tworzenie scenorysów i wyznaczanie ważnych celów, aby produkt odniósł sukces.
Twórz rozwiązania projektowe i rozwój : w oparciu o cele i wymagania produktu rozpocznij iteracyjny proces projektowania i rozwoju produktu.
Oceń produkt : projektanci produktów przeprowadzają testy użyteczności, aby uzyskać opinie użytkowników na temat produktu na każdym etapie projektowania zorientowanego na użytkownika.

W kolejnych krokach powyższa procedura jest powtarzana w celu dalszego wykończenia produktu. Te fazy to ogólne podejścia i czynniki, takie jak cele projektowe, zespół i ich harmonogram oraz środowisko, w którym produkt jest rozwijany, określają odpowiednie fazy dla projektu i ich kolejność. Można też śledzić Model kaskadowy , zwinny model lub jakiegokolwiek innego inżynierii oprogramowania praktyki.

Cel, powód

UCD zadaje pytania dotyczące użytkowników oraz ich zadań i celów, a następnie wykorzystuje wyniki do podejmowania decyzji dotyczących rozwoju i projektowania. UCD witryny internetowej, na przykład, stara się odpowiedzieć na następujące pytania:

Kim są użytkownicy serwisu?
Jakie są zadania i cele użytkowników?
Jakie są poziomy doświadczenia użytkowników ze stroną internetową i podobnymi stronami internetowymi?
Jakich funkcji potrzebują użytkownicy ze strony internetowej?
Jakich informacji mogą potrzebować użytkownicy iw jakiej formie?
Jak zdaniem użytkowników witryna powinna działać?
W jakich ekstremalnych środowiskach można uzyskać dostęp do strony internetowej?
Czy użytkownik pracuje wielozadaniowo?
Czy interfejs wykorzystuje różne tryby wprowadzania, takie jak dotyk, mowa, gesty lub orientacja?

Elementy

Jako przykład punktów widzenia UCD, podstawowymi elementami UCD strony internetowej są zwykle względy widoczności, dostępności, czytelności i języka.

Widoczność

Widoczność pomaga użytkownikowi zbudować mentalny model dokumentu. Modele pomagają użytkownikowi przewidzieć efekt(y) jego działań podczas korzystania z dokumentu. Ważne elementy (takie jak te, które ułatwiają nawigację ) powinny być akcentowane. Użytkownicy powinni być w stanie na pierwszy rzut oka stwierdzić, co mogą, a czego nie mogą zrobić z dokumentem.

Dostępność

Użytkownicy powinni mieć możliwość szybkiego i łatwego wyszukiwania informacji w całym dokumencie, niezależnie od jego długości. Użytkownikom należy oferować różne sposoby wyszukiwania informacji (takie jak elementy nawigacyjne, funkcje wyszukiwania, spis treści, wyraźnie oznaczone sekcje, numery stron, kodowanie kolorami itp.). Elementy nawigacyjne powinny być zgodne z gatunkiem dokumentu. „ Chunking ” jest użyteczną strategią, która polega na dzieleniu informacji na małe kawałki, które można uporządkować w jakiś znaczący porządek lub hierarchię . Możliwość przejrzeć dokument pozwala użytkownikom odnaleźć fragment informacji poprzez skanowanie zamiast czytania. W tym celu często używa się słów pogrubionych i pisanych kursywą .

Czytelność

Tekst powinien być łatwy do odczytania: Poprzez analizę sytuacji retorycznej projektant powinien być w stanie określić przydatną rodzinę czcionek i styl czcionki . Czcionki ozdobne, tekst pisany wielkimi literami , duży lub mały tekst główny mogą być trudne do odczytania i należy ich unikać. Kolorowanie tekstu i pogrubienie mogą być przydatne w scenariuszach z dużą ilością tekstu. Wysoki kontrast między tekstem a tłem zwiększa czytelność. Najbardziej czytelny jest ciemny tekst na jasnym tle.

Język

W zależności od sytuacji retorycznej potrzebne są pewne rodzaje języków . Pomocne są krótkie zdania, podobnie jak dobrze napisane teksty używane w wyjaśnieniach i podobnych sytuacjach związanych z tekstem masowym. O ile sytuacja tego nie wymaga, nie należy używać żargonu ani terminów mocno technicznych. Wielu pisarzy zdecyduje się na użycie głosu czynnego , czasowników (zamiast ciągów rzeczownikowych lub rzeczowników ) i prostej struktury zdań.

Narzędzia analityczne

Istnieje szereg narzędzi, które są wykorzystywane w analizie User-Centered Design, głównie: persony, scenariusze i istotne przypadki użycia.

Osoba

Podczas procesu UCD można utworzyć Personę reprezentującą użytkownika. Persona jest archetyp użytkownika używane, aby pomóc decyzje dotyczące cech produktu, nawigacji, interakcji, a nawet projektowania wizualnego. W większości przypadków persony są syntetyzowane z serii wywiadów etnograficznych z prawdziwymi ludźmi, a następnie uchwycone w 1-2-stronicowych opisach, które obejmują wzorce zachowań, cele, umiejętności, postawy i środowisko, z kilkoma fikcyjnymi danymi osobowymi, aby przybliżyć personę do życie.

Dla każdego produktu, a czasem dla każdego zestawu narzędzi w produkcie, istnieje mały zestaw person, z których jedna jest głównym celem projektu. Istnieje również tak zwana persona drugorzędna , w której postać nie jest głównym celem projektu, ale w miarę możliwości należy zaspokoić jej potrzeby i rozwiązać problemy. Istnieją, aby pomóc wyjaśnić dalsze możliwe problemy i trudności, które mogą wystąpić, nawet jeśli pierwotna osoba jest zadowolona z ich rozwiązania. Jest też anty-persona , czyli postać, dla której projekt nie jest specjalnie stworzony.

Persony są przydatne w tym sensie, że tworzą wspólne wspólne rozumienie grupy użytkowników, wokół której budowany jest proces projektowania. Pomagają również w ustaleniu priorytetów rozważań projektowych, zapewniając kontekst tego, czego potrzebuje użytkownik i jakie funkcje po prostu warto dodać i mieć. Mogą również zapewnić ludzką twarz i egzystencję zróżnicowanej i rozproszonej grupie użytkowników oraz pomóc w wytworzeniu empatii i dodaniu emocji w odniesieniu do użytkowników. Ponieważ jednak persony są uogólnionym postrzeganiem głównej grupy interesariuszy na podstawie zebranych danych, charakterystyka może być zbyt szeroka i typowa lub może za bardzo przypominać „przeciętnego Joe”. Czasami persony mogą mieć również cechy stereotypowe, co może zaszkodzić całemu procesowi projektowania. Ogólnie rzecz biorąc, persony mogą być przydatnym narzędziem, z którego mogą korzystać projektanci do podejmowania świadomych decyzji projektowych, w przeciwieństwie do odwoływania się do zestawu danych lub szerokiego zakresu osób.

Persony można również modyfikować przez cały UCD produktu, w oparciu o testy użytkowników i zmieniające się środowisko. Nie jest to idealny sposób korzystania z Person, ale nie powinien być też tematem tabu, zwłaszcza gdy staje się jasne, że zmienne otaczające rozwój produktu zmieniły się od czasu rozpoczęcia projektu, a obecne persony mogą nie odpowiadać dobrze zmienionym warunkom.

Scenariusz

Scenariusz stworzony w procesie UCD to fikcyjna opowieść o „życiu codziennym” lub sekwencji zdarzeń z pierwotnej grupy interesariuszy w roli głównej. Zazwyczaj głównym bohaterem tej historii jest postać, która została stworzona wcześniej. Historia powinna być konkretna w odniesieniu do wydarzeń, które mają związek z problemami podstawowej grupy interesariuszy, a zwykle główne pytania badawcze, na których opiera się proces projektowania. Mogą się one okazać prostą opowieścią o codziennym życiu jednostki, ale drobne szczegóły z wydarzeń powinny sugerować szczegóły dotyczące użytkowników i mogą obejmować cechy emocjonalne lub fizyczne. Może istnieć najlepszy scenariusz , w którym wszystko działa najlepiej dla głównego bohatera, najgorszy scenariusz , w którym główny bohater doświadcza, że wszystko wokół niego idzie nie tak, oraz przeciętny scenariusz , który jest typowym życiem jednostki, gdzie nie dzieje się nic naprawdę szczególnego ani naprawdę przygnębiającego, a dzień po prostu mija.

Scenariusze tworzą kontekst społeczny, w którym istnieją persony, a także tworzą rzeczywisty świat fizyczny, zamiast wyobrażać sobie postać o cechach wewnętrznych z zebranych danych i niczego więcej; jest więcej działań związanych z istnieniem persony. Scenariusz jest również łatwiej zrozumiały dla ludzi, ponieważ ma formę opowieści i jest łatwiejszy do naśladowania. Jednak, podobnie jak persony, scenariusze te są założeniami badacza i projektanta, a także są tworzone z zestawu uporządkowanych danych. Ważne jest, aby scenariusze były tworzone jak najbliżej scenariuszy ze świata rzeczywistego. Niemniej jednak czasami może być trudno wyjaśnić i poinformować, jak przebiegają zadania niskiego poziomu, na przykład proces myślowy osoby przed działaniem.

Przypadek użycia

Krótko mówiąc, przypadek użycia opisuje interakcję między jednostką a resztą świata. Każdy przypadek użycia opisuje zdarzenie, które może wystąpić przez krótki czas w prawdziwym życiu, ale może składać się ze skomplikowanych szczegółów i interakcji między aktorem a światem. Jest reprezentowany jako seria prostych kroków dla postaci, aby osiągnąć swój cel, w formie schematu przyczynowo-skutkowego. Przypadki użycia są zwykle zapisywane w postaci wykresu z dwiema kolumnami: pierwsza kolumna oznaczona jako aktor , druga kolumna oznaczona jako świat , a działania wykonywane przez każdą ze stron są zapisane w kolejności w odpowiednich kolumnach. Poniżej znajduje się przykład użycia do wykonania utworu na gitarze przed publicznością.

Aktor	Świat
wybierz muzykę do odtworzenia
podnieś gitarę
	wyświetl nuty
wykonać każdą nutę na nutach za pomocą gitary
	przekazać notatkę publiczności za pomocą dźwięku
	publiczność przekazuje wykonawcy informację zwrotną
ocenić wydajność i dostosować w razie potrzeby na podstawie opinii publiczności.
kompletny utwór z wymaganymi poprawkami
	brawa publiczności

Interakcja między aktorem a światem jest czynnością, którą można zobaczyć w życiu codziennym, przyjmujemy to za pewnik i nie zastanawiamy się zbytnio nad drobnymi szczegółami, które muszą się wydarzyć, aby takie działanie jak wykonanie utworu muzycznego istnieć. Podobnie jest z tym, że mówiąc językiem ojczystym nie myślimy zbytnio o gramatyce i sposobach frazowania słów; po prostu wychodzą, ponieważ jesteśmy tak przyzwyczajeni do ich wypowiadania. Działania między aktorem a światem, w szczególności głównym interesariuszem (użytkownikiem) i światem w tym przypadku, powinny być szczegółowo przemyślane, a zatem tworzone są przypadki użycia, aby zrozumieć, jak zachodzą te drobne interakcje.

Istotnym przypadkiem użycia jest specjalny rodzaj przypadku użycia, zwany także abstrakcyjnym przypadkiem użycia . Niezbędne przypadki użycia opisują istotę problemu i dotyczą natury samego problemu. Pisząc podstawowe przypadki użycia, nie należy przyjmować żadnych założeń dotyczących niepowiązanych szczegółów. Ponadto cele podmiotu powinny być oddzielone od procesu i realizacji, aby osiągnąć ten konkretny cel. Poniżej znajduje się przykład istotnego przypadku użycia o tym samym celu, co w poprzednim przykładzie.

Aktor	Świat
wybierz nuty do wykonania
gromadzi niezbędne zasoby
	zapewnia dostęp do zasobów
wykonuje utwór sekwencyjnie
	przekazuje i interpretuje wykonanie
	zapewnia informacje zwrotne
kończy występ

Przypadki użycia są przydatne, ponieważ pomagają zidentyfikować przydatne poziomy prac projektowych. Pozwalają projektantom zobaczyć rzeczywiste procesy niskiego poziomu, które są zaangażowane w dany problem, co ułatwia obsługę problemu, ponieważ niektóre drobne kroki i szczegóły wprowadzone przez użytkownika są ujawniane. Zadaniem projektantów powinno być wzięcie pod uwagę tych małych problemów w celu uzyskania ostatecznego rozwiązania, które działa. Innym sposobem na powiedzenie tego jest to, że przypadki użycia dzielą skomplikowane zadania na mniejsze bity, gdzie te bity są użytecznymi jednostkami. Każdy bit wykonuje małe zadanie, które następnie przeradza się w ostateczne większe zadanie. Podobnie jak w przypadku pisania kodu na komputerze, łatwiej jest napisać podstawowe mniejsze części i sprawić, by najpierw działały, a następnie złożyć je razem, aby ukończyć większy, bardziej skomplikowany kod, zamiast zająć się całym kodem od samego początku.

Pierwsze rozwiązanie jest mniej ryzykowne, ponieważ jeśli coś pójdzie nie tak z kodem, łatwiej jest szukać problemu w mniejszych bitach, ponieważ segment z problemem będzie tym, który nie zadziała, natomiast w drugim rozwiązaniu programista może być zmuszony do przejrzenia całego kodu w poszukiwaniu pojedynczego błędu, co okazuje się czasochłonne. To samo rozumowanie dotyczy pisania przypadków użycia w UCD. Wreszcie przypadki użycia przekazują przydatne i ważne zadania, w których projektant może teraz zobaczyć, które z nich są ważniejsze niż inne. Niektóre wady pisania przypadków użycia obejmują fakt, że każda akcja aktora lub świata zawiera niewiele szczegółów i jest po prostu małą akcją. Może to prowadzić do dalszej wyobraźni i innej interpretacji działań różnych projektantów.

Również w trakcie procesu bardzo łatwo jest nadmiernie uprościć zadanie, ponieważ małe zadanie wywodzące się z większego zadania może nadal składać się z jeszcze mniejszych zadań, które zostały pominięte. Podnoszenie gitary może wiązać się z zastanowieniem się, którą gitarę podnieść, której kostki użyć i najpierw zastanowić się, gdzie znajduje się gitara. Zadania te można następnie podzielić na mniejsze zadania, takie jak najpierw zastanowienie się, jaki kolor gitary pasuje do miejsca, w którym ma być wykonany utwór, i inne powiązane szczegóły. Zadania mogą być podzielone na jeszcze mniejsze zadania, a projektant musi określić, jakie jest odpowiednie miejsce, w którym można przestać dzielić zadania. Zadania mogą nie tylko być nadmiernie uproszczone, ale mogą być również pominięte w całości, dlatego projektant powinien mieć świadomość wszystkich szczegółów i wszystkich kluczowych kroków, które są związane ze zdarzeniem lub działaniem podczas pisania przypadków użycia.

Languages

In other projects