Reklama
Szukaj zleceń na Getak.pl

Stwórz profil

Musisz wpisać swoje imię
Musisz wpisać swoje nazwisko
Musisz wpisać poprawny e-mail
Musisz wpisać hasło (min. 8 znaków)
Musisz zaakceptować regulamin

Marcin Śpiewak wierzę w ludzkie
dobro i semantyczny
HTML

Temat: Sensowna krytyka UCD - polecam

Bartłomiej D.:
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.

"projektować" nie oznacza zawsze UCD.
Przecież nie musisz stosować kompleksowego modelu UCD, aby powiedzieć że stosujesz UCD. Ba, rzadko się to udaje!

Mogę zatem zrezygnować z badania prototypów jeśli uznam że jest niepotrzebne.

Temat został chyba wyczerpany :)
30.11.2009, 20:18

Bartłomiej Dymecki User experience

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:
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.

"projektować" nie oznacza zawsze UCD.

Projektowanie to element UCD. Niezależnie od tego, czy rysujesz coś na kartce, czy robisz makiety w wersji elektronicznej. Chyba że pod pojęciem projektowania rozumiesz coś zupełnie dziwnego ;-)
30.11.2009, 20:50

Eryk Orłowski projektowanie
interakcji

Temat: Sensowna krytyka UCD - polecam

myślę, że trochę niepotrzebnie bijecie pianę. Nie chodzi chyba o to, żeby się zgadzało z normą ISO, tylko - żeby cel, któremu służy stosowanie takiego UCD został osiągnięty. Osobiście uważam, iż jeżeli zmontowanie w szybkim sprincie działającego produktu służyć może przetestowaniu produktu właśnie, zamiast prototypu, to nie ma o czym mówić. Testowanie możliwie wczesnych produktów projektu w UCD służy przecież nie samej sztuce dla sztuki, tylko ma na celu uniknięcie wysokich kosztów modyfikacji na późniejszych etapach projektu. Jeżeli w zespole jest projektant, który ma pojęcie o IXD czy UXD, działająca wersja może powstać w max powiedzmy 4 tygodnie, a koszt i czas modyfikacji jest stosunkowo niski, to ja jestem za. Zakładam, że czas poświęcony na kolejne sprinty będzie się mimo wszystko skracał, a po drodze przetestujemy produkt z userami.

Jeżeli komuś udaje się w ten sposób prowadzić zwinnie projekty, szacunek.
30.11.2009, 22:05

Maciek Lipiec User Experience
Director, K2
Internet S.A.

Temat: Sensowna krytyka UCD - polecam

Tomasz B.:

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

Dlaczego? :) Obsługa stała = najlepszy deal :)

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.

My projekty robimy różne. Z kontentowym sajtem w portalu można iść "na żywioł", no problem. Inaczej sprawa wygląda, gdy mówimy o interfejsie bankowości elektronicznej, czy czymś podobnie skomplikowanym. Raz, to ma działać od dnia zero jak najlepiej, dwa - każda drobna zmiana w interfejsie wymusza najczęściej długotrwałe i bardzo kosztowne prace po stronie back-endu.
Tutaj podejście “no dobra, wypuścimy wersje beta i się zobaczy” nie ma racji bytu. Co nie znaczy, że nie ma miejsca na zbieranie feedbacku i tuning :)
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".

Myślę, że każdy się z tym zgodzi.
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.

Ja niestety nie mam zbyt wielu doświadczeń jako projektant na własny rachunek, czego żałuję. Fajnie byłoby sobie tak dłubać i dłubać w projekcie, ale w agencji wiadomo jak wygląda praca z klientem: dedlajn za dedlajnem goni..
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.

Bo to bardzo mądry gość jest jak na guru od usability ;)

pzdr.
m.
1.12.2009, 00:08

Maciek Lipiec User Experience
Director, K2
Internet S.A.

Temat: Sensowna krytyka UCD - polecam

Marcin Śpiewak:
Agencje też nie są zainteresowane analizą po wdrożeniu, bo obawiają się niekorzystnej oceny i roszczeń klienta.

Ee, często bywa, że konkurencyjne firmy testują nasze projekty, albo my audytujemy projekty konkurencji. To jest normalna sytuacja i nigdy mi się nie zdarzyło, żeby klient był szczególnie zaskoczony wynikami. (Jak jest dobrze, to jest dobrze, a jak jest źle, to klient to wie, tylko potrzebuje dokładniejszej analizy).
1.12.2009, 00:45

Marcin Śpiewak wierzę w ludzkie
dobro i semantyczny
HTML

Temat: Sensowna krytyka UCD - polecam

Maciek Lipiec:
Marcin Śpiewak:
Agencje też nie są zainteresowane analizą po wdrożeniu, bo obawiają się niekorzystnej oceny i roszczeń klienta.

Ee, często bywa, że konkurencyjne firmy testują nasze projekty, albo my audytujemy projekty konkurencji. To jest normalna sytuacja i nigdy mi się nie zdarzyło, żeby klient był szczególnie zaskoczony wynikami. (Jak jest dobrze, to jest dobrze, a jak jest źle, to klient to wie, tylko potrzebuje dokładniejszej analizy).

Konkurencyjne tak, ale nie spotkałem się z sytuacją żeby po wdrożeniu, ktoś przetestował serwis który robił i powiedział klientowi "a my nie mamy pańskiego płaszcza i co nam pan zrobi?" ;)
1.12.2009, 02:45

Michał Posiadała Strategy Planner /
Architekt Informacji

Temat: Sensowna krytyka UCD - polecam

Moim zdaniem Przykład źle został rozrysowany :). Nie przeczytałem całego tekstu, ale, to tak jakby poddać prototypowaniu koło.. Stworzenie dobrego prototypu powinno wiązać się z przeznaczeniem danego produktu. Wiadomo, że krzesła nikt nie będzie testował w wersji papierowej, tak samo zaprezentowanego młotka. Natomiast 4 obrazek jest gotowym produktem, a nie prototypem. Jeśli osobiście miałbym zająć się wykonaniem prototypu młotka przełożyłbym to na inny materiał np drewno (tańsze wykonanie prototypu, dostępność materiału itd). Gdzie można by było przetestować odpowiedni stosunek długości trzonka do "główki" młotka, wyważenie itd. następnie odpowiednie zmiany w prototypie, jeśli coś by było nie tak. Następnie przełożenie właściwości produktu na właściwy materiał końcowy.
Podsumowując. Uważam że po prostu trzeba myśleć przy projektowaniu i prototypowaniu i wybierać odpowiednią metodę do wymagań produktu.
3.12.2009, 15:39

konto usunięte

Temat: Sensowna krytyka UCD - polecam

(Ilustracje z młotkiem są zupełnie odklejone od realnej praktyki wzorniczej, zmanipulowane pod "właściwą odpowiedź").
O ile zrozumiałem, autor pije do tego, że proces projektowy kończy się w praktyce tam, gdzie powinien się - doktrynalnie według UCD - dopiero zaczynać.
No to trudno. Tak jak zadaniem UCD jest niewypuszczanie na rynek gumowych młotków, tak rolą projektanta jest znalezienie granicy między koniecznością a fanaberią.Marcin F. edytował(a) ten post dnia 05.12.09 o godzinie 12:56
5.12.2009, 12:55

Temat: Sensowna krytyka UCD - polecam

Mała dygresja.

Czasem szanowni dyskutanci skupiają się na młotku i argumentują przyznając, że nie przeczytali całego artykułu.
Naprawdę tak wszyscy już pędzimy, że nie jesteśmy w stanie zapoznać się dokładnie z tym o czym piszemy?

Jak to się robi, że nie mając kiedy przeczytać, ma się czas pomyśleć o tym, co się ma zamiar napisać. Zakładam, że przy pisaniu jednak myślimy.

Dzięki za wszystkie opinie, wzbogacają wiedzę.
Twój kawałek Eryku o biciu piany też :-)Tomasz B. edytował(a) ten post dnia 10.12.09 o godzinie 09:01
10.12.2009, 09:01

Eryk Orłowski projektowanie
interakcji

Temat: Sensowna krytyka UCD - polecam

Tomasz B.:
Dzięki za wszystkie opinie, wzbogacają wiedzę.
Twój kawałek Eryku o biciu piany też :-)

pocieszające, czasami dręczą mnie wyrzuty sumnienia - z powodu tendencji do duszenia w zarodku zdawałoby się bezproduktywnych dyskusji ;)
10.12.2009, 18:56

konto usunięte

Temat: Sensowna krytyka UCD - polecam

Nie trzeba czytać artykułu (i komentarzy). Wystarczy ominąć młotki i porównać obydwa diagramy - tam jest sedno tekstu Petersena. Drugi diagram nie jest po prostu rozszerzeniem pierwszego o jedno oczko fryzu, jak myślałem poprzednio.
To jest rysunek, który:
- przypomina diagramy próbujące zilustrować kompletny proces projektowy;
- da się odnieść do dziedzin w których skutecznie stosuje się UCD (np. moda sezonowa).
Zatem pewnie pokazuje proces UCD.
12.12.2009, 11:59

Jakub M. Speechstorm / Kainos
Software Ltd.

Temat: Sensowna krytyka UCD - polecam

Odświeżę temat ;-)
Piszecie pięknie o współpracy z klientem, klientem agencyjnym itp z tym że jeżeli klient jest w NYC, jego użytkownicy jeszcze gdzie indziej, projektant w Sydney a zespół wytwórczy gdzieś w Europie to co? :-) Praktyki iteracyjne (zarówno w sensie zarządzania całym procesem, jak i iteracyjne podejście do projektowania - UCD) wydają się być (przynajmniej na obecną chwilę, przynajmniej dla mnie) jedynym sensownym podejściem do takiego projektu. A biorąc wspomniane UCD na warsztat (i nie będąc nazbyt 'doktrynalnym') otrzymujemy całkiem poważne narzędzie jak ustawić współpracę w takim rozproszonym zespole: szkice, wireframe'y, prototypy. I nawet jeśli nie będzie to testowane z użytkownikami, to uzyskane usprawnienie w przepływie informacji będzie nie do przecenienia.

Istotą metodyk iteracyjnych (a przede wszystkim wywołanego SCRUM'a) jest to że po każdym sprincie powstaje funkcjonalność która jest gotowa do wdrożenia (i nawet jeżeli nie jest wdrażana - to może być testowana). Idąc dalej tym torem, SCRUM 'nie ma nic przeciwko' aby sprint obejmował zarówno implementację funkcjonalności A, jak i przygotowanie prototypu funkcjonalności B. Dla SCRUM'a (w uproszczeniu) istotne jest aby po zakończeniu sprintu prace nad funkcjonalnościami były zostały ukończone, a ewentualne zmiany to kolejne zadania na kolejny sprint.
18.12.2009, 00:39



Wyślij zaproszenie do