Steve Krug swojej książce pt.: “Nie każ mi myśleć! O życiowym podejściu do funkcjonalności stron internetowych” zaleca przeprowadzanie testów z użytkownikami na jak najwcześniejszym etapie prac.
Generalnie zgadzam się z takim podejściem do projektowania i budowania aplikacji i serwisów internetowych. Pojawiła się jednak sytuacja, w projekcie nad którym obecnie pracuję, która wymogła zmiany w interfejsie. Zmienić się ma sposób w jaki klient konfiguruje i kupuje produkt.
Zmian w kodzie dużo nie ma, ale dochodzi konieczność dopisania kilku funkcji w javascript. Intuicja podpowiada że zmiana będzie korzystna (dlatego na nią się zdecydowaliśmy). Nie bardzo widzę możliwości przetestowania jej na makietach papierowych (duża ilość ajaxowych elementów). Czas nas goni, budżet jest mały, więc intuicja musi wystarczyć.
I tutaj jest miejsce na moje pytanie. Testować jak najwcześniej: przy pomocy “sąsiadów” wersję “zabugowaną”; czy doprowadzić kod do porządku i dopiero wtedy testować?
- Pierwsza wersja oszczędzi potencjalnie niepotrzebnej pracy i może wskazać pułapki których nie widzimy. Niestety ewentualne błędy w kodzie będą miały wpływ na testowanie i test może być niemiarodajny.
- Wersja druga pokaże prawdziwszą prawdę co do ergonomii nowego rozwiązania ale na późniejszym etapie. A konieczne zmiany do zmian mogą kosztować i co najgorsze zająć dodatkowy czas którego nie mamy.
Ponieważ serwis budowany jest w ramach sił własnych, nie stać nas na zatrudnienie specjalisty ux. Z drugiej strony jakąś tam wiedzę w temacie mam więc nie powinno być tragedii.
Jeśli więc macie jakieś doświadczenia z podobnymi sytuacjami chętnie przeczytam Wasze sugestie.
Z końcem roku, po ponad trzy i półrocznej pracy, rozstałem się z Drukarnią Print. Poszedłem
na swoje. Razem z Mateuszem pracujemy nad kilkoma projektami, w tym dwoma swoimi. Dzięki niemu nie muszę zajmować się stroną papierkowo-organizacyjną związaną z prowadzeniem projektów i mogę skupić się nad tym w czym jestem naprawdę dobry.
Docelowo ta nasza działalność przekształci się w agencję interaktywną czy inne studio developerskie (i będziemy obrzydliwie bogaci).
Na razie, rozkoszuję się pracą dla siebie
. I uprzedzając: Wiem że praca na własny rachunek nie jest mniej stresująca (a często bardziej) niż praca na etat. Mam już za sobą prowadzenie działalności gospodarczej i wiem jak to smakuje. Zapomniałem tylko jak to jest gdy nie musisz siedzieć bezsensownie w biurze by wyrobić godziny
.
Jak to bywa na początku: jestem pozytywnie nastawiony i z optymizmem patrzę w przyszłość. I nie musicie trzymać kciuków. Mój sukces zależy w dużej mierze od ilości i jakości mojej pracy więc jestem spokojny.
Ostatnio w związku z awarią jedynego firmowego serwera z Windows Server 2003 na pokładzie musiałem zmienić konfigurację w kilku programach. Na większości stanowisk udało się to zrobić przed przyjściem osobników z nich korzystających. Niestety nie wszędzie. Do jednego z pomieszczeń nie miałem dostępu. Pech chciał że był to dział księgowości. Zmiany w konfiguracji, i tak się złożyło że również upgrade programu, musiałem przeprowadzić z użytkowniczkami “na plecach”. No i zaczęło się. Co 5 minut telefon.
A to nie działa, a tamto nie działa.
A ten komputer jakiś taki wolny po tym jak grzebałeś.
I ciągłe narzekania. Tak się składa że identyczne zmiany na innych stanowiskach w innych pomieszczeniach nie dawały takich efektów. Oczywiście wszystkie te “nie działa” wynikały z tego, że łatwiej jest zadzwonić z prośbą o interwencję, niż sprawdzić czy na pewno wszystko zrobiło się tak jak trzeba.
Po raz n-ty sprawdziły się moje doświadczenia. Jeśli wprowadzasz zmiany które dla użytkownika nie są widoczne, przeprowadź je tak, żeby nie widział że coś robisz. Inaczej będziesz miał od cholery i jeszcze trochę bezsensownych zgłoszeń.
