Temat: Umiejscowienie prac nad użytecznością przy projektach...

Witam :)

Zastanawiam się jak najlepiej umiejscowić pracę nad użytecznością serwisu internetowego w projekcie. W jakiej sekcji/ dziale takie osoby powinny pracować by wykorzystać ich wiedzę?

Czy możecie opowiedzieć kiedy u was pojawia się ocena z punktu widzenia usability, czy może towarzyszy na każdym etapie? Jaką faktyczną moc oddziaływania mają opinię osób od UX? A może macie w głowie jakieś dobre przykłady zaobserwowane gdzieś indziej?



Wojtek

Temat: Umiejscowienie prac nad użytecznością przy projektach...

przede wszystkim chyba project menagerowie przy tworzeniu koncepcji strony i jej nawigacji, przy okazji to oni moga hamowac kreatywnych przed fajerwerkami i reszta zespolu majac nadzor nad wszystkim

oczywiscie najfajniej by bylo zeby caly team kierowal sie wytycznymi uzytecznosci ale przy niewyspecjalizowanej scisle w tym agencji byloby trudno

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Dział projektowy a dokładnie architekt informacji...

Użyteczność serwisu powinna być omawiana na etapie tworzenia projektu funkcjonalnego. Posiadając już prototyp serwisu (makiety klikalne) powinniśmy zadbać o testy użyteczności na osobach, które nie brały udziału w projekcie.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Trzy sprawy:
1. Na etapie projektowania należy po prostu wykorzystywać narzędzia, które jakby automatycznie nakierowują naszą uwagę na projektowanie dla użytkownika. Mam na myśli choćby persony.

2. Podczas realizacji wszyscy członkowie zespołu stykający się z interfejsem powinni mieć obowiązek regularnych inspekcji tego nad czym pracują. Można wykorzystać np. listy kontrolne.

3. Kroki projektu, po których coś otrzymujemy - layout, wstępny prototyp, działający prototyp podlegają osobnemu przejrzeniu przez kogoś niezwiązanego bezpośrednio z pracami nad projektem. Może być to jedna osoba w firmie na kilka projektów, albo kierownik projektu, albo ktoś z zewnątrz. Tutaj też, jeśli jest taka konieczność, przeprowadzamy testy.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

1. Na etapie projektowania należy po prostu wykorzystywać narzędzia, które jakby automatycznie nakierowują naszą uwagę na projektowanie dla użytkownika. Mam na myśli choćby persony.

Serwisy projektować powinni ludzie, którzy się na projektowaniu znają, więc takie systemy nie są koniecznością i zależą raczej od stylu pracy takiej osoby.

2. Podczas realizacji wszyscy członkowie zespołu stykający się
z interfejsem powinni mieć obowiązek regularnych inspekcji tego > nad czym pracują. Można wykorzystać np. listy kontrolne.

To w małych zespołach bez sensu (bo i tak wszystko robi się w praktyce razem), a w dużych nierealne. Chyba, że uda się nam skompletować zespół cyborgów.. :)

3. Kroki projektu, po których coś otrzymujemy - layout, wstępny
prototyp, działający prototyp podlegają osobnemu przejrzeniu przez kogoś niezwiązanego bezpośrednio z pracami nad projektem.

A wcześniej przez testerów (którzy porównują zgodność tego co wyszło z projektem), ew. przez samych projektujących (to oczywiście lepsze rozwiązanie, o ile mają na to czas).

Może być to jedna osoba w firmie na kilka projektów, albo kierownik projektu, albo ktoś z zewnątrz. Tutaj też, jeśli jest taka konieczność, przeprowadzamy testy.

Tak ogólniej, to przychylam się do zdania Grzegorza Rusieckiego, z tym, że dodałbym, że raczej nie powinno się ściśle trzymać projektu, procedur (choć to oczywiście też, póki to zdrowe), a po prostu developerzy i projektanci powinni się czasem spotkać, obgadać to nad czym pracują, co powinno skutkować zmianami w projekcie (o ile nie był od początku idealny..).

Imo kluczowa jest dobra komunikacja między działem projektu a developerami i ludzie, którzy komunikować się chcą. Programista, który przejdzie się czasem do działu projektowego mówiąc, że coś dałoby się zrobić lepiej, z własnymi propozycjami, czy też z informacją, że coś jest zbyt złożone do wykonania, albo z drugiej strony - architekt doglądający czasem co tam uprogramistów słychać - taki zespół i taki styl pracy to znacznie lepsze rozwiązanie od ścisłych procedur, ścisłych obowiązków inspekcji, automatycznych narzędzi i innych...

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Pytasz o analityków użyteczności, ale nie wspomniałeś, kto w Twoich projektach będzie projektował komunikację wizualną...

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Kamil T.:

Serwisy projektować powinni ludzie, którzy się na projektowaniu znają, więc takie systemy nie są koniecznością i zależą raczej od stylu pracy takiej osoby.

I to, że "się znają" zwalnia ich z korzystania z narzędzi? Jasne, jeśli obok siebie pracują dwie osoby i to jest cały "zespół", nie ma co myśleć o bardziej formalnych metodach. Ale persony przydają się już przy kilku osobach pracujących nad projektem.

To w małych zespołach bez sensu (bo i tak wszystko robi się w praktyce razem), a w dużych nierealne. Chyba, że uda się nam skompletować zespół cyborgów.. :)

Dlaczego nierealne? Niezbyt znam się na programowaniu w dużych zespołach, ale zdaje się że normą jest codzienna inspekcja kodu. Dlaczego ma nie być codziennej inspekcji usability?

Imo kluczowa jest dobra komunikacja między działem projektu a developerami i ludzie, którzy komunikować się chcą.

Z tym się absolutnie zgadzam. Nie wolno tworzyć odrębnych światów. Ale z drugiej strony musi być jakaś platforma dyskusji nad projektem i tą zapewniają narzędzia.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Robert D.:

Kamil T.:
Serwisy projektować powinni ludzie, którzy się na projektowaniu znają, więc takie systemy nie są koniecznością i zależą raczej od stylu pracy takiej osoby.

I to, że "się znają" zwalnia ich z korzystania z narzędzi? Jasne, jeśli obok siebie pracują dwie osoby i to jest cały "zespół", nie ma co myśleć o bardziej formalnych metodach. Ale
persony przydają się już przy kilku osobach pracujących nad projektem.

True, masz rację. Trochę za mocno wyraziłem swoje zdanie o tym, że jestem wrogiem stricte analitycznego podejścia do tak humanistycznych kwestii jakimi są usability. Uważam, że robienie rzeczy na wyczucie (o ile wcześniej posiadło się stosowną wiedzę, praktykę i przede wszystkim się to wyczucie ma) jest dobre, także kiedy efekt nie jest zgodny z jakimiś usability-wzorcami.

To w małych zespołach bez sensu (bo i tak wszystko robi się
w praktyce razem), a w dużych nierealne. Chyba, że uda się nam skompletować zespół cyborgów.. :)

Dlaczego nierealne? Niezbyt znam się na programowaniu w dużych
zespołach, ale zdaje się że normą jest codzienna inspekcja kodu. Dlaczego ma nie być codziennej inspekcji usability?

Bo pisanie kodu polega zwykle na "robieniu tak, żeby wyglądało i działało jak na projekcie". Świadomi programiści dodatkowo przy tym myślą i rozmawiają o problemach i brakach jakie wyszły w trakcie z projektantami. Znacznie lepiej, łatwiej, szybciej i przede wszyskim mniej upierdliwie jest najpierw projektować, potem programować, potem sprawdzać, przeprojektywywać, programować. Chyba, że inspekcjami nazywamy luźne rozmowy na temat tego nad czym się pracuje - wtedy to jest okej, ale KAŻDA kolejna warstwa formalizmu, każda kolejna procedura, punkt w procedurze to ZŁO :)
A dodatkowo w naszej internetowej branży (bo o tej wyłącznie się wypowiadam), z naszą mentalnością nierealizowalne :)

P.S
Wszystko to co mogą robić programiści (poza pisaniem kodu) mogą i powinni robić też szefowie teamów, byle w możliwie nieintruzywnej formie..Kamil T. edytował(a) ten post dnia 31.05.07 o godzinie 10:48

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Cześć Wojtek :)

Zastanawiam się jak najlepiej umiejscowić pracę nad użytecznością serwisu internetowego w projekcie.

Od początku do końca. Najpierw określenie wymagań funkcjonalnych, potem makiety interfejsu, potem rozmawianie o projekcie z grafikami i developerami.

W jakiej sekcji/ dziale takie osoby powinny pracować by wykorzystać ich wiedzę?

Chyba najlepszym wyjściem jest niezależność od innych działów w firmie, bo i tak trzeba się mieszać we wszystko ;) Jeśli ta osoba nie będzie się zajmowała projektowaniem interakcji na full time, to niech będzie project managerem. Nie do końca mnie przekonuje umieszczanie UX w działach strategii, jak to się często dzieje, bo to jednak poziom konkretu i realizacji, a nie "wizji" czy marketingowego bullshitu.Maciek Lipiec edytował(a) ten post dnia 31.05.07 o godzinie 22:10

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Maciek L.:

Chyba najlepszym wyjściem jest niezależność od innych działów w firmie, bo i tak trzeba się mieszać we wszystko ;)

Maćku, a zdradzisz, jak to w Twojej firmie wygląda? Masz jakąś niezależność? Graficy i kreatywni nie podstawiają nóg w korytarzu? ;-)

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Maciek L.:

Chyba najlepszym wyjściem jest niezależność od innych działów w firmie, bo i tak trzeba się mieszać we wszystko ;) Jeśli ta osoba nie będzie się zajmowała projektowaniem interakcji na full time, to niech będzie project managerem. Nie do końca mnie przekonuje umieszczanie UX w działach strategii, jak to się często dzieje, bo to jednak poziom konkretu i realizacji, a nie "wizji" czy marketingowego bullshitu.

podpisuję się. Pan Maciek ma obecnie przegląd możliwości więcej niż jednej agencji ;)

U nas to działa dokładnie w opisany sposób. Jako osobny business unit, który uczestniczy w całym procesie produkcji. Od burzy mózgów, na której uczestniczymy w dyskusjach nt. pomysłów na funkcjonalności systemu, poprzez tworzenie wstępnej koncepcji specyfikacji funkcjonalnej rękami ludzi z user experience, tworzenie szablonów architektury informacji, prototypowanie - do momentu wyprodukowania i oceny (z udziałem użytkowników - jeżeli pan klient wysupła $) pełnej specyfikacji - na podstawie której pracuje kreacja i technologia.

Nie wiem, jak się żyje zespołowi od tego w k2, ale u nas mamy całkowitą niezależność. Co oczywiście nie oznacza braku konieczności uzgogdnień na codzień z kreacją i technologią. Czasami faktycznie kreację boli to i owo ;) Ale dogadujemy się - na ogół :D

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Robert D.:

Maćku, a zdradzisz, jak to w Twojej firmie wygląda? Masz jakąś niezależność? Graficy i kreatywni nie podstawiają nóg w korytarzu? ;-)

Każdy kto pracował w agencji wie, że istnieją odwieczne napięcia na linii account vs. kreacja vs. IT - AI jest po prostu kolejną stroną w tej świętej wojnie ;D

W tej chwili podlegamy bezpośrednio pod jednego z dyrektorów zarządzających.
AI jest dosyć nowym zjawiskiem w K2 i cały czas jeszcze jesteśmy na etapie opracowywania różnych wewnętrznych procedur.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Ja jako architekt :) pozwolę sobie odwołać się do bardzo prostej definicji architektury jako procesu konstruowania estetycznego i funkcjonalnego obiektu. W przypadku architektury wygląda to ta:

Funkcja -> Forma -> Konstrukcja

To pokazuje pewną logiczną kolejność, wynikających z siebie etapów owego procesu. Biorąc pod specyfikę internetu czy aplikacji w ogóle, zamiast Konstrukcji mamy oczywiście technologię. Najważniejszym etapem z punktu widzienia użyteczności jest oczywiście funkcja i to z niej wynikają kolejne etapy.

Oczywiście podpisuje się pod świętą wojną bo sam tego doświadczyłem pracując jeszcze w agencji. Natomiast wiem też że zwykle wszystkie spięcia wynikają z tego że czesto wszystkie wspomniane etapy nie zachowują swojej kolejności. Jeżeli grafik dostanie dokładne układy layoutów które ma zaprojektować to to zrobi, natomiast wiem doskonale że będzie kręcił nosem na wszelkie poprawki, podobnie z programistami, jeżeli dostaną dobrze rozpisane procesy do oprogramowania i nie będą musieli zmieniać wszystkiego 5 razy to też nie będą jęczeć a przynajmniej mniej niż zazwyczaj.

Tak więc reasumując. Moim zdaniem klucz do dobrej praktyki usability przy projektowaniu leży w zamykamiu kolejno wyżej wymienionych etapów. Mówie oczywiście o stronie organizacyjnej.

Parokrotnie zdarzyło nam się wykonywać audyt świeżo skończonej strony (już postawionej) i zawsze był to ból, bo trzeba było cofać się do samego praktycznie początku, tak wiec defacto były to badania użyteczności istniejącej aplikacji a nie badania przy projektowaniu jak podchodził do tego klient.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Jarek M.:
To pokazuje pewną logiczną kolejność, wynikających z siebie etapów owego procesu. Biorąc pod specyfikę internetu czy aplikacji w ogóle, zamiast Konstrukcji mamy oczywiście technologię. Najważniejszym etapem z punktu widzienia użyteczności jest oczywiście funkcja i to z niej wynikają kolejne etapy.

nie zgadzam się z takim uproszczeniem sprawy. Co do podstaw - rzecz jasna, że logika procesu projektowego powinna przebiegać wedle opisanej kolejności. Ale to spore niedopowiedzenie. Zobacz poniżej.

Oczywiście podpisuje się pod świętą wojną bo sam tego doświadczyłem pracując jeszcze w agencji. Natomiast wiem też że zwykle wszystkie spięcia wynikają z tego że czesto wszystkie wspomniane etapy nie zachowują swojej kolejności. Jeżeli grafik dostanie dokładne układy layoutów które ma zaprojektować to to zrobi, natomiast wiem doskonale że będzie kręcił nosem na wszelkie poprawki, podobnie z programistami, jeżeli dostaną dobrze rozpisane procesy do oprogramowania i nie będą musieli zmieniać wszystkiego 5 razy to też nie będą jęczeć a przynajmniej mniej niż zazwyczaj.

Będą jęczeć tak długo, dopóki podejmować będziesz trud przekonywania ich, że wszelkiego rodzaju aktualizacje są wynikiem wprowadzania poprawek, a więc w domyśle - ktoś wcześniej popełnił błąd, o czymś zapomniał. Tymczasem przy większych projektach, zwłaszcza związanych z przeprojektowaniem czegoś istniejącego, milion rzeczy po prostu MUSI wyjść już po oddaniu specyfikacji funkcjonalnej do kreacji i technologii. Wynika to choćby z samego założenia projektowania iteracyjnego. Niektóre funkcje aplikacji okazują się być zaprojektowane tak, że użytkownicy nie potrafią z nich korzystać. Pół biedy, jeżeli udało się przekonać klienta do przeprowadzenia kilku cykli testów, po których problemy są eliminowane możliwie wcześnie...

Rzecz jasna, nie stanowi to żadnego wytłumaczenia dla faktycznych błędów.

eof @ http://offline.pleryk orłowski edytował(a) ten post dnia 24.06.07 o godzinie 22:03

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Uproszczenie w tym wypadku jest konieczne, bo pokazuje pewien optymalny model. To chyba zresztą normalne.

Co do projektowania iteracyjnego, no cóż wiadomo że przynajmniej jedno sprawdzenie poprawności wdrożenia musi być i jest to moim zdaniem kwestia uczciwości w stosunku do klienta. Nam w metodologii komplementarnej (heurystyka, deklaracja, pomiar) to zwykle wystarcza (wytyczne, projekt, wrdozenie, badanie, poprawki, badanie, raport).

Ale z takim podejściem nie mogę się zgodzić : "Niektóre funkcje aplikacji okazują się być zaprojektowane tak, że użytkownicy nie potrafią z nich korzystać" - A ja myślałem że po to się robi grupy kreatywne albo FGI czy IDI w trakcie budowania modelu funkcjonalnego żeby takich sytuacji uniknąć. Chyba że ktoś swoją wiedzę ekspercką lubi destylować iteracyjnie :)

Jasnym jest że im większy projekt tym większe ryzyko błędu w którymś momencie projektowania. Dlatego moim zdaniem kluczem do uniknięcia podobnych sytuacji jest odpowiednie zaprojektowanie samych badań poprzedzających budowanie funkcjonalności.

Wracając jednak do głównego wątku. Mogę chyba zaryzykować stwierdzenie że jesteśmy zgodni co do tego że podstawą dobrego i użytecznego serwisu są jego mocne podstawy funkcjonalne poprzedzające dalsze prace designerskie i developerskie. Bez względu na ilość potencjalnych iteracji, zawsze pierwszy krok powinien się kończyć modelem funkcjonalności. I to właściwie moim zdaniem jest odpowiedz na pytanie zawarte w temaci wątku.

pozdr
/jJarek Muras edytował(a) ten post dnia 25.06.07 o godzinie 20:34

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Jarek M.:
Ja jako architekt :) pozwolę sobie odwołać się do bardzo prostej definicji architektury jako procesu konstruowania estetycznego i funkcjonalnego obiektu. W przypadku architektury wygląda to ta:

Funkcja -> Forma -> Konstrukcja

Żeby to było takie proste :) Zdecydowanie muszę się tutaj zgodzić z Erykiem. Czasem pewne funkcjonalności, które przyjęliśmy na wstępie jako wymagane rodzą zbyt duże komplikacje przy projektowaniu interfejsu i nagle okazuje się, że lepiej z nich zrezygnować. Albo coś co wydawało się OK na makiecie nie sprawdza się na layoucie. Podobnie pod względem technologicznym - coś co zostało opisane w specyfikacji funkcjonalnej i zaakceptowane prze IT przy produkcji zaczyna np. powodować nagle kłopoty z wydajnością. I zmieniamy, zmieniamy... Duży projekt zawsze zmienia się w trakcie jego trwania, nie z powodu błędów, ale po prostu pewne problemy są wcześniej nie do przewidzenia. Może Wasz spór to jest różnica optyki między firmą konsultingową a full service.

Kłopot w tym, żeby firma była w stanie to zaakceptować jako stan normalny (i przekonać do tego klienta!), że albo będą poprawki albo będzie słaby projekt. Czas żeby agencje zrozumiały, że duże i skomplikowane projekty informatyczne, które coraz częściej realizują wymagają innej metodyki pracy niż stronki produktowe we flashu. Tu potrzebny jest czas na samą fazę koncepcyjną, projektowanie, dokumentację, kolejne iteracje.

Z drugiej strony wiadomo jak wkurzającą rzeczą w tej pracy jest sytuacja kiedy siedzisz nad czymś tydzień analizując różne możliwości, dochodzisz do kompromisu, prezentujesz to zespołowi, nikt nie ma uwag, a za parę dni patrząc na stronę główną grafik, account albo klient ;) stwierdza "ale musimy przesunąć to menu z góry na dół", nie mając świadomości że wprowadzając jedną zmianę rozpieprza jakośtam skonstruowaną spójną całość w 20 innych miejscach...

Uff. Właśnie wróciłem z badań prototypu zmęczony okrutnie. Idę się relaksować :D

pzdr.

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Jarek M.:

Ale z takim podejściem nie mogę się zgodzić : "Niektóre funkcje aplikacji okazują się być zaprojektowane tak, że użytkownicy nie potrafią z nich korzystać" - A ja myślałem że po to się robi grupy kreatywne albo FGI czy IDI w trakcie budowania modelu funkcjonalnego żeby takich sytuacji uniknąć. Chyba że ktoś swoją wiedzę ekspercką lubi destylować iteracyjnie :)

>

FGI, grupy kreatywne czy IDI służą pozyskiwaniu wiedzy na temat tego CO jest potrzebne odbiorcy, a nie tego, w jaki sposób realizować ma to coś interfejs użytkownika.Zbieranie wymagań w stosunku do GUI zamiast wymagań funkcjonalnych jest drogą na skróty i może doprowadzić do problemów,wreszcie - jest sprzeczne z kierunkiem implikacji funkcja->forma->konstrukcja. Po prostu się zapętlamy ;-)

Co do ostatniego akapitu - z tym się nie da nie zgodzić, rzecz jasna :)

ukłony

eof @ http://offlinepl

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Wkradło mam się małe niezrozumienie :) My używamy FGI, IDI czy gk, nie tylko aby dowiedziec sie CO, a więc jakie funkcje są potrzebne ale, co moim zdaniem równie ważne - JAK powinien wyglądać proces, przy czym <u>nie mówie o jego formalnej realizacji (forma i technologia) a wewnętrznej logice</u>. Ten etap jest również wartościowy jako weryfikacja i uzupełnienie założeń wynikających z badania eksperckiego.

Przy czym myśląc o ekspercie mam na myśli osobę która raczej będzie wiedzieć "co sprawdza sie na layoucie" albo może zostać zaakceptowane przez dział IT :) Znajomość fizjologii i psychologii percepcji wzrokowej napewno mogą pomóc podobnie jak praktyka projektowa po stronie wykonawczej.

Tu właśnie chciałem odnieść się do wypowiedzi Maćka. Błedy popełniane przez ekspertów którzy uczą sie na własnych błędach, nie są argumentem w dyskusji, ani powodem dla którego klient powinien się godzić na płacenie za 50 iteracji. Według mnie znajomość specyfiki prac des i dev jest kluczem do w miare bezbolesnego wdrozenia modelu funkcjonalności. Po latach pracy w designie i paroletniej przygodnie z programowaniem mam dodatkową perspektywę patrzenia na realność realizacji założeń pierwszego - funkcjonalnego etapu.

pozdrJarek Muras edytował(a) ten post dnia 27.06.07 o godzinie 21:21

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Jarek M.:

Przy czym myśląc o ekspercie mam na myśli osobę która raczej będzie wiedzieć "co sprawdza sie na layoucie" albo może zostać zaakceptowane przez dział IT :) Znajomość fizjologii i psychologii percepcji wzrokowej napewno mogą pomóc podobnie jak praktyka projektowa po stronie wykonawczej.

Tu właśnie chciałem odnieść się do wypowiedzi Maćka. Błedy popełniane przez ekspertów którzy uczą sie na własnych błędach, nie są argumentem w dyskusji, ani powodem dla którego klient powinien się godzić na płacenie za 50 iteracji. Według mnie znajomość specyfiki prac des i dev jest kluczem do w miare bezbolesnego wdrozenia modelu funkcjonalności. Po latach pracy w designie i paroletniej przygodnie z programowaniem mam dodatkową perspektywę patrzenia na realność realizacji założeń pierwszego - funkcjonalnego etapu.

>

Szczerze mówiąc, ja tego nie kupuję. Testy makiet na kilku etapach projektowania nie służą weryfikowaniu, czy projektant popełnił błąd. Projektant nie jest i nigdy nie będzie odbiorcą swoich własnych projektów, niezależnie od posiadanej wiedzy i doświadczenia. Sądziłem, że nikogo już nie trzeba przekonywać do cyklów testów interakcyjnych. Z całym szacunkiem, ale nacisk na testowanie prototypów kładą ludzie o doświadczeniu i wiedzy z bajki nauk kognitywnych większych niż Twoje czy moje. Jakoś nie mogę uwierzyć, że po prostu macie tak dobre samopoczuci w związku ze "znajomością specyfiki", "pracą w designie", czy nawet "znajomością fizjologii percepcji wzrokowej"...

ukłony

eof @ http://offline.pl

Temat: Umiejscowienie prac nad użytecznością przy projektach...

Zaczne od końca :) z samopoczuciem różnie bywa. Chodziło mi bardziej o to że jesteśmy w stanie uniknąć na etapie monitoringu wdrożenia sytuacji o których pisał Maciek, czyli tego że coś nie zagra w layoucie albo średnio da się sensownie oprogramować. I to miałem na myśli pisząc o tym że doświadczenie wykonwcze pomaga. Dodatkowo jesteśmy w gorszej sytuacji z zewnątrz monitorując wdrożenie niż dajmy na to osoba która robiła by to wewnętrznie w ramach firmy czy działu. Dlatego jest dla nas szczególnie ważne uniknięcie wspomnianych sytuacji.

Tak sobie myślę że my mamy trochę inną metodologię pracy. U nas z wiadomych względów bardzo ważną rolę odgrywa eyetracking, oraz doświadczenie i pewne zasady które pojawiają się po pewnej ilości przeprowadzonych projektów z użyciem tej metody. Jak to powiedziała ostatnio jedna z osób w firmie - jak patrze na projekt to już wiem jakie będą na nim fiksacjie i mapy cieplne :). Oczywiście jest to radosne uproszczenie. Druga sprawa że często siadając do makiety mamy juz wyniki ET z istniejącego sajtu lub / i wyniki badania stron konkurencyjnych. Dlatego projekty są prowadzone troche w inny sposób i z innym materiałem wejściowym niż zazwyczaj. Ten materiał pomiarowy skonfrontowany z materialem deklaratywnym czy eksperckim, pozwala nam uniknąć dużej liczby iteracji.

Na tym narazie muszę zakończyć mój udział w tej przemiłej dyskusji :) Jutro wyjazd na OpenAir a po nim tydzień zmagań z wiatrem i falami bałtyku. Z przyjemnością włączę się w dyskusję po powrocie (8.07).

Pozdrawiam i życzę wszystkim miłego weekendu.
/j