pisz się na to
zgrzyt

OpenID.pl


LinkedIn
Blog > Komentarze do wpisu

pola namiotowe i crowdtesting

  • dwie refleksje po wizycie andy''ego budda i wysłuchaniu jego prezentacji.
  • pierwsza z nich dotyczy w gruncie rzeczy granic metafor, jakimi posługiwał się andy w swoich prezentacjach. najczęstszą z nich była metafora budynku. zwłaszcza w pierwszej prezentacji bootstrapowej, andy porównywał strony internetowe do obiektów architektury. muszę przyznać, że działało to na wyobraźnię, ale każda metafora ma swoje granice i ta również. po przemyśleniu, te granice zaczęły się wyłaniać bardzo wyraźnie.
  • pierwsza różnica - i tu nie będę specjalnie odkrywczy - to kwestia tego, że budynki budowane są by się nie zmieniać, zaś serwisy internetowe - wręcz przeciwnie. stąd projektując budynek staramy się by spełniał on wszystkie potrzeby użytkowników w tym stanie, w którym powstał, zaś projektując stronę internetową staramy się by w przyszłości można było ją rozbudować.
  • druga różnica to wynik bardziej lokalnego spojrzenia. stety, czy niestety, w naszym kraju dominuje coś, co nazywam "taktyką pola namiotowego". duzi gracze nie koncentrują się na stawianiu wypasionych budynków. zamiast tego rozbijają namioty, stawiają "szczęki", klecą dość bylejakie budki, chętnie posługując się prefebrykatami: zajmują teren. trudno odmówić temu sensu biznesowego, tak jak niewątpliwy sens biznesowy miały w latach 90 wszechobecne bazarowiska, wołające pod wzgledem estetyki o pomstę do nieba, a jednak działające i generujące przychody. jak więc zastosować wskazówki, o których mówił andy, skoro celem jest po prostu "zajęcie niszy" i "obecność"? robienie wykładu na temat marketingu zapachowego gościowi, który sprzedaje w upalny dzień cielęcinę z brudnego żuka jest chybione. różnicę pomiędzy światem, o którym mówił andy, a tym co mamy tutaj, dobrze obrazuje przykład firmy obvious, która stworzyła twittera i w obliczu jego sukcesu dość szybko pozbyła się swojego innego produktu. u nas zapewne zamiast czegokolwiek  się pozbywać, po roku aspirowałaby do miana portalu, tworząc fafanaście innych serwisów. wracając do budda i jego prezentacji: namioty buduje się trochę inaczej niż budynki. mając daną grupę docelową, która i tak nie opuści danego poletka (bo tam, za miedzą, mówią w obcych językach), dlaczego mamy się starać? niech serwis spełnia podstawowe potrzeby z piramidy maslowa a będzie dobrze. jak nie będzie dobrze, to... nie, oczywiście, że się go nie zamknie, ale postawi się kilka innych, podobnych namiocików, może tam się użytkownik poczuje swojsko. nie ma czasu na refleksję, na dbanie o szczegóły, bo jeśli "stracimy" na to czas, okaże się, że na upatrzonym poletku swój baraczek postawiła konkurencja.
  • druga refleksja dotyczy granic badań usability. z rozmów, które prowadziłem z andym przez weekend, można było odnieść wrażenie, że traktuje on usability bardzo praktycznie i jest świadom jego ograniczeń. to bardzo mnie ujęło, trudno się bowiem rozmawia z kimś, kto uważa, że whateverity jest panaceum na wszystko i gotową receptą na sukces w proszku, dodać wrzątek, wymieszać i gotowe. bodajże michał z nozbe zapytał o testy usability dotyczące pozyskiwania płatnych kont i czy można jakoś, dzięki badaniom, radykalnie poprawić sprzedaż. otrzymał odpowiedź, że owszem, można zbadać czy miejsce, w którym proces zakładania płatnego konta się rozpoczyna jest widoczne dla użytkownika, a następnie zbadać cały proces, ale tak naprawdę, testy usability to testy usability. a nie testy propozycji biznesowej, która może być nieatrakcyjna, nawet jeśli jest doskonale widoczna i świetnie dopracowana pod względem użyteczności. usability jest więc dobrym narzędziem, ale jednak działającym dość "atomowo", na pojedynczych procesach. jest jak "zawartość kaloryczna" dla potrawy. potrawa kaloryczna może być całkiem niesmaczna (pomijam tu fakt, że coraz wiecej osób je, żeby się odchudzać).
  • ale nie o tym chciałem pisać. wydaje mi się, że są też inne granice badań usability, chyba, że już wymyślono jak je przełamać. dotarliśmy do nich kiedyś pisząc blipa. owszem, można było przebadać proces zakładania konta. proces pisania wiadomości. proces aktywowania komunikatora i setki innych procesów. ale jak przebadać np. to, czy nie wysyłamy za dużo komunikatów? czy kokpity mają właściwą treść? blip i nie tylko blip, to aplikacje stricte społeczne. jesteśmy tam ze znajomymi. kiedy nie mamy znajomych, tracą cały sens.
    • załóżmy, że testujemy, ile komunikatów powinien otrzymywać użytkownik, tak by był zadowolony. być może średnio 20 komunikatów dziennie to za dużo. ale jeśli użytkownik ma w serwisie 5 naprawdę bardzo bliskich mu osób? 20 a nawet 40 dziennie może okazać się zupełnie akceptowalną liczbą. a jeśli są to osoby, które on ledwo zna, to i 5 może go drażnić. jak to przebadać? symulowanie znajomych? "wyobraź sobie, że ten użytkownik to kolega z pracy, a tamten to twój brat"? takie symulacje są bez sensu. można posadzić usera przed interfejsem i kazać mu komunikować się z maszyną, ale zasymulować jego sieć społeczną jest niezwykle trudno. przypomina to testowanie wnętrza dyskoteki na pojedynczych osobach. zapraszamy kogoś do pustej sali i pytamy, czy dobrze się czuje albo śledzimy jego zachowania. nie można dobrze się czuć będąc samemu na imprezie, #epic fail. ok, możemy poustawiać tam statystów. nadal #fail. nie chodzimy na imprezy poprzebywać wśród losowej próbki osób. stąd testując blipa próbowaliśmy zrobić coś w rodzaju "testowej imprezy" zapraszając kilkanaście osób, które mogły się znać i pozwalając im zaprosić jeszcze kilka, tak, żeby powstało środowisko testowe, przypominające to, co będzie działo się później w serwisie. to już jest całkiem niezłe przybliżenie.
    • nazywam to roboczo "crowdtestingiem". testowanie aplikacji społecznych, zwłaszcza tych, w których komunikacja następuje synchronicznie i w czasie rzeczywistym, to zupełnie nowa działka, która wydaje mi się bardzo ciekawa.
  • ps. scribefire, w najnowszej wersji, ssie strasznie (nie daję linka, bo nie zasłużyli). filiptepper i opi, który uratowali tą notkę, rządzą.
środa, 15 października 2008, reuptake

Dodaj komentarz »
TrackBack
TrackBack w tym blogu jest moderowany. TrackBack URL do wpisu:
Komentarze
webfocus
2008/10/15 14:40:43
punkt czwarty - niesamowicie trafne spostrzeżenie!
-
Gość: KPK, it.wp-sa.pl
2008/10/15 14:50:42
Ale mówisz o testowaniu PRZED uruchomieniem, tak? Tak czy inaczej wydaje mi się, że - przynajmniej w tym przypadku - problem przypomina węzeł gordyjski. Tak, trudno jest a priori przetestować optymalną dzienną liczbę wiadomości system- user w sieci społecznej. Tyle, że jeżeli cały system jeszcze nie działa, to jest co najmniej fyfnaście ważniejszych dylematów niż 20 vs 40 wiadomości, a oddelegowanie kompetencji użytkownikowi jest kwestią jednego dodatkowego inputa w profilu (i to w jakiejś sekcji "parametry drugorzędne"). Jeżeli natomiast system działa - nie jest szczególnym problemem udostępnienie wybranym użytkownikom do testów równoległej wersji interfejsu, przy zachowaniu wszystkich innych warstw systemu.

Być może przykład został niefortunnie dobrany, ale nie umiem wymyślić żadnej "społecznościowej" funkcjonalności, która nie podpadałaby pod jeden z tych dwóch przypadków: drugoplanowości (czyli: dostroi się po uruchomieniu) albo możliwości przetestowania przez równoległy prototyp. Chyba, że myślisz o funkcjonalnościach pierwszoplanowych, core'owych dla systemu - ale te, zdaje się, nigdzie nie dają się przetestować z góry i na tym właśnie polega biznes ;].
-
reuptake
2008/10/15 15:35:10
problemy w tym, ze nie możesz do końca udostępniać wybranym użytkownikom: musisz udostępniać wybranym grupom użytkowników. i to prawdziwym grupom, a nie losowej próbce.
-
Gość: KPK, it.wp-sa.pl
2008/10/15 15:44:38
No to trochę mechanika płynów się z tego robi. Jeżeli nie da się spośród tych grup wyodrębnić podgrup testowych i badać w zakresie relacji wewnątrz podgrupy - epic fail indeed.
-
reuptake
2008/10/15 15:46:24
oczywiście wystarczą dobre przybliżenia, nie musimy tu mieć superdokładności. tak tylko wskazuję, że testowanie systemu "społecznego" to trochę co innego niż testowanie obsługi koszyka z zakupami w sklepie netowym. może dla wielu osób to oczywiste, ale jakoś mało o tym słychać w prezentacjach.
-
mip
2008/10/15 20:58:55
A propos metafory szczęki na bazarze vs. marketing zapachowy, to polecam ten tekst:
www.rp.pl/artykul/61991,203186_Koniec_swiata_doroslych_dzieci.html

W skrócie: Benjamin Barber mówi w nim, że obecny krach gospodarczy spowodowany jest tym, że ekonomia opierała się na produkcji zapachów do marketingu zapachowego, a nie na produkcji rzeczy realizujących prawdziwe potrzeby "z dołu piramidy Maslowa".

Długofalowo bazary górą. Choć są odrażające.

-
rdrozd
2008/10/16 08:39:02
Kilka uwag na temat usability

1. Rzeczywiście symulacje są bez sensu. Zadania powinny być jak najbardziej naturalne. Nie możemy wymyślać zadań testowych, bo wyjdą nam wymyślone wyniki.

Ale w przypadku takiej aplikacji jak blip nie ma potrzeby "wymyślać" zadań i tworzyć sztucznego środowiska.

Jeśli user jest nowy - wtedy sprawdzamy podstawowe rzeczy jak zakładanie konta, logowanie, wysylanie pierwszej wiadomosci.
Jeśli jest stary - to działamy na jego istniejącym koncie i jego sieci.

Na pytanie "ile komunikatów powinien otrzymywać użytkownik, tak by był zadowolony" testy usability w swojej klasycznej w ogóle nie odpowiedzą, chyba że patrzymy userowi przez ramię w ciągu całego dnia. Jeśli nam bardzo na tym zależy (bo pytanie imho jest mało sensowne - user otrzymuje tyle na ile sobie ustawil i jaką ma sieć) to jest kwestia statystyk i badania satysfakcji. Zależność między satysfakcją a liczbą otrzymywanych powiadomień może jakaś będzie.

Swoją drogą, w blipie parę rzeczy pod względem usability jest mocno zwalonych i jeśli dotarliście do granic, to chyba z drugiej strony. :-) Na przykład obserwować ludzi mogę na kokpicie lub komunikatorze. Ale tagi muszę śledzić jednocześnie na jednym i drugim. Brak konsekwencji.

2. Zgadzam się jednak, że usability ma swoje granice i jest zresztą bardzo często mylone np. z rzeczami czysto marketingowymi. Np. sklep chce mieć "analizę użyteczności" a tak naprawdę chodzi mu przecież tylko o poprawienie sprzedaży i użyteczność jest tylko jednym z czynników.

W serwisach społecznościowych użyteczność nie ma tak wielkiego wpływu, dopóki ludzie nie mają wyboru - tzn nie mają drugiej takiej sieci. Blip w swojej niszy jest w PL jedyny, ale jak to zaczniecie wypuszczać normalsom, to przyjdzie mu się zmierzyć z pingerem i innymi możliwymi serwisami. Choć jeżeli zintegrujecie to z gadu, to nadal będzie przewaga która pozwoli pewne błędy użyteczności ignorować. :-)
-
Gość: ndemi, 91.197.12.1*
2008/10/16 09:03:58
Jeśli chodzi o blipa - o jakie dokładnie komunikaty chodzi?
-
reuptake
2008/10/16 09:40:32
to nie chodzi o jakiś konkret. chodzi o ogólne wrażenie, jakie mieliśmy przy jego tworzeniu. po prostu pewnych rzeczy nie potrafiliśmy przetestować, potrzebowaliśmy całej grupy połączonych osób.
-
rdrozd
2008/10/16 09:44:01
po to są wersje beta :) jasne ze bez jakiegos ruchu niektorych rzeczy nie sprawdzisz.
-
reuptake
2008/10/16 09:44:33
@rdrozd: a co do tego konkretnego przykładu: zgadza się, to jest niekonsekwencja. ale patrząc na to z drugiej strony i porównując z twitterem, z którym tak lubią wszyscy nas porównywać, twitter a) nie ma tagów; b) przestał obsługiwać komunikatory (natomiast zapewne pracuje nad nim 10-20x więcej osób). i problem z głowy :) czasem mamy dylemat czy wprowadzić funkcjonalność w prostszej formie, czy też nie wprowadzać wcale i zwykle wybieramy to pierwsze.
-
reuptake
2008/10/16 09:53:04
@rdrozd: tak, ale właśnie jest tu pewna róznica: taki sklep internetowy możesz w 99% sprawdzić pod względem usability sadzając przed nim poj. ludzi. a w serwisach społecznościowych musisz poczekać na wersję beta. właściwie jest to testowanie walką.

pewnie nie udało mi się tego przekazać we wpisie, tak czy owak: wydaje się mi, że sadzanie uzytkownika przed interfejsem sklepu z poleceniem: kup chleb i zapłać kartą to kompletnie co innego niż tuning aplikacji społecznej, w której w interakcję wchodzi wiele osób.
-
webfocus
2008/10/16 13:55:14
@reuptake: wydaje mi się, że problemem jest różnica poziomów abstrakcji. sklepy internetowe sa po to, zeby ludzie znalezli towar i go kupili. proste cele, więc łatwo sprawdzić jak dany system je realizuje. A o co chodzi w serwisach społecznościowych? informuj znajomych? bądź w kontakcie? rozwijaj swoją karierę? dużo bardziej abstrakcyjne pojęcia. to wszystko można robić bez tych serwisów. poza tym kazdy moze miec swoją wizję jak będzie z tego korzystał i przez ile czasu.

mam takie swoje porównanie: warzywniaki i knajpy. w warzywniaku jest ważny towar no i lokalizacja. chodzimy do najbliższego ważywniaka za rogiem, żeby coś kupić. towar musi być też akceptowalny. to wszytsko. tak jest z e-commerce, niektorymi uslugami itd. za to z knajpami jest już tak, że nie zawsze lubimy tą, która jest najbliżej. raczej wybieramy taką, która odpowiada nam klimatem, muzyką, do której chodzimy z naszymi znajomymi. dużo więcej jest tych czynników. dlatego trudniej prowadzić dobrą knajpę niż dobry sklep.
-
Gość: michal, 217.11.152.7*
2008/10/16 19:23:24
testować można mechanizm, procedurę, etc., natomiast w przypadku serwisów społecznościowych (i nie tylko), sądzę, że warto próbować także innych metod badawczych, np. etnografii - można wtedy uzyskać wgląd w rolę serwisu, sposoby wykorzystania, itd. w perspektywie różnych typów użytkowników. Nie daje to wprawdzie jednoznacznej odpowiedzi na pytanie "ile komunikatów", dostarcza jednak wiedzy, która może być pomocna, w samodzielnym planowaniu modyfikacji. mam za sobą dwa etnograficzne projekty wirtualne (przy czym dobra etnografia wirtualna przebiega tak naprawdę dwutorowo - w sieci i w "realu"): ludzie, którzy używają tych samych serwisów i robią pozornie to samo, mają różne pobudki i oczekiwania (webfocus trafnie mówi powyżej o różnych wizjach serwisu) - crowdtesting tego nie wychwyci (choć pod pewnymi względami na pewno może być użyteczny)
-
Gość: firem, na-10.bialnet.com.pl
2008/10/17 12:24:13
Dwa ostatnie linki w twoim wpisie pokazują, że testowanie wyłącznie za pomocą crowdtestingu jest niewystarczające. Po prostu oba URl-e prowadzą do SG blipa - jeśli jest niezalogowany. Dla tej grupki znajomych z blipa, permalinki do wpisów są pewnie jak najbardziej OK, ale dla kogoś z zewnątrz to tylko fałszywe odnośniki.
-
reuptake
2008/10/17 12:30:31
right, powinna być informacja, że jest to dostępne tylko do zalogowanych.
Dodaj komentarz »