Poznańskie spotkania UX Books mają nieco inną formułę, niż spotkania wrocławskie lub warszawskie. Chcemy pójść za głosem ludu i być może dyskutować o sprawach nie tylko bezpośrednio związanych z użytecznością. Chcemy poruszać tematy związane również z reklamą w sieci, prowadzeniem własnych projektów e-biznesowych, pozyskiwaniem funduszy na własne przedsięwzięcia, aspektami technologicznymi.

Założyliśmy również grupę na goldenline poświęconą spotkaniom UX books w Poznaniu.

Najbliższe spotkanie odbędzie się:

miejsce: Idea Park biuro co-workingowe, ul. Grottgera 16

termin: 16 lutego, godzina 19

cel spotkania: omówienie jednej z książek – wciąż wybieramy jaka będzie to książka, dzielimy się doświadczenie i każdy wychodzi z nowymi pomysłami i inspiracjami ze spotkania

Zapraszamy wszystkich chętnych, nawet jeśli nic nie wiesz na temat użyteczności, albo jesteś w zupełnie innej branży, ale masz ochotę przyjść to nic nie stoi na przeszkodzie. Dajcie znać swoim znajomym spotkaniu.

naturalne środowisko użytkownika

Najnowsze nurty w badaniach kognitywistycznych świadczą o tym,  że percepcja nie służy temu, by wiedzieć, ale temu by sprawnie działać. Stąd tak duży nacisk, by projektowane serwisy i aplikacji przede wszystkim jasno komunikowały  co można za ich pomocą zrobić. Dla właściciela witryny jest to korzystne, a dla użytkownika naturalne, by coś kliknąć, włączyć, wpisać itp.

Współczesne pytania o to jak poznajemy i skutecznie działamy, przynoszą odpowiedź, że nasze poznanie jest ucieleśnione (embodied cognition) i zanurzone w świecie. Nasze myślenie nie jest funkcją samego mózgu, ale charakter nadaje mu to jak się poruszamy i działamy. Najlepszym tego dowodem są metafory w naszym języku np. dotyczące Internetu – poruszamy się po nim, szukamy w nim, surfujemy, odwiedzamy, nawigujemy. Aby zatem w pełni zrozumieć jak użytkownicy podejmują decyzje potrzebujemy szerokiego spojrzenia na kontekst ich działania.

Na pewno znane jest Tobie pojęcie analizy zadań (task analysis), czyli obserwacja jak ludzie wykonują zadania – ile wykonali i w jakim stopniu.  Jej ciekawe rozszerzenie proponuje Frank Spiller, specjalista ds. użyteczności, kognitywista, autor idei Cognitive archeology, której głównym założeniem jest badanie aktywności użytkowników w ich naturalnym środowisku korzystania z Sieci.

Jakie są główne techniki tej metody?

• wywiady kontekstowe – to nie osoby przychodzą na badanie, ale badanie prowadzone jest tam, gdzie użytkownicy pracują i korzystają z Internetu – w miejscu pracy, na uczelni, w kawiarni z WiFi. Dzięki temu procesy kognitywne użytkownika są pod normalnym wpływem poznawczych artefaktów czyli np. żółtych karteczek przyklejonych do monitora.
• analiza zadania – obserwacja użytkownika i identyfikacja kontekstu użycia – czy stosowane są  skróty klawiszowych, praca na zakładkach, jakiego rodzaju aplikacje dodatkowo są uruchomione oraz ilości błędów,  szybkości i kompletności wykonania.
• diary studies -  nie wszystkie istotne spostrzeżenia użytkownika
  

  diary studies

  mogą być zarejestrowane przez badacza. Dlatego warto dać osobie badanej kartki papieru na których będzie mogła zapisać swoje obserwacje, wrażenia czy uwagi.
  

Metody analizy danych

• affinity diagrams – metoda wizualizacji pozwalającą określać za pomocą małych kartek relacje i zgrupowania np. pomysłów powstałych podczas burzy mózgów czy spostrzeżeń z notatek użytkownika
• task flow - obrazowanie akcji użytkownika, akcji systemu i ich wzajemnej interakcji za pomocą ustandaryzowanych schematów np. za pomocą UML.

• scenariusze – synteza obserwacji użytkownika, która pozwala wyjaśniać przebieg wykonania zadania i wyciągać wnioski dotyczące możliwych usprawnień czynności użytkownika ze strony projektowanego interfejsu

Więcej o badaniu kontekstu możesz przeczytać w artykule Task Analysis through Cognitive Archeology (PDF), który ukazał się jako rozdział książki The Handbook of Task Analysis for HCI.

Dobry interfejs to dobre narzędzie dla użytkownika.  Taki narzędzie powinno wspierać i rozszerzać możliwości poznawcze użytkownika tak jak młotek jest artefaktem wydłużającym możliwości dłoni, a okulary możliwości oka.  Zauważ, że jest w tym miejsce dla realizacji celów biznesowych Twojego projektu. Jeśli poznasz kontekst działania twojego użytkownika, zrozumiesz jak podejmuje decyzje. Z naukowych teorii czasami coś ciekawego wynika, czyż nie?

Co prawda firmy produkujące takie programy, mają w swoim budżecie środki na testowanie User Experience, to jednak jest to wciąż raczej modny dodatek, niż rzeczywisty proces usprawniania aplikacji. Problemy z użytecznością ERP dotyczą m.in.

Problemy techniczne:

Skomplikowanie

Wysoki poziom skomplikowania aplikacji, która zawiera wiele różniących się od siebie funkcjonalności, skierowanych do różnych, bywa, że o odmiennych interesach, grup użytkowników w firmie.

Wiele funkcjonalności

Duża liczba funkcjonalności, ma to swoje uzasadnienie, zarówno praktyczne jak i marketingowe, nawet fachowcy wolą mieć więcej niż mniej w tej samej, albo podobnej cenie. Nawet, jeżeli więcej oznacza większe problemy z użytecznością, i jest mało przydatne w firmie.

Różne grupy użytkowników

Odmienne grupy użytkowników w ramach firmy, do których adresowane jest oprogramowanie. Systemy tego typu, muszą często godzić interesy wielu grup począwszy od księgowości, a skończywszy na handlu, dostosowanie aplikacji do wymagań każdej z grup oznacza dodatkowe koszty.

Monolityczny charakter aplikacji

Monolityczny charakter oprogramowania ERP, czyli produkcja softu poprzez dodawanie kolejnych zależnych od siebie modułów, gdzie zmiana w jednym module pociąga za sobą zmiany w innych modułach. Z uwagi na licznie dobudowywane w czasie funkcjonalności, które nie zawsze dobrze działają w jednym środowisku powstaje coś na kształt domku z kart, gdzie każda mniejsza zmiana pociąga za sobą konieczność zmian większych w innych obszarach. Stąd też problem z szybką implementacją UCD w procesie produkcyjnym.

Przeszkody biznesowe:

Ostateczny nabywca

Oprogramowanie ERP, w przeciwieństwie do serwisów WWW, kuchenek mikrofalowych, czy telewizorów kupowane jest przez dyrektorów i kierowników działów. Fachowców w swojej dziedzinie. W przeciwieństwie do zwykłego Kowalskiego, dla którego ma znaczenie to czy pralka ma czytelny interface, albo strona użyteczny formularz, fachowiec na wysokim stanowisku użyteczność traktuje jako marginalne kryterium przy wyborze oprogramowania. Dla niego ważniejsza jest liczba funkcjonalności, szybkość przesyłu danych, możliwości techniczne oprogramowania . W zasadzie nie zwraca się uwagi na to jak dużo firma straci w związku z długimi (płatnymi) rzecz jasna szkoleniami swoich pracowników.

Powstający rynek

Rynek oprogramowania, o którym dowiedziałem się dużo rozmawiając z szefem ds. wdrożeń w jednej z większych firm tego typu w Polsce, jest wciąż w etapie początkowym. Firmy, co prawda szybko i wiele kupują, implementacji jest dużo, ale w przeciwieństwie do zachodnich sąsiadów użyteczność wciąż nie stanowi o uzyskaniu przewagi konkurencyjnej. Użyteczność WWW, rozwinęła się na dobre w okresie, kiedy, na e-rynku powstało wiele silnych przedsięwzięć, które konkurując ze sobą po pewnym czasie sięgnęły po użyteczność, jako narzędzie budowania przewagi konkurencyjnej. Rynek ERP’ów nie jest jeszcze w takim stadium zaawansowania, żeby korzystanie z użyteczności stanowiło sposób budowy przewag ekonomicznych. Zatem musi minąć jeszcze trochę czasu.

W skrócie sytuacja na Zachodzie wygląda teraz tak:

Vendors of enterprise and manufacturing software are beginning to respond to customers’ calls for applications that can be more easily used by a wider audience of employees across the enterprise. After spending years focusing primarily on winning the race to add more features and functionality to their products, vendors such as SAP, Oracle, Epicor, IFS, GE Fanuc, Wonderware, and Rockwell are beginning to focus more of their resources on enhancing the user experience. Employing a wide range of emerging technologies — including service-oriented architectures and Web 2.0 tools such as AJAX — vendors are rolling out a host of innovations that, in addition to Microsoft Office integration, include interfaces tailored for people in specific functional roles, contextual search, and even visualization.

The User Interface Revolution(Easy as Pie)

Tak z kolei działa IFS – dostarczyciel oprogramowanie ERP.

In an effort to understand how IFS could modify our products to enhance usability and increase our customers’ productivity, in late 2007 we performed a study of 250 IFS customers and 100 non-IFS customers. When asked to name the main barriers to productivity within their ERP packages, the top source of non-value-added time, the non-IFS customers said the top challenge they faced was the fact that different parts of their system worked in different ways, had different commands and required different types of interaction. The second most frequent response by the non-IFS customers was that difficulty in transferring information between parts of applications was a problem. We are proud to say that IFS customers did not complain about these two things to the same extent as other respondents, likely because we have always worked to present a consistent user experience across our applications, and to ensure that context-sensitive information follows a user from one functional area to another.

IFS White Paper

Świadomość użytkowników oprogramowania

Jednym słowem przeciętni pracownicy w firmie, nie są zainteresowani otrzymywaniem narzędzi bardziej poręcznych i mniej frustrujących. Wpływa na postawa szefów oraz przyzwyczajenie do tego, że ERP musi być trudny i mało wydajny w początkowym okresie korzystania z niego.

Zyski firm produkujących oprogramowanie

Z biznesowego punktu widzenia inwestowanie w użyteczność zwiększa jedynie koszty produkcji oprogramowania, nie zapewniając jednocześnie dostatecznego zwrotu z tej inwestycji. Kto, jak kto, ale firmy produkujące takie systemy same wiedzą najlepiej, na jakich procesach zaoszczędzić, dotyczy to właśnie UCD, a wynika między innymi z poziomu rozwoju rynku i stosunku kadry zarządzającej i klientów do oprogramowania ERP.

Co zrobić by móc wejść z użyteczności ą w rynek ERP?

1. Pisać o tym jak bardzo użyteczność jest ważna – mamy na wyciagnięcie reki przykłady zachodnie, starajmy się krzewić tą wiedzę, tak samo jak do tej pory krzewiono wiedzę z zakresu Web Usability.
2. Prowadzić badania – ktoś musi w końcu podjąć się wysiłku przetestowania aplikacji ERP i sprawdzenia jak różne wdrożenia wpływają na kwestie związane z użytecznością.
3. Spotykać się z ludźmi projektującymi ERP, badać rynek, dowiadywać się jak funkcjonuje proces produkcji softu i w którym etapie najlepiej zastosować testy by były racjonalne z biznesowego punktu widzenia.
4. Liczyć na to, że rynek będzie rósł i że użyteczność decydować będzie o zyskaniu przewagi konkurencyjnej.
5. Uczyć się nowych metod testowania, field studies, badań ilościowych – szczególnie dobrze widziane przez technicznych fachowców.

Co dalej?

Specjaliści twierdzą, że skomplikowane, monolityczne systemy ERP są skazane na ewolucję i dostosowanie się do zmian użytkowania oprogramowania przez użytkowników. Presja sieci wciąż będzie rosła, czego dowodem jest rozpowszechnianie się usług „Cloud Computing’owych”, do których pełny dostęp realizowany jest poprzez przeglądarkę WWW. Rozwijanie usług „Cloud Computing’owych” wpływać będzie na zmiany samego modelu projektowania i działania ERP, jako dużych sformalizowanych implementacji po stronie serwerów klienta w ramach jego infrastruktury.

Zapewne opracowywanie odrębnych interface’ów w ramach tego samego systemu ale różnych grup odbiorców wymagać będzie nowego podejścia do pracy z ekranem roboczym, skupienia uwagi na wielu zmiennych, segregowaniem różnych kanałów informacji. Pomocne okażą się tutaj doświadczenia projektantów OS.

Linki zewnętrzne:

1. Jeśli ktoś ma ochotę dowiedzieć się jak powstaje ERP i może nawet zostać projektantem systemów. Niestety pełny dostęp możliwy jest dla zarejestrowanych użytkowników.  SOP SAP
2. Krótko o użyteczności ERP w firmie SAP: Providing a Web-Like User Experience to Business Users,  The New SAP CRM Web Client User Interface
3. CFO, ERP make easy
4. IDENTIFYING USABILITY ISSUES WITH AN ERP IMPLEMENTATION

Sam pracując w Symetrii miałem okazję uczestniczyć w tego typu badaniach i współpracować z prawdziwym ekspertem w tej dziedzinie, Piotrem Jardanowskim, kierującym działem badań w poznańskiej agencji.

Już na etapie przystępowania do konstrukcji scenariusza badania, pojawiają się pytania, na które trzeba odpowiedzieć, by nasze badanie miało jakikolwiek sens i znaczenie. Pytania te dotyczą przede wszystkim ilości badanych, sposobu doboru próby, kształtu samego scenariusza badania, stopnia zaangażowania badacza w proces badania. Artykuł ten stanowi pierwszą część, większego cyklu artykułów na temat wykorzystania narzędzi statystycznych w przeprowadzaniu i analizie wyników badań z użytkownikami.

Pisząc ten artykuł w dużym stopniu, opieram się na własnych doświadczeniach, wiedzy o statystyce opisowej, opracowaniach branżowych, z których jedno pełni rolę pierwszoplanową, mianowicie – Measuring the User Experience Collecting, Analyzing, and Presenting Usability Metrics (Interactive Technologies), Toma Tullisa i Billa Alberta.

Czym są miary?

Miara to sposób na zmierzenie/określenie wartości danego zjawiska. Miarą długości może być metr, kilometr albo cal, za pomocą miar jesteśmy w stanie porównywać określone rzeczy i wyliczać związki między nimi. O ile dłuższa odległość A od odległości B w metrach. Miary stosowane w badaniach użyteczności muszą spełniać kilka warunkach by były poprawne:

Stosowane miary użytecznością muszą być:

• Związane z interakcją między systemem, a użytkownikiem, muszą badać ludzkie zachowania i motywacje w trackie interakcji z aplikacją.
• Zaobserwowane – wystarczy określenie czy np. zadanie zostało wykonane, albo jaki był czas wykonania zadania.
• Obliczalne, każdy wynik musi być przedstawiony w postaci liczbowej.

Sam prowadząc projekty często słyszałem od swoich klientów pytanie o możliwość rzutowania wyników z badania użyteczności na populację. Jednak populacja określona przy tych projektach zwykle była bardzo szeroka – co najmniej kilka milionów osób, zatem możliwość wnioskowania o populacji na podstawie badań na kilku użytkowników nie była możliwa, (opatrzona byłaby zbyt dużym błędem). O możliwości rzutowania wyników na populację, czyli m.in. określaniu przedziałów ufności otrzymanych wyników mowa będzie później.

Wielkość próby i sposoby jej doboru

To chyba jedno z pytań, które są powszechnie zadawane w branży użyteczności. Początek rozważaniom na temat liczby potrzebnych do badania użytkowników rozpoczął zdaje się jakieś ćwierć wieku temu Jakob Nielsen. Badania mające ustalić optymalną ilość użytkowników prowadzone były co najmniej kilkukrotnie. Nigdy nie określono jednej uniwersalnej liczby użytkowników, która musi zostać zrekrutowania do badania. W zależności od badania i tego jakie rezultaty spodziewamy się uzyskać, liczba użytkowników jest zmienna. Na pewno powinniśmy się starać by nasza próbka była w miarę reprezentatywna, czyli jeśli testujemy serwis skierowany do nastolatków zainteresowanych mangą i anime, to najlepiej zrekrutować osoby w tym przedziale wiekowym z tymi konkretnie zainteresowaniami.

Stara zasada mówi, że lepiej testować serwis nawet z jednym użytkownikiem, niż w ogóle tego nie robić. Specyfika badań użyteczności, jest taka, że nawet wyniki badania z jednym użytkownikiem mogą powiedzieć badaczowi bardzo wiele na temat użyteczności testowanego systemu.

Idąc dalej, możemy określić kilka metod doboru próby, zwykle jednak albo stosujemy dobór losowy, a więc każda osoba z danej populacji ma takie same szanse by stać się naszym badanym (znaleźć się w próbce), albo (co jest znacznie powszechniejsze) – metoda określana przez Tullisa jako „sample convenience”, w zasadzie jest wygodny dobór próby poprzez np. publikację ogłoszenia, że poszukuje się uczestników do badania, którzy spełnialiby określoną w badaniu charakterystykę.

Czy oni mi zaufają? Czyli czym są przedziały ufności i poziom ufności?

Jeśli chcemy aby otrzymane przez nas wyniki były reprezentatywne dla całej badanej przez nas populacji, musimy dysponować odpowiednio dużą próbą badawczą. Jeśli nie ma znaczenia, czy nasze wyniki, są reprezentatywne, to możemy testować z kilkoma użytkownikami i nie zawracać sobie głowy liczebnością i zróżnicowaniem populacji.

Przedział ufności określa jak bardzo możesz być pewny, albo jak bardzo niepewny, że otrzymane przez ciebie wyniki z badanej próbki są reprezentatywne dla całej badanej populacji. Powiedzmy, że na 10 użytkowników, 8 wykonało zadanie, czy takie wyniki dają nam prawo do tego, by twierdzić, że 80% populacji wykona zadanie z testu. Oczywiście, że nie.

Próba reprezentatywna to taka próba, która:

• Daje podstawy do uogólnienia na cała populację
• Pozwala określić możliwy błąd przy uogólnieniu na populację
• Dobierana jest według ściśle określonych zasad
• Zazwyczaj jest dość liczna

Oto jak w swojej książce Tullis i Albert wyjaśniają znaczenia przedziałów ufności (nie mylić z poziomem ufności), w stosunku do czasu wykonania zadania.

Przykładowo załóżmy, że musisz oszacować średnią dla całej populacji i chcesz być na 95% pewny tego, że twoja wyliczona średnia jest prawidłowa. Na obrazku powyżej 95% przedział ufności wynosi powyżej 7 sekund. Oznacza to, że masz 95% pewność, że średnia realizacji zadania otrzymana w trakcie badań, czyli 35 sekund, będzie wynosi w całej populacji 35 sek. ±7, albo między 28, a 42 sek.

Wynik między 28, a 42 sek. to nasz przedział ufności. Natomiast 95% to poziom ufności, który został założony na początku, czyli stopień tego na ile jesteśmy pewni, o czymś.

Czy próba powinna być reprezentatywna?

Jeśli badana populacja to nie wszyscy użytkownicy Internetu w Polsce, a jakaś mniejsza grupa np. wcześniej wspomniani księgowi, lekarze, czy użytkownicy programów ERP, wówczas możemy się pokusić o przeprowadzenie testów użyteczności, które będą reprezentatywne. Przy mniejszej populacji, ilość badanych, czyli liczebność próby może być mniejsza niż w przypadku wszystkich Internautów, przy zachowaniu rozsądnych przedziałów ufności, przy danym poziomie ufności – powiedzmy 95% pewności. Im mniejsza populacja tym mniejsza jest potrzebna próba by móc rzutować otrzymane dane na badaną populację z danym prawdopodobieństwem (czyli poziomem ufności).

Zwykle jednak testując masowe serwisy, gdzie populacja badana to kilka milinów osób, klient nie ma ochoty płacić dodatkowych pieniędzy za przeprowadzenie badań reprezentatywnych. Czy takie reprezentatywność wyników jest konieczna, to już inna sprawa, zależy od testowanego systemu, celów badania, kosztów i życzeń klienta.

Jaką potrzebę użytkowników ma zaspokajać serwis/aplikacja

Punktem wyjścia naszych rozważań zawsze musi być jednak konkretna czynność jaką użytkownik będzie realizował w serwisie. Taka czynność jest już zwykle zdefiniowana przez klienta – powiedzmy, że mamy do zaprojektowania serwis, za pomocą, którego użytkownicy będą uploadować swoje zdjęcia. W takim wypadku czynnością, którą użytkownicy będą realizować jest utrzymywanie więzi społecznych.

O metodzie projektowania AOF, pisał Porter w książce omawianej na wrocławskich spotkaniu UX Books. Zatem wychodzimy od czynności – podtrzymywanie więzi społecznych, idziemy do konkretnej akcji jaką użytkownik musi wykonać by realizować ta czynność – upaloadowanie zdjęć, a na samym końcu określamy konkretne parametry akcji (jak będzie w praktyce wyglądać uploadująca funkcjonalność).

Przystępując do projektowania musimy mieć na uwadze zadania jakie użytkownik będzie realizował w serwisie. Tym zadaniom podporządkować cały system. Innymi słowy na samym początku musimy zaprojektować flow – przepływ informacji w systemie. Skupiamy się na akcji uploadowania zdjęć do niej dobudowujemy inne funkcjonalności na zasadzie wspomagającej lub uzupełniającej.

Skupiamy się na tym by zaprojektować jak najlepszą ścieżkę realizacji akcji przez użytkownika. Starajmy się zaprojektować swoisty lejek do którego użytkownika wpada i wykonuje zaplanowane przez nas czynności. Tyle teoria.

Rzecz jasna nie możemy przewidzieć tego w jaki sposób użytkownik będzie korzystał z naszego serwisu. Nie każdy będzie przechodził ścieżką od reklamy po stronę główną i przez kolejne zaplanowane przez nas kroki. Niektórzy użytkownicy będą trafiać w różne części naszego lejka i każdy element musi spełniać swoją rolę – napędzać konwersję. Niezależnie od tego w które miejsce trafi użytkownik, zawsze musi być dla niego jasne w jakim znajduje się serwisie, jaką potrzebę dzięki niemu może zrealizować i jak w najprostszy sposób to zrobić.

Możemy powiedzieć, że każda nasza strona jest stroną typu landing page. Dobry projektant nie tylko zaprojektuje serwis, który jest użyteczny, ale również taki, który spełnia swoje cele biznesowe. To jest probierzem dobrego projektu – zadowolenie użytkownika z powodu otrzymania świetnej aplikacji i zadowolenie klienta w postaci rosnącego konta bankowego na Kajmanach.

Etapy pracy nad projektem

• Konsultacje z klientem
• Poznanianie potrzeb grupy docelowej
• Dogłębne poznanie modelu biznesowego serwisu, oraz planów jego rozwoju, ewentualnie wprowadzenia dodatkowych form zarabiania w serwisie
• Dysponowanie wynikami badań fokusowych
• Przejrzenie aplikacji konkurencyjnych, zastosowanych w nich rozwiązań, historii serwisów konkurencyjnych
• Przeprowadzenie burzy mózgów w firmie
• Przyjęcie określonej metodologii pracy, określamy czynność jaką użytkownik realizuje, określamy wszelkie dostępne możliwości jej realizacji, te z kolei dzielimy na konkretne funkcjonalności
• Przedstawienie diagramu przepływów – pokazanie za pomocą diagramu UML jak będzie przebiegać realizowanie celów w serwisie przez użytkownika
• Wybranie najlepszych funkcjonalności – dysponując wcześniejszymi projektami możemy sobie zaoszczędzić wiele pracy
• Przystąpienie do sporządzenia projektu funkcjonalnego – ja polecam Axure jako najlepsze obecnie narzędzie do prototypowania

Najbardziej istotnym elementem w pierwszej fazie projektowania jest poznanie użytkowników dla których projektujemy system. Możemy tutaj albo konsturować persony, albo poznać bardziej dogłębnie grupę docelową do której kierowana jest aplikacja. Testy fokusowe przyczyniają się do określenia modeli mentalnych przyszłych użytkowników aplikacji. Pod tą dziwnie brzmiącą nazwą kryje się odpowiedź na pytanie jak użytkownicy myślą, w jaki sposób podejmują decyzje, rozwiązujaą problemy w codziennym życiu. System pozwala na prostsze rozwiązywanie określonych problemów jakie pojawiają się w codziennym życiu użytkownika. Projektanci muszą zgłębić dotychczas stosowane przez użytkowników metody ich rozwiązywania i dostosować aplikację do już nabytych doświadczeń użytkowników.

W poradnikach Apple na temat budowy interfesju użytkownika możemy przeczytać: „Użytkownik ma już wypracowany model mentalny opisujący zadania jakie Twoja aplikacja pozwala mu wykonać. Model ten stanowi komponent doświadczeń użytkownika z życia codziennego, doświadczeń z obsługą innego oprogramowania i serwisów WWW i doświadczeń z komputerami w ogóle. Na przykład użytkownicy mają praktyczne doświadczenia z wysyłaniem listów pocztą, aplikacja, która będzie im pomagać utrzymywać kontakt z bliskimi i znajomymi, musi odzwierciedlać oczekiwania uzytkowników co do czynności wysyłania listu – tworzenie nowego listu, precyzowanie odbiorcy, wysyłanie.”

Aplikacja, która idzie pod prąd oczekiwaniom użytkowników, igrnorująca ich modele mentalne skazana jest na porażkę.

Rzecz jasna przedstawiony tutaj schemat czynności projektowych to tylko propozycja, która moim zdaniem dość dobrze się sprawdziła w przypadku realizowanych przeze mnie projektów. Zależnie od projektu i wybranej metodologii pracy, nasz schemat projektowy może być inny. Mogą się w nim pojawić persony, papierowe prototypowanie czy jeszcze inne elemeny.

I na sam koniec – nie zapomnijmy o tym, żeby nasze makiety poddać ocenie użytkowników i wykonać z użytkownikami co najmniej jedną sesję badawczą.

Dlaczego należy prototypować?

Oszczędność czasu, przy dużych projektach stworzenie prototypu przyczyni się do oszczędności czasu – mniej niedomówień i braku zrozumienia na linii projektant – zespół programistów.

Pewność ostatecznych wyników, kiedy programiści wiedzą, co i jak ma działać mają do dyspozycji dynamiczny projekt plus specyfikacje w której opisano to co czego nie dało się zasymulować, to możemy być pewni, że ostatecznie otrzymamy świetnie działający serwis, wykonany zgodnie z naszymi założeniami.

Oszczędność pieniędzy, przy braku prototypu, ilość poprawek wprowadzanych ad hoc przez klienta i ilość poprawek wynikających z powodu braku zrozumienia naszych intencji przez programistów, prowadzi do wydłużenia się realizacji projektu o 1000%. Klient traci pieniądze nie tylko w przeliczeniu na 1 h pracy, traci zyski które mógłby wypracować gdyby aplikacja była gotowa na czas.

Przyjemna praca, projekt funkcjonalny to rezultat wielogodzinnych konsultacji z klientem, który nie zawsze do końca wie co chce zrobić, mając w ręku gotowy prototyp o wiele łatwiej torpedować pomysły klienta idące w kierunku zmian już realizowanej koncepcji, jednym słowem każda ze stron wie na czym stoi.

Klient ma możliwość zobaczenia jak jego serwis będzie nie tylko wyglądał, ale przede wszystkim jak będzie działał. Tutaj możemy natknąć się na rafy niezrozumienia, bo klient nie zawsze rozumie, że prototyp to nie jest działający serwis. Zatem projekty muszą być pozbawione szaty graficzne i skupiać się na mechanizmach działania serwisu, bez niepotrzebnych rozpraszaczy w postaci kolorowych przycisków i obrazków.

W następnym wpisie spróbuję bardziej szczegółowo przyjrzeć się jednemu z narzędzi do tworzenia makiet stron WWW, czyli programowi Axure.

Warto poczytać:

Apple Human Interface Guidelines
Mental Models and Usability
Webaudit, Makiety, prototypy i 6 popularnych błędów