Projektowanie zorientowane na użytkownika

<a href=\"http://www.konferencje24h.pl\" target=\"_blank\" rel=\"nofollow\"><a href=\"http://www.konferencje24h.pl\" target=\"_blank\" rel=\"nofollow\">http://www.konferencje24h.pl</a></a>

zobacz na <a href=\"http://www.konferencje24h.pl\" target=\"_blank\" rel=\"nofollow\">Nazwa linka...</a> aktualne informacje o konferencjach.

VII Międzynarodowa Konferencja IWP \"Perspektywy rozwoju e-usług. Wzornictwo usług\" <br /> Warszawa, 24-25 listopada 2011 roku.<br /><br /> <a href=\"http://www.iwp.com.pl/vii_miedzynarodowa_konferencja_iwp\" target=\"_blank\" rel=\"nofollow\">http://www.iwp.com.pl/vii_miedzynarodowa_konferencja_iwp</a>

Nic a nic nie widać :D

A mnie zawsze wydawało się, że jest to naturalne podejście do projektu i nie potrzebuje takich opisów, nazw i specjalizacji. Projektowanie dla szerszego grona osób zawsze niesie ze sobą potrzebę funkcjonalności i w takim kierunku intuicyjnie powinno się kierować. Świetne projekty noszą znamiona wysmakowanej grafiki, dobrego i oryginalnego zamysłu, intuicyjnego interfejsu/wyglądu oraz oczywiście dobrej realizacji. Co do programisty "to jest niemożliwe"... by robił z nami następny projekt;)<br /> Co do architekta treści zgadzam się, że przy dużych projektach taka osoba jest przydatna, by odpowiedni ludzie skupili się tylko na tym co robią najlepiej i co lubią robić najbardziej:)

Tomek - zgadzam się z Tobą. Cieżko wyobrazić sobie projekt serwisu w którym nie uwzględnia się perpsektywy użytkownika.

Panowie, wiecej optymizmu :-). W PL sporo firm pracuje w filozofii UCD, nie wszystkie o tym glosno mowia a nawet nie wszystkie sa tego swiadome ale jest ich sporo. Sporo projektow tak powstaje.

<blockquote>Z pracą projektanta jest tak iż jak jest dobrze to nikt nie powie ze jest ok tylko jak coś spieprzysz t wala się gromy.</blockquote><br /> <br /> true, true :)

Marcinie <br /> <blockquote><br /> Podajcie proszę parę przykładów z naszego polskiego podwórka serwisów, które są bliskie ideałów, o których piszecie + kilka słów wyjaśnienia dlaczego właśnie te strony. Jeśli to nie filozofia jeno, metoda musi mieć oparcie w realnych przykładach.<br /> </blockquote><br /> <br /> W treści wpisu nie ma przykładów serwisów. <br /> Z tego co wiem to podejście UCD jest stosowane w niewielu firmach w Polsce. U nas usability traktuje się jako dodatek do procesu projektowania na zachodzie jest to cześć pakietu jaki dostaje klient. <br /> <br /> Agnieszko <br /> <blockquote><br /> Kiedy mamy małą stronę, gdzie w menu są trzy pozycje na krzyż, to rzeczywiście bez większego znaczenia, czy architekt wkroczy do akcji czy nie. Ale serwis korporacyjny? Ale rozbudowana funkcjonalnie i estetycznie strona FMCG?<br /> Toż to tu najbardziej potrzeba usability, żeby użytkownik miał rzeczywiście szansę powiedzieć "to zajebiste".<br /> </blockquote><br /> <br /> Dobre, ale nie wyobrażam sobie sytuacji, gdzie user mówi zajebista architektura informacji szacun dla architekta :) <br /> Z pracą projektanta jest tak iż jak jest dobrze to nikt nie powie ze jest ok tylko jak coś spieprzysz t wala się gromy.

ciężkie jest życie projektanta UX...:)

Podajcie proszę parę przykładów z naszego polskiego podwórka serwisów, które są bliskie ideałów, o których piszecie + kilka słów wyjaśnienia dlaczego właśnie te strony. Jeśli to nie filozofia jeno, metoda musi mieć oparcie w realnych przykładach.<br /> <br /> A plakat jest ok. Przy podejmowaniu pracy w działach marketingu powinien być testem dla osób, które mają się zajmować interactive.

Super, ze chlopaki z Komitywy poruszyli ten temat! Dzieki!<br /> <br /> To ja dorzuce swoje trzy grosze:<a class="non-html" href="http://www.webusability.pl/2008/03/18/user-centered-design-na-plakacie/"> http://www.webusability.pl/2008/03/18/user-centered-design-na-plakacie/</a> :-)

Z tą filozofią kojarzą mi się bardzo konkretne metody zarządzania projektami XP oraz XPrince - polecam lekturę.<br /> <br /> Ogólnie też jestem zdania, że taki przeciętny klient czy user wie czego nie chce, ale nie wie czego chce. W rzeczywistości nieumiejętne stosowanie stosowanie takiego podejście na pewno może przynieść negatywne skutki (np. termin realizacji projektu może wydłużyć się kilkakrotnie bo wciąż jest coś ustalane/zmieniane) ale doświadczeni PMowie mogę z powodzeniem kierować się takim podejściem - ja osobiście uważam, że to co robię ma być przede wszystkim dla ludzi a nie dla mnie.<br /> <br /> Odpowiadając na pierwsze pytanie Eryka - tak chętnie, poczytam coś więcej: przykłady, porównania z innymi podejściami, ew wady i własne spostrzeżenia.

<blockquote>A nie prościej jest tak:<br /> Dobry informatyk + dobry grafik + ze 20 ludzików (reprezentanci grupy docelowej), którzy mówią tym dwóm, co i jak mają zrobić, jakie są preferencje i oczekiwania grupy, (bo przyjmuje, że tych 20-stu nie potrafi programować czy projektować, a szkoda, bo to by jeszcze bardziej ułatwiło sprawę). I mamy user-centered design w czystej postaci. Gdy by jeszcze informatyk nie mówił "to jest niemożliwe" a grafik "tak się teraz nie projektuje" to mamy NIEBO po prostu. <br /> Jak tak teraz patrzę na to, co napisałem to wole zostać przy teoretyczno-filozoficznych dywagacjach niż gdyby taka wizja miała się spełnić. Może i "user friendly", ale gdzie tu fun i pasja?<br /> </blockquote><br /> <br /> Infomatyk i grafik, z całym szacunkiem, nie muszą mieć pojęcia o tym, jak sortować informację w dużych zbiorach, żeby się ją intuicyjnie przeszukiwało, a także żeby zastosowane funkcjonalności nie zmuszały nas, userów do odwalania zbędnej, a denerwującej roboty przy przeglądaniu strony. <br /> Kiedy mamy małą stronę, gdzie w menu są trzy pozycje na krzyż, to rzeczywiście bez większego znaczenia, czy architekt wkroczy do akcji czy nie. Ale serwis korporacyjny? Ale rozbudowana funkcjonalnie i estetycznie strona FMCG? <br /> Toż to tu najbardziej potrzeba usability, żeby użytkownik miał rzeczywiście szansę powiedzieć "to zajebiste". Powiem więcej: architekt powinien wyznaczyć ramy dla fantazji grafika i programisty. Wiedzieć, kiedy powiedzieć stop. <br /> Strona nie musi być naszpikowana funkcjonalnościami i technologiami - one służą jakiemuś celowi, a nie jako kwiatek do kożucha. <br /><br /> A gdzie fun i pasja? Architektura nie musi być projektem danym raz na zawsze; programiści, graficy powinni być pierwszymi osobami do których architekt pójdzie konsultować swoje propozycje. Z tym że architekt jest tu tym głosem rozsądku, tym który patrzy na projekt z zupełnie innego punktu widzenia niż osoby które go potem wykonują. <br /><br /> Jeszcze co do badań: zazwyczaj to są badania jakościowe, nie ilościowe. Wszyscy mamy podobnie zbudowany mózg, przyzwyczajenia kulturowe (w danym kraju) oraz przyzwyczajenia do pewnych standardów w internecie. No i dlatego problemy na testach się powtarzają :)

No właśnie to nie jest takie proste. Użytkownik nie jest w stanie po prostu powiedzieć Ci jak masz zrobić serwis, bo nie jest projektantem ani informatykiem i nie ma o tym pojęcia. Jedyne co możesz od niego uzyskać to wiedza o jego potrzebach wobec tego serwisu, którą trzeba dopiero przełożyć na projekt. Tutaj jest miejsce na Twoją kreatywność!<br /> <br /> Gwarantuje Marcin, że gdybyś tylko popracował z dobrymi ludkami od UCD to byś nas docenił :)<br /> Za grafika + informatyka odwalamy kawał brudnej roboty, której na zewnątrz często nie widać, ale dzięki temu zyskują oni czytelne ramy i wymagania dla tego co robią najlepiej. <br /> <br /> Rozdzielmy jeszcze dwie rzeczy:<br /> <br /> 1) projektowanie funkcjonalne, które musi zagwarantować, że dobrze realizowane są założone cele - czyli projekt zarabia kasę i pozwala na efektywne wykonanie zadań użytkownika, tak że klient i user będą kontenci<br /> <br /> 2) projektowanie artystyczne, które powinno sprawić, że użytkownik powie dodatkowo: łał, ale zajebiste!<br /> <br /> Obie te rzeczy muszą koegzystować w dobrym projekcie, czasem się łączą, czasem kłócą, ale są to dwa różne światy i dwa wielkie obszary umiejętności i wiedzy.<br /> <br /> Co do punktu 2 to osobiście nie wierzę, że jakieś focusy nad konceptem graficznym pozwalają na uzyskanie lepszego efektu. Dobry grafik z dobrym pomysłem jest na pewno lepszy niż dizajnowanie przez komitet.<br /> <br /> Ale jeśli chodzi o ergonomię i wymagania biznesowe, to walidacja z użytkownikami jest podstawową metodą. Tylko tego dotyczy UCD. Bo może być tak że projekt, który był dla Ciebie pełen funu i pasji, u użytkownika budzi ziewanie albo zgrzytanie zębów.<br /> <br /> Co do tego ile osób badać itd. to jeśli Cię to interesuje zapraszam na priv. Oczywiście każda metoda badawcza obarczona jest jakimiś systematycznymi błędami, ale zdając sobie z tego sprawę, można wziąć na to poprawkę.<br /> <br /> Polecam Ci książki Donalda Normana, czyli kolesia który wymyślił to całe user-centered design - "Design of everyday things" i "Emotional Design" - czyta się to naprawdę fajnie i pasji tam nie brakuje. Zwłaszcza ta pierwsza jest świetna, bo to chyba jedyna książka o interakcji-człowiek komputer, w której prawie wszystkie przykłady pochodzą z życia codziennego (drzwi, włączniki światła, kuchenka gazowa itp.) Książka ma już kilkanaście lat i jest nadal aktualna.

Ależ my nic innego nie proponujemy, niż to, o czym Marcin piszesz. Tyle tylko, że w bardziej sformalizowany sposób. Chcemy tylko powiedzieć, że nie jesteś użytkownikiem stworzonego przez siebie serwisu, że powinieneś rzeczonego użytkownika poznać, dowiedzieć się - czego ów chce. Pasja i fun? Na to też jest miejsce. Rzecz tylko w tym, żeby mieć na uwadze to, czego chciałby użytkownik. Jeżeli nawet chcesz potrzeby użytkownika dopiero kształtować, warto być pewnym, że Twój odbiorca będzie wiedział, jak to ugryźć.<br /> <br /> Krótko mówiąc - Ty przekonujesz użytkownika do tego, że produktu potrzebuje, ja staram się, żeby produktu nie wyrzucił trzy dni po zakupie. Jest miejsce i na pasję, i na aspekt użytkowy. Jedno bez drugiego zwykle nie funkcjonuje najlepiej, od którejkolwiek strony by nie podchodzić.

A nie prościej jest tak:<br /> Dobry informatyk + dobry grafik + ze 20 ludzików (reprezentanci grupy docelowej), którzy mówią tym dwóm, co i jak mają zrobić, jakie są preferencje i oczekiwania grupy, (bo przyjmuje, że tych 20-stu nie potrafi programować czy projektować, a szkoda, bo to by jeszcze bardziej ułatwiło sprawę). I mamy user-centered design w czystej postaci. Gdy by jeszcze informatyk nie mówił "to jest niemożliwe" a grafik "tak się teraz nie projektuje" to mamy NIEBO po prostu. <br /> Jak tak teraz patrzę na to, co napisałem to wole zostać przy teoretyczno-filozoficznych dywagacjach niż gdyby taka wizja miała się spełnić. Może i "user friendly", ale gdzie tu fun i pasja?

gwoli wyjaśnienia warto dodać, że autorem tekstu nie jest żaden z nas wyżej komentujących, lecz Marcin Szuba :)

Marcin, autorowi chodziło chyba o to, że user-centered design w szerokim znaczeniu można rozumieć jako ogólną filozofię projektowania, gdzie wymagania użytkownika końcowego są traktowane nadrzędnie w stosunku do wymagań technologicznych czy samozadowolenia art directora ;) Co za tym idzie:<br /> <br /> - projektowanie interfejsu użytkownika powinno poprzedzać projektowanie systemu od strony technologicznej<br /> - rozbudowana musi zostać rola narzędzi służących do pozyskiwania wymagań użytkowników<br /> - projektowanie interfejsu powinno mieć iteracyjny charakter (projekt podlega weryfikacji z użytkownikami i jest na tej podstawie ulepszany)<br /> <br /> To są główne wyznaczniki obecności "filozofii" UCD w projektowaniu.<br /> <br /> Z drugiej strony UCD to także różne konkretne implementacje tego podejścia w postaci już sformalizowanych metodyk prowadzenia projektu i tutaj jeden z modeli doczekał się standaryzacji w normach ISO (13407 i 18529).

Polecam jednak spróbować zastosować czasami przynajmniej niektóre z elementów UCD. Można nabrać pokory - okazuje się, że rzeczywistość nie musi wyglądać ta, jak opisujesz. Jeżeli klient woli zrobić po uważaniu - no cóż, niech zatem bierze inną agencję. My akurat zajmujemy się projektowaniem w określonych ramach - wyznaczonych przez UCD. <br /> <br /> Zdziwiłbyś się, ilu klientów odpowiada "tak, zdecydowanie, chcemy badania" (ograniczając zaangażowanie użytkownika do badań, w uproszczeniu). Wystarczy tylko czasmi spróbować to zaproponować...<br /> <br /> Co do liczby użytkowników i związanych z tym zarzutów - spróbuj kiedyś wziąć udział w testach z udziałem dwóch pięcioosobowych grupach. Zobaczysz, jak powtarzają się problemy i uwagi użytkowników. <br /> <br /> "Wszyscy użytkownicy wypowiedzieli się pozytywnie. Powstał projekt finalny. Ale dwójce z badanych coś jednak nie pasuje." - takie rzeczy się nie zdarzają, zapewniam :) Bardzo szybko zorientujesz się w wadze wykrytych problemów, prowadząc badania...

Kurde sorry, teraz doczytałem, że to jest "filozofia". No to jestem w domu. Rozumiem.

A na ilu użytkownikach testujemy?<br /> A jak pięciu powie ok. a szósty nie załapie, poprawiamy?<br /> Poprawiliśmy, ale czwarty w tym momencie się pogubił. Poprawiamy?<br /> Ok. testy na makietach przeszły prawidłowo. Wszyscy użytkownicy wypowiedzieli się pozytywnie. Powstał projekt finalny. Ale dwójce z badanych coś jednak nie pasuje. Poprawiamy?<br /> "Pierwszym krokiem jest opracowanie planu. Jest to dokument, który powstaje w wyniku spotkania z udziałowcami projektu - a więc wszystkimi, na których wpływa projektowana aplikacja." <br /> Projektowana aplikacja ma wpłynąć na potencjalnych użytkowników np.: portalu informacyjnego. Pokój, w którym odbyłoby się spotkanie powinien być baaaaardzo duży. W przeciwnym wypadku jak? Ignorujemy ich?<br /> W metodologii antropologii kulturowej jest znane pojęcie obserwatora. Czyli badacza, który niby stoi z boku, obserwuje i wyciąga wnioski. Wszyscy wiedzą, że metoda jest słaba, bo obserwator ma wpływ na obserwowanych już przez samą obecność (idealnie, gdy by był niewidzialny, ale to jest niemożliwe), ale nie ma innej lepszej metody, więc stosuje się tą, która daje fałszywe wyniki. W wypadku metody UCD mam podobne wrażenie. Coś, ktoś bardzo mądrze napisał. Brzmi sensownie. Ale rzeczywistość najczęściej wygląda tak: Tu macie chłopaki i dziewczyny strukturę (możemy dyskutować, ale właściwie chcielibyśmy żeby została bez zmian) macie 2-3 tygodnie i chcielibyśmy żeby serwis był w sieci. Robicie? "Nie, bo nie ma czasu na wprowadzenie procedury UCD". Nie? Aha, to zrobi to agencja "x". Dobranoc. <br /> I jeszcze jedno. Jak się domyślam w polskiej sieci jakieś 99% serwisów jest zaprojektowana i wdrożona z pominięciem tej metody? To znaczy, że jak? Do kosza? A w ogóle to jak te serwisy powstały? Czary? Fusy? Przypadek? <br /> Bo działają i mają się dobrze.

prosimy czytelników o feedback - czy temat powinien być rozwijany w szczegółach? Inne oczekiwania w kwestiach około-usability? Bardziej specjalistycznie? Bardziej ogólnie? Przykłady?<br /> <br /> z góry dziękujemy