|
Archiwum
Ostatnie notki
Zakładki:
Inne moje "rzeczy"
Inne "rzeczy"
Innych "rzeczy"
Książki
Możliwości i wzorce projektowe
Po godzinach
Rządzą... Gry
![]() ![]() MOJE KSIĄŻKI - AUTOR
REDAKTOR MERYTORYCZNY
|
niedziela, 08 listopada 2009
W ciągu ostatniego tygodnia miałem okazję zapoznać się z kilkoma wersjami czytników do ebooków, więc stwierdziłem, że swoimi obserwacjami się podzielę. Tym bardziej, iż wiele wskazuje, że w najbliższym czasie w tym sektorze dużo się będzie działo (również interfejsowo, bo - jak będzie można wywnioskować po lekturze tego wpisu - jesteśmy jeszcze na początku drogi). Wystarczy, że dodam, iż na 13-stych Targach Książki, na których w sobotę byliśmy z żoną, znajdowały się 4 stoiska, na których prezentowano produkty bądź usługi związane z tym sektorem. Ale do rzeczy... Testowałem:
Rysunek 1. Powyżej czytniki ebooków (od lewej): Kindle, eClicto, Sony, Cool-er, Nook. Rys. za: passwordincorrect.com.
Ogólne obserwacje jakie mam to:
eClicto W zasadzie na tym chciałbym poprzestać w tym wpisie. Udało mi sie otrzymać jeden egzemplarz tego czytnika (dzięki Tomasz za wypożyczenie!) i jemu poświęcę osobny wpis.
Rysunek 2. Czytnik eClicto firmy Kolporter Info S.A. (od lewej): z wyświetloną książką oraz ze zrzutem strony nakanapie.pl.
środa, 04 listopada 2009
Już niektórzy z Czytelników bloga UI Design wiedzą (mówią mi, że wiedzą) nt. prac, które prowadzimy teraz w serwisie nakanapie.pl. Niedawno pisał też o tym Artur Kurasiński i kilka szczegółów tychże prac zdradziłem; kolejne czekają na swój czas (tj. launch). Dzisiaj zamiast wpisu - obrazek. Obrazek szczególny, pokazujący wykres rejestracji w ramach serwisu nakanapie.pl. Bez kampanii, bez kasy, samymi zmianami w AI. Dla nas obrazek wymowny, bo pokazujący, że ma sens to co robimy i to całe - za przeproszeniem - usability ;) Na razie bez liczb jeszcze - przyjdzie pora i na nie.
niedziela, 04 października 2009
Jakiś czas temu Grzegorz Miłkowski, przy okazji prac nad raportem interaktywnie.com nt. użyteczności, poprosił mnie o kilka wypowiedzi. W raporcie znalazło się co prawda kilka z nich, aczkolwiek Grzegorz swoimi pytaniami poruszył kilka kwestii, które są dość interesujące, a o których na blogu jeszcze nie pisałem (i pewnie w innej sytuacji bym nie napisał). Stąd postanowiłem – za zgodą Grześka – zamieścić cały tekst na blogu.
*** GM: Czy użyteczność musi stać w opozycji do rozwiniętej interakcji? Zdarza się, że aby niejako zmusić użytkownika do pożądanych przez nas czynności na stronie www, należy zrezygnować z części użyteczności, utrudniając mu życia. Czy jest możliwość pogodzenia tych sprzecznych potrzeb? MK: Termin 'użyteczne', nie jest tylko cechą stron łatwych w obsłudze, wtedy zapewne dużo lepszym terminem byłby 'używalne'; użyteczne, to także potrzebne i przydatne (a nie wszystkie przydatne narzędzia są łatwe w obsłudze i odwrotnie – nie wszystkie łatwe w obsłudze narzędzia są przydatne). Czasem efekt końcowy wymaga zastosowania pewnych właściwości (funkcjonalności, sposobu rozwiązania nawigacji), które zdają się „utrudniać” posługiwanie się aplikacją, ale za cenę zwiększenia na przykład bogactwa płynącego z doświadczenia interakcji. Nie zawsze pożądaną cechą systemu jest łatwość jego obsługi – a przynajmniej nie pierwszoplanową. Jednak aplikacja dalej może być potrzebna i przydatna, a w tym sensie i użyteczna. Klasyczne pojmowanie użyteczności już się skończyło bądź, gdy chcieć je stosować, jest mocno ograniczone. Głównym ograniczeniem może być fakt prób wyjścia poza standardowe składowe interakcji oraz standardowe interfejsy oparte o myszkę i klawiaturę po stronie użytkownika oraz elementy klikalne po stronie medium. „Gonitwa” za zwiększeniem doświadczeń użytkowników z marką (user experience) wymusza na projektantach rozwiązania niestandardowe, jeszcze kilka lat temu nie funkcjonujące w świecie interakcji internetowej. By nie poruszać się tylko w sferze teorii – mój ulubiony przykład: jeśli zależy mi na tym, by użytkownicy przychodzący na stronę WWW odczuli pozytywne cechy marki – np. gazowanego napoju orzeźwiającego – zamiast klasycznego kliku powodującego wejście na stronę, mogę zastosować interfejs oparty o kamerę internetową (dostępną już w prawie każdym modelu laptopa) oraz system rozpoznawania mimiki twarzy. Uśmiech osoby siedzącej przed ekranem komputera może być tym samym, czym do niedawna było kliknięcie w przycisk WEJŚCIE (bądź SKIP INTRO). Użyteczność, jako łatwość obsługi stron, też nie zawsze jest główną cechą jaką chcemy uzyskać w ramach klasycznych stron WWW. Na przykład coraz większa ilość użytkowników skarży się, że jednym z utrudnień dla korzystania ze stron, jest system zakładania na nich kont i konieczność logowania. Gdzieś niedawno czytałem wyniki badań, które wskazywały, że jest to bodajże druga cecha klasyfikowana przez respondentów biorących udział w badaniu, utrudniająca im korzystanie z zasobów. Ale z drugiej strony mamy serwisy internetowe, które niejako w strategię mają wpisane tworzenie kont użytkowników – i co wtedy? Poza tym, rejestracja w serwisach wywołuje pewne cechy u użytkowników, które z punktu widzenia marki mogą być istotne – jak np. poczucie elitarności i przynależności do pewnej grupy. Stąd nie zawsze jest tak prosto stwierdzić, który z aspektów użyteczności należy wybrać przy danym projekcie. Krótko mówiąc – poszerza się sfera możliwości interakcji (np. dzieki interfejsom dotykowym czy wykorzystaniu kamery internetowej), stąd i użyteczność jako dyscyplina również ewoluuje.
GM: Z jakimi tarciami na linii specjalista od usability / projektant najczęściej można się spotkać? Które elementy serwisu są najczęściej punktem spornym? MK: Nie wiem. Jestem projektantem, wykorzystującym w swej pracy m.in. wiedzę z zakresu usability. Nie czuję wewnętrznego konfliktu ;)
GM: Czy można wyróżnić elementy, które wpływają na użyteczność i jednocześnie się różnią w zależności od tego, jaką funkcję ma pełnić serwis, np. strona korporacyjna, sklep itp. Na jakie najważniejsze różnice należy zwrócić uwagę w takim przypadku? Oczywiście bezdyskusyjne jest to, że są to zupełnie różne kreacje, jednakże być może są jakieś elementy, które nie odgrywają ważnej roli w jednym przypadku, a w drugim warunkują powodzenia? MK: Jedno wiem na pewno i staram się o tym mówić tam, gdzie mogę. Tak jak alchemikom nie udało się znaleźć kamienia filozoficznego – bo go nie ma – tak nie ma złotych reguł z zakresu użyteczności zapewniających sukces serwisom. Mało tego, sam często powtarzam, że czasem, dla dobra sprawy, należy niektóre sprawy skomplikować – jak mawiał Einstein: „rzeczy powinny być tak proste jak to możliwe, ale nie prostsze”. Strony internetowe są tylko środkami to uzyskania pewnych celów klienta – w żadnej mierze nie są celami samymi w sobie. Podam przykład: Ostatnio na jednej z konferencji wywołałem oburzenie części ekspertów (których osobiście szanuję), że są przypadki, gdy nie należy doprowadzać proces wypełniania formularza do zbytniego uproszczenia. Że trudność w kwestii wypełnienia formularza, na przykład wymuszenie podania jakieś danej, której normalnie użytkownicy nie posiadają przy sobie, a tylko klienci faktycznie zainteresowani danym produktem bądź usługą, ma tę pozytywną cechę, że już na starcie pozwala nam wyselekcjonować tylko te osoby, które faktycznie są zainteresowane produktem/usługą. W innym wypadku, gdy formularz będzie prosty w wypełnieniu, w tym sensie, że będzie mógł go wypełnić każdy, narażamy firmę – naszego klienta – na dodatkowe koszta wynikające ze zwiększenia ilości obsługi przy odpowiadaniu na zapytania ofertowe, przy jednoczesnym spadku procentowej ilości transakcji. W ten sposób, widząc tylko krótkowzroczny cel naszej pracy – umożliwienie użytkownikom łatwego wypełniania formularzy – czasem łatwiej wyrządzić krzywdę klientowi, przy jednoczesnej radości z tego, że nasze działania zwiększyły konwersję.
GM: Często można spotkać się z zarzutami, że serwisom flashowym nie po drodze z usability. Gdzie więc tkwi klucz do użyteczności takich stron? MK: Trudno tak jednoznacznie stwierdzić, że Flash jest be, a HTML jest cacy. W 2000 roku Jakob Nielsen napisał swój głośny artykuł "Flash: 99% Bad". Zaraz potem firma Macromedia zatrudniała go w roli eksperta mającego za zadanie przyczynić się do zwiększenia użyteczności tej technologii. Dwa lata później wyszła książka o przewrotnym tytule "Flash 99% Good. A Guide to Macromedia Flash Usability", autorstwa Kevina Airgida i Stephenie Reindel. W tym samy roku ukazała się blisko 500-stronicowa "The Flash Usability Guide. Interacting with Flash MX", którą napisało aż sześciu ekspertów. To pokazuje jak firma – jeszcze wtedy Macromedia – zaczęła szybko działać w kwestii podwyższenia użyteczności swoich produktów, a z drugiej strony jak dużo czasu upłynęło, a mit nieużytecznego Flash wciąż się utrzymuje. Z tego co wiem, to w narzędziach programów do obróbki Flash znajdują się opcje związane z użytecznością, czy raczej dostępnością (nie używam tej aplikacji, więc trudno mi to potwierdzić). Nie wszyscy jednak je wykorzystują. Chociaż, nie powiem, brak obsługi kliknięcia z prawego przycisku w przypadku technologii Flash bywa uciążliwy... przynajmniej dla mnie.
GM: Czy można wymienić jakieś elementy, które świetnie sprawdzają się w serwisach html-owych, natomiast we flashowych stanowią ich przysłowiowy gwóźdź do trumny. I na odwrót, flashowe rozwiązania dotyczące użyteczności, które nie pasują do zwykłych serwisów? MK: Nie wiem. Mam wrażenie, że jeśli nawet, to dzięki coraz ciekawszym zastosowaniom technologii AJAX przy jednocześnie powiększającej się ilości dostępnych gotowych skryptów, ta przepaść się zmniejsza.
GM: Czy jest w ogóle sens badać serwisy flashowe pod kątem usability? MK: Tak. Łatwość obsługi stron nie jest w żaden sposób zależna od użytej technologii. Tak samo jak badamy pod kątem usability również obsługę pilotów do TV. Użyteczność nie jest tylko zarezerwowana dla stron WWW, czy dla stron WWW wykonanych w HTML-u.
GM: Naukowcy z Research Center Xeroxa w Palo Alto Stuart Card, Ed Chi i Peter Pirolli badając na początku lat 90-tych zachowania ludzi szukających informacji w Internecie stwierdzili, że ich postępowanie podobne jest do polowania zwierząt. Jednym słowem, podążają za tropem, który wydaje im się silny oraz jednocześnie budujący nadzieję na obfity łup. Jak więc powinna wyglądać dobrze zbudowana ścieżka (trop), która doprowadzi użytkownika do pożądanego przez nas miejsca w serwisie WWW? MK: Nie ma złotych reguł, jak wspominałem już powyżej. Ale… dobra ścieżka to: 1) możliwość szybkiej identyfikacji przez użytkownika, że element, który widzi jest tym, który szuka (na przykład dobrze dopasowane słowo – szybsze są czasy reakcji osób aplikujących do jakieś firmy, gdy w ramach łącza prowadzącego do informacji z działu personalnego widzą słowo ‘Praca’, niż ‘Twoja kariera’); 2) łatwa w obsłudze ścieżka dotarcia do finalizacji ścieżki – widoczne i dobrze opisane elementy tworzące łańcuch kliknięć, pozwalające w miarę szybkim czasie dotrzeć do realizacji danego scenariusza użycia; czasem też w takich przypadkach, gdy na przykład naszym flow jest zestaw formularzy (wizard), możliwość umieszczenia opcji „Pomiń”, pozwalającej skrócić pewne kroki. Generalnie, sieć wywołuje wśród użytkowników jakiś rodzaj zniecierpliwienia i gonitwy. Dużo trudniej jest im się skupić przez dłuższy czas na jakimś elemencie treści, zaś dużo częściej oddają się klikaniu, jako czynności mającej ich przybliżyć do czegoś bardziej ciekawego niż to, co widza w danej chwili. Ta gonitwa kliknięć ku ‘jeszcze fajniejszym rzeczom’, ku ‘nowym odkryciom’, staje się coraz powszechniejsza. W sieci zamieniamy się w myśliwego i szukamy coraz atrakcyjniejszej zdobyczy. Natomiast z czasem, coraz trudniej zaspokoić nasz apetyt. Jak w czasach studiów mawiał mój profesor od estetyki – gdy człowiek nauczy się pić drogie wina, nagle przestają mu smakować tanie, którymi jeszcze do niedawna się delektował.
GM: Czy można rozróżnić jakieś elementy, które będą bardziej użyteczne dla jednych grup wiekowych, a mniej dla innych? Tj. czy można pokusić się o stwierdzenie, że serwisy przeznaczone np. dla starszych internautów powinny być nieco inaczej zbudowane pod kątem usability? MK: Tak. Od wieku grupy docelowej zależą na przykład takie elementy jak: wielkość dobranego fontu, kolorystyka (poziom kontrastu), w tym kolorystyka łącz (widzenie koloru niebieskiego z wiekiem jest coraz gorsze, stąd stosowanie niebieskich łączy przy jednoczesnym stosowaniu opcji ukrywania ich podkreślenia, może spowodować, że starsi użytkownicy nie będą mogli w prosty sposób zidentyfikować co jest donośnikiem, a co tekstem zasadniczym); w końcu też wielkość elementów klikalnych.
GM: Czy o podobnym rozróżnieniu można mówić w przypadku podziału na płeć? Czy mężczyźni oczekują innych - zapewniających funkcjonalność - elementów niż kobiety? Czy może na tej płaszczyźnie mamy do czynienia z równouprawnieniem i w przypadku obydwu płci sprawdzają się podobne rozwiązania dotyczące użyteczności? MK: Nie znam żadnych sensownych i zarazem wiarygodnych badań w zakresie różnic w płci co do oczekiwań funkcjonalnych, czy użytecznościowych.
GM: Budując serwis na jego wygląd duży wpływ chcą mieć marketerzy. Jakie elementy najczęściej chcą oni wdrażać i zmieniać? MK: Czerwone przyciski z wielkim napisem KUP :) Tak, marketerzy uwielbiają myśleć, że czerwony sprzedaje i pragną myśleć, że umieszczenie jak największej ilości dużych czerwonych przycisków z napisami Kup, Kup, Kup, przyczyni się do zwiększenia konwersji. Oczywiście kolor czerwony faktycznie powoduje zwiększenie uwagi na te elementy, ale jest to zwykła reakcja mająca podstawy psychofizjologiczne i nie przekładająca się w żaden sposób na zwiększenie sprzedaży. Po prostu w świecie przyrody kolor czerwony jest nośnikiem informacji na temat potencjalnego zagrożenia, stąd niektóre zwierzęta wykorzystują go także na zasadzie mimikry, a w ramach budowy interfejsu uzasadnione jest wykorzystywanie go wszędzie tam, gdzie mamy do czynienia z zawodnością systemu, jak np. komunikatach o błędach. Ale niektórzy są bardzo przywiązani do swoich przekonań. :)
GM: Jakie pomysły marketerów są nie do przyjęcia z punktu widzenia usability? MK: Nie spotkałem jeszcze takiego marketera :) Na razie wszystkie były do przyjęcia.
niedziela, 27 września 2009
Dawno nie pisałem... na blogu. Co zrobić, gdy chwilę czasu ma się tylko przy okazji choroby. Jako że morzy mnie gorączka, nadarza się okazja by spisać kilka przemyśleń. *** 1. Projektowanie to przede wszystkim myślenie - definiowanie problemów projektowych i ich rozwiązywanie. Rysowanie makiet i AI to sprawa wtórna w stosunku do "zobaczenia" (zdefiniowania) problemu i jego rozwiązania (koncepcji). Poza tym, czasem dany problem miewa kilka rozwiązań - jedne są lepsze, drugie gorsze. W dodatku bywa też i tak, że jedne rozwiązania są lepsze dla użytkowników, inne są lepsze dla wydawcy serwisu. Ostateczne rozwiązanie może okazać się nie trywialne. 2. Weźmy dla przykładu taką funkcję: "Wyrażanie opinii". Funkcja wyrażania opinii jest funkcją ogólną, tj. podpadają pod nią różne funkcje szczegółowe jak chociażby:
3. Każdy z tych systemów opiniowania ma swoje konsekwencje - zarówno dla łatwości wykonywania czynności wyrażania opinii przez użytkowników (czyli tego, co określam mianem używalności), jak i dla wydawcy serwisu. 4. Każdy z nich to konkretna decyzja projektowa. Niby wszystkie z powyższych systemów opiniowania służą temu samemu - wyrażaniu opinii - jednak jedne rozwiązują pewne klasy problemów projektowych, inne nie. 5. Weźmy dla przykładu system wyrażania opinii przez komentarze. System ten jest najlepszy z powyższych, gdy celem, który przed nami stoi, jest zbieranie wartościowego contentu, bądź gdy potrzebujemy informacji od użytkowników natury jakościowej. Przeciwieństwem do niego będzie ilościowy system 'łapkowy'. Prosty w użyciu, lecz nie dający wiedzy merytorycznej, czasem niezbędnej innym użytkownikom. System bazujący na komentarzach ma jednak pewne swoje daleko idące konsekwencje. Projektant musi zdecydować o tym czy:
6. Odmiennym, od powyższych systemów komentowania i 'łapkowania', jest system gwiazdkowy, umożliwiający oddawanie głosów w ramach pewnej przyjętej wcześniej skali - powiedzmy od jeden do pięciu. W sensie wizualnym (a więc i na AI) może to być klasycznych system gwiazdek, bądź slider, czyli interfejs analogowy z suwakiem przypominającym te z equalizera. Ale... przyjęcie dwu różnych form wizualizacji wyników ma także swoje konsekwencje.
Użytkownik odczytujący opinie w przypadku wizualizacji gwiazdek sposobem drugim ma więcej informacji nt. faktycznej wartości produktu ocenianego, niż w przypadku pierwszym. Gdyż może się zdarzyć, że średnia 3 bierze się raz z faktu, że wiele głosów na 5 zostało raz zaniżonych prze ocenę na 1, a innym razem, że produkt jest po prostu przez większość oceniany na 3, z małymi odchyleniami między 2 i 4. Informacyjnie to dwa różne przypadki. 7. Wybór czasem też nie jest prosty. Musi godzić interesy użytkowników (w tym kwestie prostoty wykorzystania) z interesami wydawcy. W sensie prostoty (tak ostatnimi czasy przecenianej przez osoby związane z tworzeniem aplikacji WWW i nadużywanej) najlepszym wyborem zapewne byłby system 'łapkowy'. Ale znowuż powstaje problem, gdyż w ramach interesów wydawcy może być gromadzenie unikalnych treści - wówczas lepszą odpowiedzią na zapotrzebowanie klienta będzie system dodawania komentarzy. 8. Dla komplikacji zadania, zawsze można jeszcze stworzyć systemy hybrydowe. Czyli takie, na które składają się elementy bądź nawet połączenia różnych rozwiązań.
Reasumując: definiuj problemy projektowe i - przywołując Einsteina - "Twórz rozwiązania tak proste jak to możliwe, ale nie prostsze." I myśl... o konsekwencjach swoich projektów. I rzecz na koniec, gdyż przeraża mnie już trochę narzędziowe podejście do projektowania: w projektowaniu to nie rysowanie jest najważniejsze. Jak mawia moja żona: dwie osoby o różnym poziomie talentu, wyposażone w płótno i farby (więc te same narzędzia), stworzą obrazy o zupełnie różnej wartości artystycznej. Chociaż ważne jest jak to, co zaprojektujesz, ostatecznie dla użytkownika będzie wyglądało, to definiowanie i rozwiązywanie problemów projektowych jest kwintesencją projektowania jako takiego. Jak, na przykład, kwestii stworzenia mechanizmów zwiększających ilość odsłon w serwisie Twojego klienta (problem projektowy) i to tak, by użytkownicy czuli się usatysfakcjonowani wprowadzonymi rozwiązaniami (jedna z wytycznych).
Rysunek 1. Projekt koncepcyjny blisko 10-ciu rozwiązań odsłonowych może zmieścić się na kartce z notesu biurkowego. Wybór tych, które ostatecznie zostaną wdrożone, to ciężkie zadanie i musisz pamiętać, że każde z nich może rodzić różne konsekwencje.
wtorek, 18 sierpnia 2009
Właśnie jestem w trakcie lektury "Serwisy społecznościowe. Projektowanie" autorstwa Portera; niedawno też przerobiłem "Neuro Web Design" Susan Weinschenk (o tej książce pisał też ostatnio Maciej). Ani jedna, ani druga lektura nie zrobiły (robią, gdyż Serwisy społecznościowe jeszcze czytam) większego wrażenia. Powody są dwa: 1) na studiach wpajano mi podstawy socjotechniki, w tym badania Stanleya Milgrama oraz 2) lektura książki Cialdiniego "Wywieranie wpływu na ludzi" była podstawowym podręcznikiem do tych zajęć, a w obu książkach - i Portera i Weinschenk - sporo odwołań do Cialdiniego. (Na marginesie: ostatnio uzupełniam listę książek z zakresu UCD, które posiadam, więc zainteresowanych odsyłam do mojej kolekcji). ALE... projektowanie na potrzeby Internetu wymaga by pamiętać o podstawowym czynniku komunikacji: Człowiek to nie tylko zwierzę (ze swoim bagażem psychofizjologicznym), ale i zwierzę społeczne! Co z tego wynika dla Weba? Zobaczmy.
"Tylu tu ich jest - musi być fajnie" Taki efekt mają przynieść wlepki na blogi, na których widnieją portrety osób, które bądź to mają założone konto w danym serwisie, bądź też - jak w przypadku My BlogLog - odwiedzają jeden z blogów, którego autor zrzeszony jest w tym samym systemie agregacji informacji, co i jego czytelnicy. Przypomina mi się tutaj jedna z rozmów, tocząca się bodajże na Flakerze, gdy ktoś komentujący Świstak.pl zarzucił Rafałowi Agnieszczakowi, że na stronie głównej widnieje boks "Zobacz kto do nas ostatnio dołączył" ze zdjęciami świeżo upieczonych użytkowników. Rafał - komentując po swojemu - słusznie zauważył, że statystyki Z boksem i BEZ boksu mówią same za siebie, czy boks jest wart cennej przestrzeni strony głównej.
Rysunek 1. U góry fragment strony głównej serwisu aukcyjnego Świstak.pl oraz - na dole - wlepka z systemu MyBlogLog pokazująca czytelników strony oraz - co jest istotą tego przykładu - z linkiem "Join My Community" jako akcją domyślną.
Jak to działa? Ano trochę tak, jak w jednym z eksperymentów Milgrama (na spółę z Bickmanem i Berkowitzem) w ramach którego grupa osób stojących na ulicy wpatrywała się w okna szóstego piętra budynku, przy którym stali. Zauważano, że przechodnie przechodzący obok "gapiów", w ramach społecznego bodźca także zaczęli spoglądać w owe wypatrywane miejsce, w oczekiwaniu, że dojrzą tam coś interesującego - coś, w co wpatrują się INNI. Przy czym - i to jest interesujące - czym owych INNYCH wpatrujących się było więcej, tym - stwierdzono - bodziec pobudzał większą część przypadkowych przechodniów. Jaki z tego wniosek? Ano chociażby taki, że pokazywanie w serwisach INNYCH - na fotkach, w blokach "Ostatnio tu byli", "Ostatnio zalogowani", "Nowi zarejestrowani..." etc. - sprzyja procesowi rejestracji, włączenia się do społeczności. I to jest patent numer 1.
"Skoro ON tego używa, to musi być fajne" Patent numer dwa w pewnym sensie związany jest z pierwszym, acz bazuje na sile autorytetu, a nie na sile ilości (masy). Zobaczmy jak to działa. Case polskich mikroblogów: "bitwa" systemów mikroblogingowych odbywa się przy pomocy celebrites. Kominek dołączając do Blipa przyprowadził ze sobą rzeszę swoich wiernych. Grzesiek pisząc na swoim AntyWebie achy i ochy pod adresem Flakera - a miało to miejsce jeszcze w pierwszych m-cach funkcjonowania serwisu - przyczynił się z pewnością do zwiększenia w tym czasie ilości nowych użytkowników, w tym rejestracji. Adam wręcz otwarcie mówi, że bitwę wygra ten, kto posiądzie Dodę (nie w dosłownym znaczeniu :). Stąd zresztą chwilę później Blip zaczął się chwalić pozyskaną Frytką. Case Adtaily: przebiegał trochę inaczej, acz ważną rolę odegrał tu Maciej Budzich, na którego blogu chyba jako pierwszym zaczęły pojawiać się reklamy z systemu AdTaily oraz informacje 'z czym to się je'.
Rysunek 2. Kominek używa Blip.pl, a Ty? A Flakera używa prawie-Doda. Kiedy czas na tą prawdziwą?
Społeczna siła autorytetu (również anty-autorytetu czy po prostu oszołomstwa) istotna jest z punktu widzenia projektowania do Internetu. Łącząc patent nr 1 z patentem nr 2 otrzymujemy mieszankę wybuchową, gdyż nagle się okazuje, że czytelnikami bloga X są same znane osobistości. Przekaz tego komunikatu dla osób postronnych jest tak silny, że - chcąc nie chcąc - blog taki szybko ląduje w zaskrybowanych kanałach RSS. Pisze też o tym Porter podając przykład używania internetowej aplikacji przez Setha Godin, autora m.in. znanej u nas "Fioletowej krowy" i skrzętnego wykorzystania tego faktu przez ludzi z marketingu w celu zwiększenia ilości rejestracji przez odwołanie się do faktu posiadania tak zacnego użytkownika.
Podsumowania czas Istnieją pewne wariacje, a czasem i zagrożenia w stosowaniu powyższych technik. Na przykład:
*** Era społecznego zaangażowania moim zdaniem dopiero się rozpoczyna. I nie mówię tu o serwisach społecznościowych, a o projektowaniu społecznościowym. Mechanizmy, które mamy - opisane powyżej, ale także te z e-commerce: "klienci, którzy kupili, kupili także", "ten produkt ma tyle i tyle opinii pozytywnych" - to dopiero początek wykorzystania społecznego zaangażowania. Stosowanie wlepek z Facebook w sklepach, pokazujących ile mamy fanów, które wśród odwiedzających zwiększają poziom zaufania do oferty. Funkcjonalności w stylu FlakTesty, które realnie podwyższają sprzedaż. To kolejne kroki. W dobie aplikacji społecznych nawet blogi tracą już swój pierwotny sens - w aktualnej formule nie są w stanie agregować wszystkich moich aktywności sieciowych. A w przeważającej części - IMHO - ludzie nie czytają blogów - czytają INNYCH. Warto przeczytać także: Maciej Lipiec, Większość nie może się mylić.
I zupełnie na koniec - osobiście uważam, że aktualnie najlepsze patenty społecznościowe funkcjonujące w obrębie polskiego internetu ma... (i te trzy kropki będą z pewnością najlepiej klikalnym linkiem tego wpisu :). Chociaż - dodam łyżkę dziekgciu - system ten jest za trudny w użyciu dla przeciętnego użytkownika, co dobrze by było, by jego Autorzy zdali sobie jak najszybciej z tego sprawę.
wtorek, 07 lipca 2009
1. Nie cierpię tzw. audytów użyteczności i raportów, które w wyniku nich powstają. Takich klasycznych mówiących, że logo ma być u góry po lewej, musi być tagline, bo inaczej -5 do końcowej oceny, a stopka krótka (kto to wymyślił? Znam przynajmniej kilka powodów dla których warto rozbudować stopkę). Są przeważnie długie - autor piszący raport chce w ten sposób wykazać, ile pracy włożył i za co ostatecznie bierze wynagrodzenie - nudne i w przeważającej części oderwane od faktycznych problemów z serwisem. Miałem okazję już trochę czytać raportów powstałych tu i ówdzie, biorących pod uwagę tzw. heurystyki Nielsena, które są albo przestarzałe, albo bez znaczenia dla użytkowników i ich scenariuszy użycia różnych stron; nie wspominając, że nie rzadko nie mają wiele wspólnego z celami biznesowymi klienta oraz strategią. 2. Odświeżyłem sobie niedawno lekturę "Szybcy i mądrzy" Marka Breiera i chociaż spora część książki wywołuje już uśmiech na twarzy ('managerowie, używajcie poczty e-mail, to oręż, dzięki któremu wygracie nie jeden bój' :), to w swym przesłaniu, sposobie działania, który wniósł Jeff Bezos, książka jest wybitnie aktualna. Bądź szybki! Reaguj i wprowadzaj innowacje szybciej, niż Twoja konkurencja - inaczej przegrasz. 3. Miałem okazję uczestniczyć w ostatnim 1,5 m-ca czasu w licznych spotkaniach - zarówno jako prelegent (ClearWeb, w Realu, @rewolucja biznesu, warsztaty z usability dla Informedia), jak i słuchacz (Aula Polska). Wspominam o tym nie bez kozery, gdyż główne dwie myśli, które przy okazji spotkań starałem się przekazać, to ROZWIĄZUJCIE FAKTYCZNE PROBLEMY oraz TESTUJCIE (Always be Testing)... na żywym organizmie. Świetnie w tą ideę wpisywało się wystąpienie Witolda Ferenc z frisco.pl na Auli, który na spotkaniu opowiadał o spontanicznym (chociaż przemyślanym) wprowadzaniu do sklepu funkcjonalności i innowacji. Szybcy i Mądrzy! 4. Użyteczność ekstremalna, to szybkie rozwiązywanie problemów natury funkcjonalnej. Definiowanie problemów i szukanie rozwiązań - najlepsze rozwiązania powstają na styku użytkowania, w wyniku wdrożenia i interakcji z użytkownikami. Użyteczność ekstremalna (podobnie jak programowanie ekstremalne) to wyznaczanie sobie celów, definiowanie podzadań i ich rozwiązywanie. Myślenie w ramach definiowania problemów i szukania dla nich rozwiązań. Zero heurystyk Nielsena. Zero nastawienia na gotowe rozwiązania (NIE - chcę sklep internetowy, tylko - chcę sprzedawać w Internecie; NIE - chcę badanie eyetrackingowe, tylko szukam odpowiedzi, czy slogan reklamowy zostanie zauważony, jakiego rodzaju badanie możecie zaproponować?; w końcu NIE - robimy redesign strony, może byś nam pomógł, ALE - mamy sygnały od użytkowników, że jest taki problem na stronie, poza tym chcemy wstawić tam nową ofertę i dział - uważamy, że w aktualnej wersji strony to będzie trudne, co radzicie?). Jak przekonywałem na prezentacjach - w wielu przypadkach to nie redesing jest potrzebny serwisom, tylko przemyślane funkcjonalności. Rozwiązania potrafią być gdzie indziej, niż wzrok osób prowadzących projekt. 5. W użyteczności ekstremalnej, gdy liczy się czas i gdy testuje się na żywym organizmie, trzeba niekiedy przerzucić kwestię badań PRZED, na badania PO wdrożeniu. W tej wersji liczą się obserwacje i szybka reakcja zespołu tworzącego. Użyteczność ekstremalna świetnie nadaje się przy tworzeniu serwisów wymagających krótkiego czasu realizacji od załogi i szybkiego wdrożenia. Nadaje się też tam, gdzie liczba zmian jest duża i przez to odczuwalna dla użytkownika (case strony głównej Allegro, zresztą - na pohybel krytykom - świetnie zrealizowany przez zespół projektowy tej firmy). Użyteczność ekstremalna to także najlepsza metoda dla firm, które tworzą swoje wewnętrzne działy od użyteczności - dodatkowo walczą z konkurencją, bądź w szybkim czasie chcą pozyskać część rynku. Muszą być szybcy. Muszą umieć ryzykować. Trudno sobie wtedy pozwolić na długie iteracje w fazie tylko projektowej. 6. Mój ogląd z zakresu projektowania nie rzadko różni się od tych powszechnie spotykanych. Większość tego co wiem, to nie książki (chociaż przeczytałem ich trochę, a sama część mojej biblioteczki z HCI to blisko 0,5 tys. tytułów), tylko testy i badania. Większość badań i testów, które przeprowadziłem, to te na żywym organizmie. Nie słuchaj co użytkownicy mówią (a przynajmniej nie zawsze) - patrz co robią! Wprowadzaj poprawki, uaktualnienia, czasem coś "zepsuj" - i obserwuj co robią użytkownicy, a uzyskasz wiedzę czy faktycznie zepsułeś. Ale przede wszystkim myśl problemami, a nie gotowymi przepisami. Szybko i mądrze.
piątek, 19 czerwca 2009
Ten wpis nie będzie o interfejsach, ani o projektowaniu do Weba. Chociaż źródłem jego powstania jest refleksja nad pewnym projektowym przypadkiem oraz osobistym podejściem do sztuki projektowania jako takiej. Zawsze lubiłem pisanie, a w liceum prócz pisania (i pierwszej wydanej książeczki - tomiku wierszy), zajmowałem się sztuką filmową. Chociaż różne to tak dyscypliny, u ich podstaw leży jednak ten sam element - uczestniczenie w procesie twórczym (czemu notabene miałem poświęcić swoją pracę doktorską).
Po nitce do kłębka Element twórczości jest dla mnie - jako dla projektanta - bardzo istotny przy tworzeniu rozwiązań dla klientów. Stąd w panelach dyskusyjnych raczej opieram się tezie, że w użyteczności należy kopiować wzorce, a hołduję tezie - że jeśli chodzi o TŁO, to tak, ale elementy wyróżniające się powinny tworzyć przewagę nad konkurencją, w związku z tym - niejako z definicji - konieczne by były nowatorskie (pisałem o tym w swoim czasie na GL). Dlatego też głównym motorem mojej pracy jest Features Definition, czyli definiowanie funkcjonalności, z nastawieniem na zdefiniowanie tej kluczowej - z jednej strony mającej za zadanie rozwiązać problem zdefiniowany wcześniej w procesie projektowym, a z drugiej stanowić o elemencie wyróżniającym mojego klienta na tle konkurencji. Najlepszą nagrodą wtedy dla mnie - ale jak obserwuję również dla moich klientów - jest dzień, w którym obserwuję, że konkurencja skopiowała moją funkcjonalność, zwłaszcza gdy dzieje się to na poziomie Wielkich Konkurentów.
Case study nie wprost Wątek filmowy wprowadziłem we wstępie nie bez kozery. Oto ogólny zarys scenariusza, który od lat mi chodzi po głowie: Starszy już wiekiem pisarz, uznany w środowisku krytyków, z licznymi nagrodami na koncie, sprzedającymi się na pniu książkami, cierpi na najgorszą dolegliwość - wypalenie. Rozgłos kilku ostatnich jego dzieł zawdzięcza bardziej swojemu asystentowi, u którego odkrył talent pisarski - ale o tym wiedzą tylko oni dwaj... Historia mało oryginalna (choć efekt filmu opiera się w głównej mierze nie na tym CO opowiadamy, a JAK). Ale temat dość uniwersalny i stanowi dobrą ilustrację tego, co spotyka nas na co dzień. Nie będę tutaj streszczał całego scenariusza, bo nie czas i miejsce na to, ale w kontekście projektowania zastanawiający jest wątek "twórczego cienia" - w wątku przedstawionym powyżej, to asystent, który pisze dzieła, pod którymi - ze względu na swoją rozpoznawalność - podpisuje się wielbiony przez tłum czytelników Autor. Dla drugie to "być albo nie być"; dla pierwszego to dysonans w swojej czystej postaci: z jednej strony radość, że tak naprawdę to czytają mnie, z drugiej, że nikt nie wie, kto za tym stoi...
Wpis dedykuję tej skopiowanej funkcjonalności (dobrze skopiowanej). |