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

Projektowanie: myślenie o konsekwencjach

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:

  • dodawanie komentarzy,
  • gwiazdkowanie,
  • system 'łapkowy' - jak sam go określam, bazujący na dłoni z kciukiem wystawionym do góry, symbolizującym, że moja opinia jest na Tak, i z kciukiem zwróconym ku dołowi, symbolizującym, że jestem na Nie,
  • i inne systemy opiniowania.

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:

  • użytkownicy mają mieć możliwość wyrażania swoich opinii anonimowo czy tylko przez osoby w jakiś sposób zweryfikowane przez system (np. tylko zalogowane, a więc i zarejestrowane);
  • konsekwencją powyższego jest także ustalenie czy - jeśli przyjąć, że także użytkownicy nie posiadający konta w danym systemie (nie zarejestrowani) będą mogli wyrażać swoje opinie przez komentarze, to powinien być jakiś inny system ich weryfikacji, np. podanie adresu e-mail. Jeśli tak, to po co? (Może po to, by w przyszłości powiadomić przy pomocy tego adresu osobę, że ktoś dodał także komentarz);
  • inną konsekwencją jest także przykładowy, a następujący fakt: w przypadku gdy damy możliwość dodawania opinii przez komentarze tylko osobom zarejestrowanym, współczynnik przyrostu komentarzy będzie dużo wolniejszy, niż w przypadku umożliwienia wyrażania takich opinii przez osoby nie zarejestrowane. Jednak to znowu może rodzić konsekwencje mniejszej ilości osób rejestrujących się, jeśli zaniedbamy kwestię uwypuklenia innych opcji, które dla użytkownika zarejestrowanego będą stanowiły (przynajmniej potencjalnie) wartość;
  • powstaje pytanie czy komentarze można komentować? Co powoduje powstanie struktury drzewiastej komentarzy, a przez to i - nierzadko - mniej czytelnej;
  • a może komentarze można oceniać? Jeśli tak, to czy tylko w ramach przyznawania plusików, czy także minusów? Czy wpływa to na sposób wyświetlania komentarzy - domyślnie będą wyświetlane najnowsze, czy też te z najwyższą ilością plusów?;
  • Itd.

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.

  • Możemy wyświetlać wyniki jako średnią ocenę zebraną przez głosowanie wraz z informacją ile głosów zostało oddanych. (I znowu - czy tylko zalogowani mogą głosować, czy niezalogowani też?).
  • Oraz możemy wyświetlać bardziej szczegółowo informacje - ile głosów na 5 gwiazdek zostało oddanych, ile na 4, na 3 itp.

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).

 

Mockup.

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.

niedziela, 27 września 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/09/29 16:31:32
Życzę powrotu do zdrowia, ale z drugiej strony chyba dobrze, że masz trochę więcej czasu na pisanie na blogu (tak, wiem, egoista ze mnie).

Odnośnie tematu - podejmowanie decyzji, które rozwiązanie jest sensowniejsze w danym przypadku to w niektórych projektach (dla mnie) mordęga.
-
2009/09/29 20:04:16
Zacne i ciekawie poukładane. Ukłony.
-
Gość: mtreder, *.chello.pl
2009/09/29 22:12:43
Gorączka, a jednak nie zaburzyła trzeźwości myślenia. "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)." Powinno być mottem projektantów interakcji i co mniej rozgarniętych PMów.
Zastanawia mnie tylko dlaczego: "prze(ra?)ża mnie już trochę narzędziowe podejście do projektowania". A właściwie, dlaczego "przeraża mnie już"? Wydawało mi się, że narzędziowe podejście do projektowania to domena 'oldschoolowych' projektantów stron-grafików i kombajnów projektowo-programistyczno-graficznych, którzy o użytkownikach myślą jako o odzwierciedleniu siebie i często używają argumentów typu 'jest tak, bo ja tak zawsze się zachowuję przy przeglądaniu stron'. Wydawało mi się, że to dla nich przede wszystkim projekt ma wyglądać, a czy ma sens to już kwestia marginalna. Tymczasem czuję, że raczej uderzasz w projektantów interakcji, którzy bardziej niż skupiają się na prototypowaniu (co ma sens chyba tylko w przypadku: a) testowania z użytkownikami, b) słabej komunikacji na drodze projektant - produkcja) niż na rozwiązywaniu realnych problemów. To oczywiście sytuacja jak leczenie się u fryzjera. Można po tym lepiej wyglądać, ale czy długo się pożyje? Pytanie tylko, czy występowanie takich projektantów jest rzeczywiście powszechną sprawą.

Co do podejmowania decyzji to warto przypomnieć klasyka: "What testing can do is provide you with invaluable input which, taken together with your experience, professional judgment, and common sens, will make it easier for you to choose wisely - and with greater confidance - between 'a' and 'b'." W niektórych sytuacjach ta rada może być bardzo pomocna.
-
2009/09/29 22:39:50
@mtreder: Marcin, niestety narzędziowe podejście nie jest domeną starej szkoły. Na każdym niemal kroku potyka się o pytania: w czym projektować? czy Visio jest ok? czy może jednak lepszy Axure? a co na Maca? Problem polega na tym, że nie zawsze rozwiązaniem jest AI, czasem wystarczy stworzyć dobry algorytm bądź heurystykę rozwiązujące dany problem, a na stronie umieścić tylko jeden link go uruchamiający; żadnych Visio i Axure tu nie potrzeba.

Żeby była jasność, ja bardzo lubię Axure i raczej mam tą przyjemność, że byłem jedną z pierwszych osób, które wprowadzały to narzędzie do kraju. Acz to nie narzędzia są najważniejsze.

Mam w portfolio pewne rozwiązania problemów, które polegały na tym, że coś wyrzucałem ze stron by były efektywniejsze. Są też przypadki, gdy w ramach analizy projektowej trzeba było klientowi powiedzieć, że nie jest dobrym pomysłem wdrażanie tego, czego on sobie życzy, gdyż... i tu oczywiście padały odpowiednie argumenty.

Jeśli wziąć pod uwagę, że clue projektowania polega właśnie na rozwiązywaniu problemów, której efektem MOŻE, ale NIE MUSI być prototyp, to jest to moim zdaniem dużo lepsze postawienie sprawy niż zastępowanie szkoły raportowej (słynącej z okazałych raportów, których w przeważającej części czytała garstka), szkołą makietową.

I powtórzę to jeszcze raz - nie mam nic przeciwko makietom i AI, sam tworze je na co dzień. Jedyne co, to mam wrażenie, że czasem punkty ciężkości źle są rozkładane.