Zobacz mnie na GoldenLine
ThinkLab: moja firma

MOJE KSIĄŻKI - AUTOR

Użyteczność w praktyceM. Kasperski, A. Boguska-Torbicz Projektowanie stron WWW. Użyteczność w praktyce, Helion 2008.

Moja książkaM. Kasperski, Sztuczna Inteligencja, Helion 2003.

REDAKTOR MERYTORYCZNY

UmysłD. Casacuberta, Umysł. Czym jest i jak działa, Świat Książki 2007.

100 sposobów...T. Stafford, M. Webb, 100 sposobów na zgłębienie tajemnic umysłu, Onepress 2006.

Istota inteligencjiJ. Hawkins, S. Blakeslee, Istota inteligencji, Onepress 2005.

Blog > Komentarze do wpisu

Extreme usability: użyteczność ekstremalna

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.

wtorek, 07 lipca 2009, marekkasperski

Polecane wpisy

  • Definicja UX: Przez wskazanie... Feature na rynku nieruchomości

    Wstęp [można pominąć] 0.1. User Experience to nie jest ' wziu-wziu ' w HTML5. To nawet nie jest front-end. Sorry , nie przekonacie mnie w licznych rozmowach;

  • Z półki projektanta: Koszyk

    Krótki komiks o projektowaniu. *** To jest koszyk na zakupy. To jest ładny koszyk na zakupy, jednak pełni taką samą rolę jak zwyczajny koszyk. Dla sklepu (a

  • Polski Internet śpi

    Nie wiem, czy to za sprawą globalnych dużych graczy, którzy (pod względem zasięgu) przejęli polskich użytkowników, a z nimi polskie budżety marketingowe, ale wy

TrackBack
TrackBack w tym blogu jest moderowany. TrackBack URL do wpisu:
Komentarze
2009/07/09 13:26:03
Jeden z najlepszych artykułów na tym blogu.
-
2009/07/09 13:37:17
:) Nie wiem czy to dobrze, czy źle. Wolę myśleć, że dobrze :)
-
Gość: ndemi, *.neoplus.adsl.tpnet.pl
2009/07/09 15:22:16
Dobry art. "Użyteczność ekstremalna" - świetnie mi znane, szkoda tylko, że na zmiany wynikające z badania "po" też trzeba czekać bo zespoły programistów mają swoje harmonogramy.
-
2009/07/09 15:27:28
1) Na wszystko trzeba czekać i zawsze ktoś czeka. Jak nie klient, to programiści; innym razem użytkownicy. To są koszta , które trzeba wkalkulować.

2) Inna sprawa, to kwestia poukładania prac w zespołach i być może dedykowania grupy programistów szybkiego wsparcia do tego rodzaju współpracy z działem projektowo-badawczym.
-
Gość: ndemi, *.neoplus.adsl.tpnet.pl
2009/07/09 15:38:19
Pewnie byłoby to idealne rozwiązanie - zespół szybkiego wdrażania poprawek. Tylko zdarza się, że na dane elementy ma wpływ szereg różnych czynników, w które muszą być zaangażowani różni ludzie - np. admini. Wtedy to zaczyna iść swoim torem.
-
2009/07/09 15:46:32
zgadzam się - mnie też doświadczenie nauczyło, że szczegółowe raporty nie zawsze wnoszą wartość, a rozwiązanie konkretnego problemu - a i owszem. Ale temat jest trochę bardziej skomplikowany:

1. Klienci, którzy bardzo bardzo bardzo chcą mieć audyt. Bo tak. Bo to wygodne, nie angażuje klienta (współukładanie zadań, myślenie, łażenie na badania). Bo w rozrgrywkach koroporacyjnych szukają podkładek do takich, a nie innych decyzji. Bo "audyt" brzmi godnie. Bo nie wiem co jeszcze - chcą i już.

2. Niektóre serwisy są tak pokopoane, że nie ma sensu robić badania na użytkownikach - wiadomo, że sie zamęczą. Przeprojektowanie pod kątem dobrej (patrz dalej) listy sprawia, że nie będzie się tracić czasu swojego i użytkowników na wykazanie podstawowych błędów.

3. Są listy i listy. Dla niektórych taka lista to kilkanaście-dziesiąt uwag wypisnach z książek. Jeśli lista powstaje również na podstawie doświadczeń badawczych, to jednak część problemów wychwytuje dobrze. Ale faktem jest, że chyba nigdy nie była wystarczająca - użytkownicy na badaniu zawsze mnie czymś zaskakują. Są jednak miejsca, gdzie precyzyjne listy kontrolne mają szczególnie dużą moc - np. formularze.

4. Podsumowując - w większości sytuacji dobre badania, patrzenie pod kątem celów użytkownika, scenariusze - zawsze będzie miało przewagę nad listami. Listy jednak pomagają ogarnąć bajzel na b. złych stronach, a w niektórych obszarach dają przyzwoite efekty (uzyskane szybciej i taniej).
-
2009/07/09 16:01:39
Dzięki Wojtek za komentarz!

Co do 1, to ja się zgadzam. Ale wychodzę z innego założenia - od tego klient ma mnie, jako partnera, bym mu wybił to z głowy. Nie uda się? Trudno.

2-4 Nie chodzi mi tylko o testy z użytkownikami. Zresztą szybkość często wymusza sytuacje, gdzie nie mamy czasu na nie. Piszę o badaniach PO, czyli obserwacjach już na wdrożonym serwisie (lepiej: fragmencie serwisu).

Żeby była jasność, wiem że nie każdy może sobie na coś takiego pozwolić. Wiem, że nie każdy case się do tego nadaje. Ale jak już pisałem, nie wierzę w złote reguły. raz sprawdzi się brunetka, innym razem blondynka ;)
-
Gość: piotr, *.toya.net.pl
2009/07/09 22:04:50
case strony głównej Allegro, zresztą - na pohybel krytykom -
świetnie zrealizowany przez zespół projektowy tej firmy

Zaplacili ci bys tak napisal? ;-) No daj spokoj. Przestane cie czytac w koncu.

-
2009/07/10 16:29:27
@ Piotr: :) Moje poglądy są gratis.
-
2009/07/12 20:23:06
Niestety upowszechniło się dość błędne rozumienie procesu UCD, w którym chodzi przecież o to aby jak najszybciej stworzyć jakiś konkret (makietę, prototyp, wersję beta) do pokazania, a nie o to żeby każdy projekt poprzedzać miesięcznym researchem. Inna sprawa, to że klienci których biznes nie jest stricte internetowy mają trudności ze zrozumieniem, że serwis www nigdy nie jest skończony. To co wdrożone zwykle będzie trochę inne niż, to co zaprojektowane, pewne rzeczy zawsze można stuningować, a ich własne wymagania będą za chwilę już trochę inne w stosunku do tego, co brano pod uwagę podczas projekowania...
-
2009/07/15 00:06:15
Bardzo dobry tekst ale z kilkoma rzeczami w punkcie 1 się nie zgodzę. W prawdzie nie czytałem nigdy żadnego raportu użyteczności i nie mam tak na prawdę pojęcia jak wyglądają ale moim zdaniem trzeba uszanować różne trendy do których użytkownik się przyzwyczaja i które dają mu niejako poczucie bezpieczeństwa na stronie.
-
Gość: KUBA: , *.tktelekom.pl
2009/07/20 13:12:48
Świetnie napisałeś Marek. Rewelacyjnie !
-
2009/08/17 17:40:41
Witam
Trochę w offtopicu, trochę w nawiązaniu - szukam pozycji książkowych o projektowaniu interfejsów webowych i interfejsów gier internetowych. Chodzi mi o teorię i praktykę dotyczącą takich standardów jak budowa menu, rozkład przycisków, kolorystyka, układ treści itd. itp.. Czy możesz mi jakieś polecic?
Dominik Marzec
-
2009/08/17 17:51:55
@soloo Hm, to ciekawe, bo właśnie jestem w trakcie 'wklepywania' listy moich książek z tej tematyki. Możesz sprawdzić moją kolekcję książek z Usability / UCD / projektowania na potrzeby gier komputerowych w serwisie nakanapie.pl.
-
2009/09/16 02:43:40
Dzięki wielkie, a czy którąś z tych knig poleciłbyś jakoś wyjątkowo? Chodzi o temat stricte związany z usability, kawa na ławę;) Bez programowania, bo to nie moja działka. I czy któraś jest dostępna w jezyku polskim, bo nie chcę się męczyć z angielszczyzną:)
Z góry dzięki za odpowiedź, pozdrawiam!
-
2009/09/16 08:58:37
-
2009/09/24 23:54:12
Dziękuję bardzo, zamawiam:)
-
2009/12/30 08:50:44
Może trochę odświeżając temat - większość pozycji książkowych tyczy się projektowania dla web, czy spotkałeś się może z ciekawymi pozycjami dotyczącymi projektowania aplikacji desktopowych? Czy dla tego typu aplikacji (typowo okienkowych) można przenieść niektóre wytyczne dotyczące użyteczności?
-
2009/12/30 11:06:29
@mmizu: Zaczynając od końca:

1. Tak, sporo z zachowań użytkowników z interfejsami webowymi jest tożsama z zachowaniem z interfejsami aplikacji.

1.1. Wszelkie badania mające na celu sprawdzić stopień używalności czy to strony, czy aplikacji, będą w podobny sposób przeprowadzane.

1.2. W końcu standaryzacja GUI jest związana z aplikacjami desktop, a później została przyjęta dla Web. Przykładowo: kiedy stosować dropdown, a kiedy radiobutony, biorąc pod uwagę, że obydwa elementy GUI reprezentują przypadek wyboru jednego elementu z wielu.

2. Co do lektur: w języku angielskimi jest sporo książek poświęconych tematyce usability aplikacji. Z polskojęzycznymi jest znacznie gorzej, ale masz: Spolsky, Projektowanie interfejsu użytkownika : poradnik dla programistów, Cogswell, Tworzenie użytecznego oprogramowania, Cooper, Wariaci rządzą domem wariatów : dlaczego produkty wysokich technologii doprowadzają nas do szaleństwa i co zrobić, żeby tego uniknąć.

Więcej książek: Kolekcja Usability/UCD/Games w serwisie nakanapie.pl.