Temat: Sensowna krytyka UCD - polecam

Natknąłem się na bardzo sensowny kawałek o projektowaniu UCD.

Polecam lekturę.

Autor - w największy skrócie - twierdzi, że zakres działania metodologii nie powinien się kończyć przed wdrożeniem.
Nie liczy się to, co na testach zrobią testowani userzy, tylko co zrobią i jak zareagują klienci. A tym elementem projektanci - nie wszyscy - zwykle się już nie interesują.

Zapraszam do dyskusji.Tomasz B. edytował(a) ten post dnia 27.11.09 o godzinie 11:03

Temat: Sensowna krytyka UCD - polecam

Tomasz B.:
Natknąłem się na bardzo sensowny kawałek o projektowaniu UCD.

Polecam [url=http://000fff.org/getting-to-the-customer-why-everythi...]lekturę[/ul].

Autor - w największy skrócie - twierdzi, że zakres działania metodologii nie powinien się kończyć przed wdrożeniem.
Nie liczy się to, co na testach zrobią testowani userzy, tylko co zrobią i jak zareagują klienci. A tym elementem projektanci - nie wszyscy - zwykle się już nie interesują.

Zapraszam do dyskusji.

Moim zdaniem problem leży bardziej w świadomości klientów, którzy w momencie wdrożenia chcieliby mieć produkt idealny i zamknięty raz na zawsze. W związku z tym nie widzą potrzeby dalszej obsługi powdrożeniowej ze strony projektantów ("jak to, zapłaciłem już za projektowanie i testowanie?!" :)

Co do krytyki samego UCD - jeżeli produkcja gotowego młotka zajmie 10 miesięcy, zaangażuje pół firmy i będzie kosztowała ponad pół miliona złotych, to jednak lepiej testować wcześniej na prototypie :)

Jedynie robiąc prototyp jestem w stanie dobrze przekazać klientowi, co właściwie wymyśliłem i przetestować, który z kilku wariantów rozwiązania problemu działa najlepiej.

UCD ma także dążyć do zaangażowanie całego zespołu produkcyjnego w projektowanie i w myślenie o użytkowniku. W ogóle skąd się wziął taki proces? - po to, żeby odróżnić się od typowego procesu ukierunkowanego na technologię i programistów. To jest dla mnie najważniejszy wyznacznik UCD.

Nigdzie natomiast UCD nie sprzeciwia się zaangażowaniu po wdrożeniu - przeciwnie, nawet ISO 18529 mówi o supporcie powdrożeniowym i ciągłym monitoringu. Autor tego artykułu chyba nie do końca zgłębił przedmiot swojej krytyki :)

UCD krytykował już nawet jego twórca Don Norman, ale z trochę innych pozycji: http://www.jnd.org/dn.mss/human-centered.html

Temat: Sensowna krytyka UCD - polecam

Zastanawiałem się i wyszło mi, że zgadzając się z Maćkiem, zgadzam się także z Petersenem :)

Deprecjonowanie badań na etapie projektu dlatego, że nie ma wówczas produktu, wydaje mi się nieodpowiedzialne. Rzeczywistość pokazuje, że te badania po prostu mają przełożenie na rezultat. Z drugiej strony - i tu zgoda z Petersenem - kompleksowa weryfikacja produktu w kontekście wniosków z etapu projektowania powinna być stałym elementem każdego projektu internetowego (podkreślam "kompleksowa" - badania, testy, wnioski, konsekwencje - a nie tylko monitorowanie i support, jak u Maćka).

Przed wdrożeniem, realizując cały proces UCD, można popełnić kupę gaf:

- błędy na etapie projektowania - wyciąganie złych wniosków z zachowań użytkowników, albo wręcz budowanie złych założeń co do użytkowników (a w konsekwencji nieadekwatnych person).
- zastosowanie nieadekwatnych prototypów do badań
- zmiany na etapie wdrażania - kompromisy generalnie mają większą siłę niż wnioski z badań, a w konsekwencji mogą wpłynąć na wdrażanie crapowych rozwiązań
- ideologiczne spory - rozwiązywanie problemów, które dotyczą wyłącznie projektu (a nie produktu) lub pewnych filozofii, może prowadzić do wypaczenia produktu końcowego
- brak wyobraźni - który może spowodować całkowite pominięcie pewnych problematycznych obszarów i niezbadanie ich

A nawet jeśli nie ma gaf, zdarza się pewien odsetek produktów obarczony "efektem niespodzianki" - kiedy produkt z powodu swoich innych walorów jest używany w inny sposób i wywołuje inne reakcje niż mogłoby się wydawać lub mogłoby wynikać z badań (tak jak u Petersena - intuicyjny sposób robienia "czegoś" okazuje się nie być intuicyjnym sposobem robienia "tego" - nasza-klasa?). I żeby usprawnić taki produkt trzeba przeprowadzić nowe badania, już na etapie gotowego produktu.

Takie podejście - a więc dodatkowy krok polegający na testowaniu "po", a nie tylko "przed" - ma też tę dodatkową zaletę, że w odróżnieniu od badania przed wdrożeniem, można skomunikować ze sobą badania jakościowe z ilościowymi.

Ale wydaje mi się, że nie da się utrzymać tezy Petersena, że testowanie użytkowników nijak ma się do testowania klientów.Adam Plona edytował(a) ten post dnia 27.11.09 o godzinie 12:58

Temat: Sensowna krytyka UCD - polecam

Proszę nie traktować mojego postu jako głosu w dyskusji. W numerze 3(61)2009 kwartalnika "kultura współczesna" ukazała się seria artykułów prezentujących stan nauki o projektowaniu. Jest tam sporo tematyki Państwu bliskiej; również nieco propozycji na przyszłość. Jest również, o ile pamiętam, rozwiązanie problemu postawionego w wątku.

Temat: Sensowna krytyka UCD - polecam

Przyznaję, że nie przeczytałem poleconego tekstu w całości, więc odnoszę się głównie do tez stawianych w jego początku.

Sam tytuł " why everything you think about User Centred Design is wrong" jest mocno arogancki. Czyżby autor miał monopol na jedyną słuszną prawdę? :)
Autor opisuje młotek twierdząc, że najlepsze jest stworzenie gotowego młotka. Według mnie - poważnie się myli. Jeśli przyłożymy proces UCD do tworzenia młotka to etapem prototypowania powinno jak najbardziej być stworzenie metalowej formy i przetestowanie wbijania! Nie musi to być jednak projekt końcowy pod względem szczegółów wyglądu.

Czy autor chciały, aby tworzenie skomplikowanej aplikacji polegało na jej stworzeniu, a potem testowaniu? Każdy kto miał do czynienia z UCD wie, że jest to często o wiele kosztowniejsze... nie wiem, czy coś więcej trzeba dodawać.

A opieka powdrożeniowa to przecież zupełnie inna bajka, często ze strony klientów po prostu nie ma takiej opcji. Nie znam rynku en, ale myślę że różnice w porównaniu z polskim rynkiem mają tutaj duże znaczenie.

Jeśli nie do końca zrozumiałem co autor miał na myśli to proszę o wybaczenie, ale nie mam czasu przebijać się przez cały tekst.

Temat: Sensowna krytyka UCD - polecam

Maciek Lipiec:
W związku z tym nie widzą potrzeby dalszej obsługi powdrożeniowej ze strony projektantów
("jak to, zapłaciłem już za projektowanie i testowanie?!" :)

Może trzeba im mówić o tym, zanim zapłacą? "Drogi kliencie, tak naprawdę Twój produkt jeszcze wtedy nie będzie działał" albo jeszcze uczciwiej "zastosujemy wszystkie metodologie, ale dopiero poprawienie tego co zrobimy da nam szanse na dobry produkt".
Wiem wiem, to nie byłby dobry biznes.
/koniec czepiania :-)

Nie wybieramy między młotkiem a produktem, który ma pochłonąć 10 miesięcy i 500 tys.
Chyba, że robimy tylko za pieniądze UE, albo za mniej nie zaczynamy rozmowy.
W każdym innym przypadku - a więc przy większości projektów - rola projektantów nie powinna się kończyć się w momencie oddania do produkcji. Muszą zobaczyć "to zrobiłem, tu się pomyliłem, to założenie było idiotyczne, tego nie przewidziałem".

Tak rozumiem ten tekst.
Czasem nawet warto to projektowanie skrócić i zamiast szukać idealnego rozwiązania sprawdzić jak działają te, które akurat mamy do dyspozycji.

A krytyka Normana zawiera kilka trafnych spostrzeżeń wogóle nt roli projektanta i "słuchania" użytkowników.
W tym kontekście czy nie, przeczytać ją warto.
Zresztą zwykle lepiej coś przeczytać niż pisać bzdury :-)Tomasz B. edytował(a) ten post dnia 27.11.09 o godzinie 18:24

Temat: Sensowna krytyka UCD - polecam

Ciekawy wątek. Tak naprawdę dotyczy on zasad współpracy z klientem:

1) typowy klient agencyjny, o którym napisał Maciej oczekujący skończonej strony WWW (tak, to w tej frazie jest zwarty fałsz - logiczna wartość = 0);

2) klient świadomy (bądź uświadomiony przez projektanta, ale i tak wymagający od niego otwarcia i gotowości zaufania), z którym współpracuje się długoterminowo. Wie, że skończone serwisy nie istnieją, że chcąc się rozwijać, należy testować (moje ulubione: Always be testing!).

Czasem bywa też tak, że sytuacja z punku drugiego zachodzi, gdy projektant jest zarazem klientem, tj. jest właścicielem serwisu, dla którego wypuszcza projekty. Rzadka sytuacja, ale warta wszelkich pieniędzy bo zwraca się jako wartość dla projektanta, jak i wartość dla właściciela.

Reasumując: gdyby projektanci byli włączani także w proces utrzymania i rozwoju produktu, wówczas to wszystko zaczyna mieć sens. Ale to wymaga edukacji - co słusznie Tomku zauważasz, oraz - co też podkreślasz - podejścia trochę w opozycji do biznesu: "nie zrobię to Panu, bo to z definicji jest crapowy pomysł!". To drugie na co dzień jest trudne, bo trzeba żyć, acz z mej perspektywy warte zachodu i przeważnie długoterminowo się zwraca.

Na marginesie: czasem zdarzają się klienci, którzy sami mówią "ta strona jest na dwa-trzy lata; poza tym cały czas ją będziemy poprawiali, bo strony nigdy nie są skończone. A potem zrobimy nową". To prawie cytat z jednego z moich klientów - i najlepiej mi się z nim współpracuje.

Temat: Sensowna krytyka UCD - polecam

Marek Kasperski:
Ciekawy wątek. Tak naprawdę dotyczy on zasad współpracy z klientem:

1) typowy klient agencyjny, o którym napisał Maciej oczekujący skończonej strony WWW (tak, to w tej frazie jest zwarty fałsz

Problem jest taki, że większość klientów nie zadaje sobie pytania czy i jak zarabia na serwisie WWW. Agencje też nie są zainteresowane analizą po wdrożeniu, bo obawiają się niekorzystnej oceny i roszczeń klienta. Do tego stosowanie UCD zwyczajnie podnosi koszt projektu. Czasem lepiej nie mówić, że wdrożenie, to początek drogi a nie koniec.

2) klient świadomy (bądź uświadomiony przez projektanta, ale i tak wymagający od niego otwarcia i gotowości zaufania), z którym współpracuje się długoterminowo. Wie, że skończone serwisy nie istnieją, że chcąc się rozwijać, należy testować (moje ulubione: Always be testing!).

To prawda, ale poziom zwrotu z tej inwestycji musi być opłacalny.
Jak ktoś wydaje 5-10k na stronę, to ile powinien wydać na jej analizę w perspektywie roku? Testy mają sens jeśli możliwe jest wdrożenie zmian. Testowanie dla testowania, to nie jest droga do długiej relacji z klientem.

- co też podkreślasz - podejścia trochę w opozycji do biznesu: "nie zrobię to Panu, bo to z definicji jest crapowy pomysł!". To drugie na co dzień jest trudne, bo trzeba żyć, acz z mej perspektywy warte zachodu i przeważnie długoterminowo się zwraca.

Kiedy jest się kowalem własnego losu jest prościej. Najgorzej jest kiedy ma się "handlowców" jako pośredników, albo zupełnie niekumatego szefa. Wtedy powiedzenie "nie zrobię" nabiera nowego wymiaru.. coś pomiędzy bohaterstwem a głupotą ;)

Temat: Sensowna krytyka UCD - polecam

Adam Plona:

Deprecjonowanie badań na etapie projektu dlatego, że nie ma wówczas produktu, wydaje mi się nieodpowiedzialne. Rzeczywistość pokazuje, że te badania po prostu mają przełożenie na rezultat.

Ale zwinne metodyki przekonują do możliwie najszybszego dostarczenia pierwszej wersji. Co oznacza, że z lepiej jest testować wersję alfa niż prototyp wersji alfa. Moim zdaniem dużo zależy od doświadczenia zespołu, technologii i metody prowadzenia projektu. Nie można przykładać tej samej miary do np. Ruby+Scrum i SAP+Waterfall.

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:

Adam Plona:

Deprecjonowanie badań na etapie projektu dlatego, że nie ma wówczas produktu, wydaje mi się nieodpowiedzialne. Rzeczywistość pokazuje, że te badania po prostu mają przełożenie na rezultat.

Ale zwinne metodyki przekonują do możliwie najszybszego dostarczenia pierwszej wersji.

Metodyki zarządzania projektami (które pewnie masz na myśli) przede wszystkim odpowiadają za organizacyjny, a nie merytoryczny sukces projektu. Dlatego nie wiem, dlaczego miałyby przekonywać?
Zresztą metodyki agile bynajmniej nie wykluczają etapów testowania.

Anyway, są projekty i Projekty :)
Pewnych rzeczy po prostu nie ma sensu testować.

Co oznacza, że z lepiej jest testować wersję alfa niż prototyp wersji alfa.

Generalnie jest tak, że jeśli w ogóle myśli się o testach, to znaczy, że traktuje się projekt dość serio. Jeśli tak jest, to najczęściej wytworzenie wersji alfa trochę jednak trwa. I dlatego lepiej nie bazować w tym czasie wyłącznie na intuicji projektantów.

Inna rzecz, że tak to się najczęściej dzieje :))Adam Plona edytował(a) ten post dnia 29.11.09 o godzinie 00:28

Temat: Sensowna krytyka UCD - polecam

Adam Plona:

Marcin Śpiewak:

Adam Plona:

Deprecjonowanie badań na etapie projektu dlatego, że nie ma wówczas produktu, wydaje mi się nieodpowiedzialne. Rzeczywistość pokazuje, że te badania po prostu mają przełożenie na rezultat.

Ale zwinne metodyki przekonują do możliwie najszybszego dostarczenia pierwszej wersji.

Metodyki zarządzania projektami (które pewnie masz na myśli) przede wszystkim odpowiadają za organizacyjny, a nie merytoryczny sukces projektu.

Myślę, że nie masz racji dzieląc włos na czworo. Zawsze celem jest dostarczenie oprogramowania zgodnego z wymaganiami klienta. Czynności, które można podjąć, są ograniczone budżetem i czasem. Jeśli rezultatem ma być serwis o wysokiej użyteczności, to i tak musi powstać produkt, który można poddać ostatecznej ocenie. Wszystko pomiędzy celem a finalnym produktem, to tylko środki a nie cel sam w sobie.

Anyway, są projekty i Projekty :)
Pewnych rzeczy po prostu nie ma sensu testować.

Co oznacza, że z lepiej jest testować wersję alfa niż prototyp wersji alfa.

Generalnie jest tak, że jeśli w ogóle myśli się o testach, to znaczy, że traktuje się projekt dość serio. Jeśli tak jest, to najczęściej wytworzenie wersji alfa trochę jednak trwa. I dlatego lepiej nie bazować w tym czasie wyłącznie na intuicji projektantów.

Czasem doświadczone zespoły są w stanie wydawać nowe wersje w 2 tygodniowych iteracjach. Po co budować i testować prototypy, jeśli do dyspozycji jest gotowy produkt? Jeśli ktoś nie zna polecam http://gettingreal.37signals.com/

Sorry za małe OTMarcin Śpiewak edytował(a) ten post dnia 29.11.09 o godzinie 19:48

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:
Czasem doświadczone zespoły są w stanie wydawać nowe wersje w 2 tygodniowych iteracjach. Po co budować i testować prototypy, jeśli do dyspozycji jest gotowy produkt? Jeśli ktoś nie zna polecam http://gettingreal.37signals.com/

Hmm...co jest bardziej kosztowne - praca zespołu programistów, czy praca jednego projektanta interakcji?

Wyobraź sobie sytuację w której bardzo doświadczony zespół złożony jest tylko z istot ludzkich i to najczęściej trzymający się z dala od wiedzy z zakresu szeroko rozumianego user experience, tworzy aplikację w ciągu 2 tygodniowej iteracji np. w metodyce SCRUM. Pokazują ją światu (obojętnie czy świat jest rzeczywistością całej sieci czy rzeczywistością badania użyteczności), a świat w pełni odrzuca założenia przyjęte przez bardzo doświadczony zespół. Aplikacja trafia do poprawek. Mijają kolejne dwa tygodnie i znowu koszta wyznacza praca programistów. Fajnie idzie praca? Koszta spadają? Nie sądzę;).

A drugi wariant to dwutygodniowa praca projektanta interakcji (współpracującego z zespołem, wykorzystującego czas na przeprowadzenie badania - to jest możliwe:)), który dopieszcza prototyp minimalizując ryzyko wystąpienia krytycznych błędów interfejsu w momencie w którym zabierają się do niego programiści. Ostatecznie obniżamy koszty projektu, przez sprowadzenie do minimum ryzyka.

Marcin - ostatnio skupiasz się na atakowaniu UCD pod względem jego nieprzystawalności do metodyk zwinnych. Uważam, że to nietrafiony zarzut. UCD nie jest pomnikiem ze spiżu - łatwo jest je modyfikować.

Oczywiście co innego praca w portalu, co innego praca w agencji. Niemniej w portalu dam sobie głowę uciąć, że da sie pogodzić UCD np. ze SCRUMem.

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:Do tego stosowanie UCD zwyczajnie podnosi koszt projektu.

Tu się nie do końca zgodzę. Bo jaki koszt, czy powinno i czy na pewno.
Przecież po to się to robi, by ustrzec się błędów i realizacji niepotrzebnych rzeczy. Projektujemy "UC", żeby ustalić co ten U tak naprawdę podtrzebuje.
Może koszt samego projektowania podnosi, ale kosztu stworzenia produktu raczej nie powinno. Całościowo wręcz powinno obniżać.

(edytuję bo robię literówki i dopiero na gotowym widzę)Tomasz B. edytował(a) ten post dnia 30.11.09 o godzinie 10:01

Temat: Sensowna krytyka UCD - polecam

Tomasz B.:

Marcin Śpiewak:Do tego stosowanie UCD zwyczajnie podnosi koszt projektu.

Tu się nie do końca zgodzę. Bo jaki koszt, czy powinno i czy na pewno.
Przecież po to się to robi, by ustrzec się błędów

Nie da się "ustrzec błędów". Można tylko zaakceptować istnienie zmian i sobie z nimi radzić - w szerszym kontekście - przecież nie ma skończonych stron. :)

realizacji niepotrzebnych rzeczy. Projektujemy "UC", żeby ustalić co ten U tak naprawdę podtrzebuje.

UCD jest kosztem zawsze (ludzie, soft, maszyny, pomieszczenia albo usługa) Pytanie kto go pokrywa i czy/jak bardzo obniża zysk. Większość firm IT kończy "zarabianie" na wdrożeniu i nie obchodzi ich co się potem dzieje. A nawet kasują za poprawki i szkolenia :)

Zatem potencjalnie tracą, jeśli klient nie zapłaci ekstra za badania. Stosując UCD zwiększa się "time to market" - odsyłam do raportu interaktywnie.com gdzie są ładne wykresy na ten temat.

Klienci niechętnie chcą dawać osobny budżet na badania. Z drugiej strony niedoświadczone zespoły nie potrafią sobie poradzić z wytworzeniem aplikacji na czas (zdecydowana większość projektów), a jeszcze miałyby dbać o użyteczność w tej samej cenie.

Może koszt samego projektowania podnosi, ale kosztu stworzenia produktu raczej nie powinno. Całościowo wręcz powinno obniżać.

Procentowo koszty jest tym bardziej widoczny, im bardziej idealny model wytwarzania posiada zespół. Ale UCD powinno skracać "time to profit". Tylko po wdrożeniu agencje nie uczestniczą w podziale zysku (cena jest stała). Zyskuje tylko ten, kto potrafi budować długotrwałe relacje, ale jak wiemy na polskim rynku nie ma czegoś takiego jak lojalność - liczy się cena. I koło się zamyka.

Zupełni inna dyskusja zaczyna się, kiedy mamy zarabiający produkt i dział badawczy. A jeszcze inaczej, kiedy mamy start-up i ponosimy koszt projektu z własnej kieszeni. Pointa jest taka, że na projekty trzeba patrzeć szerzej - ostatnio miałem okazję o tym mówić http://uxweb.pl/projektowanie_nakierowane_na_uzytkowni...

Temat: Sensowna krytyka UCD - polecam

Marcin Treder:

Wyobraź sobie sytuację w której bardzo doświadczony zespół złożony jest tylko z istot ludzkich i to najczęściej trzymający się z dala od wiedzy z zakresu szeroko rozumianego user experience, tworzy aplikację w ciągu 2 tygodniowej iteracji np. w metodyce SCRUM. Pokazują ją światu (obojętnie czy świat jest rzeczywistością całej sieci czy rzeczywistością badania użyteczności), a świat w pełni odrzuca założenia przyjęte przez bardzo doświadczony zespół. Aplikacja trafia do poprawek. Mijają kolejne dwa tygodnie i znowu koszta wyznacza praca programistów. Fajnie idzie praca? Koszta spadają? Nie sądzę;).

Są mniejsze. Jeśli zespół jest doświadczony, to coś wie o usability i ma świadomość jego znaczenia. Po wydaniu pierwszej wersji, użytkownicy dostarczają feedback, który można poddać interpretacji. Jeśli produkt jest totalnie odrzucony, to znaczy, że jego rozwijanie nie ma sensu - zatem minimalizujemy straty.
Zespołowi, który nie ma projektanta często łatwiej jest wytworzyć produkt niż zrobić prototypy, a jeśli ma projektanta, to tym łatwiej powinien wytworzyć produkt.

A drugi wariant to dwutygodniowa praca projektanta interakcji (współpracującego z zespołem, wykorzystującego czas na przeprowadzenie badania - to jest możliwe:)), który dopieszcza prototyp minimalizując ryzyko wystąpienia krytycznych błędów interfejsu w momencie w którym zabierają się do niego programiści. Ostatecznie obniżamy koszty projektu, przez sprowadzenie do minimum ryzyka.

A teraz dla porównania. Robimy prototypy i badania. Po tych samych 2 tygodniach okazuje się, że to zły pomysł.. a jeśli mamy go rozwinąć to potrzeba kolejnych 2 tygodni (albo więcej, bo mamy "obiektywne problemy programistyczne wymagające zweryfikowania"), która metoda jest tańsza? Nie chodzi tylko o koszt samego badania czy procesu, ale też o to co dostajemy w zamian.

Zaczęliśmy od tego czy lepiej jest badać produkt niż prototypy - ja uważam że produkt, ale tylko jeśli możemy wprowadzić w nim zmiany.

Marcin - ostatnio skupiasz się na atakowaniu UCD pod względem jego nieprzystawalności do metodyk zwinnych. Uważam, że to nietrafiony zarzut. UCD nie jest pomnikiem ze spiżu - łatwo jest je modyfikować.

Zgadzam się, ale nie można twierdzić że UCD to dobro objawione i zawsze warto je stosować od samego początku do końca. Im bardziej się nad tym zastanawiam, tym mniej jestem hurra optymistą, a bardziej widzę koszty i ograniczenia tego działania. Nie chcę żeby ludzie myśleli, że UCD jest warunkiem sukcesu, bo tak zwyczajnie nie jest. Wiele projektów udało się bez UCD.

Oczywiście co innego praca w portalu, co innego praca w agencji. Niemniej w portalu dam sobie głowę uciąć, że da sie pogodzić UCD np. ze SCRUMem.

Oczywiście, że tak. Ale w tym wypadku stosujesz raczej UCD w kontekście istniejącego produktu i jego poprawek.. Tylko nie wszyscy mają szczęście pracować w portalu. :)

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:
A teraz dla porównania. Robimy prototypy i badania. Po tych samych 2 tygodniach okazuje się, że to zły pomysł.. a jeśli mamy go rozwinąć to potrzeba kolejnych 2 tygodni (albo więcej, bo mamy "obiektywne problemy programistyczne wymagające zweryfikowania"), która metoda jest tańsza? Nie chodzi tylko o koszt samego badania czy procesu, ale też o to co dostajemy w zamian.

2 tygodnie na wprowadzanie zmian po badaniach? Oj to jakiś ekstremalny przypadek. Ale ok. załóżmy, że przez 2 tygodnie projektant walczy z prototypem, bada zmienia, bada zmienia.

Jak to się ma do kosztów? Cóż wciąż nie angażujemy zespołu programistów, nie obciążają więc nas ich pensje. Co więcej oddamy im prototyp, który posłuży za dokumentację, minimalizujemy ilość błędów wynikających z nieprzemyślanego interfejsu i... dzięki poświęceniu większej ilości czasu na profesjonalne przemyślenie i zaprojektowanie tego co tworzymy, maksymalizujemy szanse na sukces produktu.

Problemy programistyczne wymagające zweryfikowania? Otóż konsultacje z programistami powinny się odbywać w trakcie tworzenia prototypu. Doświadczony programista na tym właśnie etapie przyspiesza znacząco proces wytwarzania aplikacji.

I pewnie - nie zawsze to zadziała. Chyba nie ma w tej grupie nikogo, kto zawsze stosuje pełną ortodoksyjno-książkową metodykę UCD. Tak jak sposób prototypowania dostosowujemy do projektu (czasem wystarczy paper-prototype, czasem potrzebujemy prototypu hi-fi, czasem musi symulować w pełni działanie serwisu, czasem może być statyczny...etc.), tak i w samym sposobie analizy i stosowaniu metod badawczych, szukamy optymalnej ścieżki dla nas i naszych klientów.

Ominąć proces prototypowania? To strzał w kolano. Nie wyobrażam sobie przemyślenia projektu bez chociażby stworzenia prototypu papierowego.

Nie testować, a obserwować projekt w działaniu? Jedno i drugie jest bardzo potrzebne. Zasada powinna być raczej taka: zawsze (!) testować i obserwować aplikację w działaniu, o ile tylko jest to możliwe. W praktyce bogactwo rozmaitych metodyk badawczych wspierających wytwarzanie prouktu (w tym na etapie prototypu!) - prawie zawsze pozwoli wybrać nam coś odpowiedniego i nieobciążającego.

Z mojej strony to wszystko. Zamierzam za jakiś czas zorganizować cykliczne spotkania użytecznościowe przy piwku - będzie okazja na dogłębniejsze dyskusje.

Oczywiście, że tak. Ale w tym wypadku stosujesz raczej UCD w kontekście istniejącego produktu i jego poprawek.. Tylko nie wszyscy mają szczęście pracować w portalu. :)

Nie tylko chodzi tu o istniejący produkt i jego poprawki. A i na portalu życie się nie kończy;)Marcin Treder edytował(a) ten post dnia 30.11.09 o godzinie 18:46

Temat: Sensowna krytyka UCD - polecam

Marcin,

dlatego właśnie stosuje się UCD, aby nie musieć wkładać dużego nakładu pracy w poprawianie gotowej aplikacji.

Chciałbyś wrócić do "korzeni", posadzić np. 3 programistów i kazać im napisać to, co oni uważają za słuszne? Powstają zaawansowane projekty bez specjalnego etapu projektowania, ale jak wiele razy kończą się źle?

Myślisz, że taniej jest poprawiać gotową aplikację lub aplikację w zaawansowanym stadium niż np. prototyp w Axure?

Temat: Sensowna krytyka UCD - polecam

Marcin Treder:

Ominąć proces prototypowania? To strzał w kolano. Nie wyobrażam sobie przemyślenia projektu bez chociażby stworzenia prototypu papierowego.

Ja sobie wyobrażam. Prototypownie to nie UCD, a UCD to nie tylko prototypy. Twierdzę, że badanie użytkowników często jest zbyt dużym kosztem w stosunku do wartości dla projektu i się zwyczajnie nie opłaca. Ogólnie "to zależy".. i nie ma jednej słusznej drogi.

P.S. To nie jest tak, że jak programiści nic nie robią, to znikają ;)

Temat: Sensowna krytyka UCD - polecam

Bartłomiej D.:
Marcin,

dlatego właśnie stosuje się UCD, aby nie musieć wkładać dużego nakładu pracy w poprawianie gotowej aplikacji.

Zdaje sobie z tego sprawę

Chciałbyś wrócić do "korzeni", posadzić np. 3 programistów i kazać im napisać to, co oni uważają za słuszne? Powstają zaawansowane projekty bez specjalnego etapu projektowania, ale jak wiele razy kończą się źle?

Czemu zakładasz, że zespół to sami programiści? To że nie stosuje się UCD nie oznacza, że nie ma projektanta interfejsu i odwrotnie.

Myślisz, że taniej jest poprawiać gotową aplikację lub aplikację w zaawansowanym stadium niż np. prototyp w Axure?

To zależy.. wiesz doskonale, że na takie pytanie nikt odpowiedzialny nie odpowie. Jeśli z testów wyniknie, że trzeba zamienić tekst przycisków w menu, to twierdzę, że taniej może być poprawić aplikację :]

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:

Chciałbyś wrócić do "korzeni", posadzić np. 3 programistów i kazać im napisać to, co oni uważają za słuszne? Powstają zaawansowane projekty bez specjalnego etapu projektowania, ale jak wiele razy kończą się źle?

Czemu zakładasz, że zespół to sami programiści? To że nie stosuje się UCD nie oznacza, że nie ma projektanta interfejsu i odwrotnie.

W takim razie co oni robią? Chyba projektują, tak? Skoro tak, to jest to UCD. Przecież nie musisz stosować kompleksowego modelu UCD, aby powiedzieć że stosujesz UCD. Ba, rzadko się to udaje!

Mówił o tym Eryk Orłowski na Krakspocie. Polecam obejrzeć wideo, jest gdzieś w sieci :)