Jeśli ktoś chce się zapytać,ile kosztowałaby go hipoteka 6% na 30 lat na sumę 470 000 złotych,  sprawdzić, jaka jest oczekiwana długość życia 25-letniego Polaka albo obliczyć jakieś skomplikowane równanie matematyczne to powinien zajrzeć  na wyszukiwarkę (czy też w tym przypadku maszynę do odpowiedzi)  WolframAlpha.

WolframAlpha to usługa online stworzona przez Wolfram Research, która, zamiast przeszukiwać dokumenty i strony internetowe,  przetwarza odpowiedź na bazie ustrukturalizowanych danych. O WolframAlpha pierwszy raz było słychać w maju 2009, kiedy została ogłoszona  przez Popular Science największą innowacją technologiczną zeszłego roku.

Najwiękasza różnica między WolframAlpha a tradycyjnymi wyszukiwarkami to to, że, zamiast przeszukiwać danych na bazie indeksowania wyników analizy semantycznej, stara się zaproponować jedną pełną odpowiedź na pytanie użytkownika  przy użyciu bazy wiedzy (knowledge base) wyposażonej w  dane strukturalne.  Nowa maszyna jest zbudowana w oparciu o program Mathematica, dzięki czemu użytkownicy są w stanie otrzymać odpowiedzi na skomplikowane zagadnienie matematyczne a także odpowiednie wizualizacje.

Zdarzało mi się słyszeć opinie, że WolframAlpha to kolejny “Google  Killer”, ale wydaje mi się, że tak naprawdę te dwie wyszukiwarki nie są dla siebie konkurencją, a raczej uzupełniają się wzajemnie (jak google i wikipedia).  Co jest, wg. mnie niesamowite, jeżeli chodzi o WolframAlpha to sposób pokazania wyników: z obliczeniami, grafami i wszystkim tym co sprawia, że człowiek dostał pełną i wiarygodną odpowiedź na pytanie. Co po raz kolejny pokazuje, jak ogromną wartością jest porządne  zaprojektowanie interakcji i interfejsu użytkownika – takiego, który nie tylko działa, ale też działa tak, że aż się chce z niego korzystać:)

Członkowie grupy realizują projekty z zakresu zrównoważonego, odpowiedzialnego projektowania. Powstałe produkty odpowiadają na realne, istniejące potrzeby i są wynikiem badań i wnikliwej analizy otoczenia. Wszystkie realizowane pomysły są związane z procesem recyclingu, ponownym przetwarzaniem dostępnych już materiałów. Są to różnego rodzaju odpady, od papieru po tworzywa sztuczne. Makultura promuje proekologiczne zachowania, a tym samym stara się upowszechniać segregację odpadów. Członkowie grupy, jako projektanci, mają  większą zdolność do wizualizowania informacji oraz potrafią realizować projekty, które odpowiadają na rzeczywiste potrzeby np. pojemniki ułatwiające segregację odpadów. Organizują warsztaty z dziećmi i dorosłymi, wykłady oraz wystawy, które mają edukować i promować ekologiczny design.

Największą dotychczas zorganizowaną przez nich wystawą była HejNow Kraków na III Międzynarodowym Festiwalu Designu w Łodzi 2009, na której zaprezentowali ekologiczne projekty, powstałe na krakowskiej ASP. W styczniu 2010 roku grupa prowadziła wykład „Najbliższe otoczenie jako baza do działania” na 2-ej Międzynarodowej Konferencji Projektowej: „Odpowiedzialne Projektowanie Graficzne” w Katowicach. W lutym 2010 prowadzili warsztaty projektowe w ramach WORK/SHOP’u zorganizowanego przez Rondo Sztuki w Katowicach, które miały na celu rozpowszechnienie idei recyclingu i świadomego projektowania. W warsztatach brali udział nie tylko młodzi projektanci, ale również amatorzy, którzy chcieli nadać kolejne życie odpadom przemysłowym.  Tego typu warsztaty będą odbywały się cyklicznie, a Makultura każdorazowo będzie przygotowywała odrębny program dla swoich podopiecznych.

Obecnie Makultura jest na etapie realizowania projektów w ramach warsztatów Polyester Design Creative Workshop z firmą Perfect Sobierajski. Członkowie zajęli się trudnym tematem odpadów przemysłowych, zagospodarowaniem wiórów oraz ścinków powstających przy wdrożeniach i produkcji wyrobów poliestrowych. Odpady poliestrowe nie są biodegradalne, a jedyna metoda ich pozbycia się to składowanie przez tysiące lat na śmietniskach. Projektują produkty, których wytwarzanie “skonsumuje” wszystkie odpady, powstałe przy ich wdrożeniu i seryjnej produkcji, a tym samym zmniejszy ilość składowanych odpadów na śmietniskach.

W ramach działalności grupy powstają projekty na bazie wspólnych założeń, co nie wyklucza jednak bardzo różnych efektów końcowych. Takie działania stwarzają  warunki do wzajemnej edukacji. Oprócz działalności w grupie, każdy z projektantów podąża własną drogą rozwoju zawodowego.

Przeglądając ich blog, znalazłam kilka naprawdę rewelacyjnych projektów  (materiał tekstowy pochodzi z blogu grupy, a zdjęcia wykonane są przez jednego z jej członków: Przemka Szubę i również dostępne na ich blogu).

Pasedo (zaprojektowane przez Jadwigę Husarską-Chmielarz) to papierowe siedzisko przeznaczone do pracy z umieszczonym na kolanach notebookiem. Zaprojektowane z myślą o studentach wykorzystujących każda wolna chwilę na pracę nawet w korytarzach uczelni. Siedziska można sztaplować, a dzięki eliptycznemu uchwytowi łatwo przenosić. Zostało wykonane ze ścinków papieru pociętych w nieszczarce. Ścinki sklejono warstwami klejem celulozowym na formie negatywowej. Papierowa skorupa o grubości 1 cm została w środku wzmocniona „lejkowatym” kształtem mogącym przenosić znaczne obciążenia. Dolną krawędzi siedziska spaja aluminiowa lub tworzywa listwa chroniąca papier przed rozwarstwianiem. Zużyte siedzisko należy oddać na makulaturę.

Tuboret (zaprojektowany przez Franciszkę Kornecką) to siedzisko dla potrzeb studentów, np. oczekujących na korekty przed drzwiami Katedr. Wykonany z odpadowych bobin, czyli kartonowych tub, na które nawija się np. papier. Dwadzieścia rur o długości 40 cm i średnicy 5,8 cm połączone ze sobą linką. Tuboret można zawiesić na ścianie tworząc siedzisko z oparciem, gdy nie jest używane można je odwiesić na zaczepy. Po zdjęciu, w zwiniętej formie może być niskim (20 cm) lub wysokim (40 cm) wolnostojącym taboretem. Po rozłożeniu na płasko staje się rodzajem maty.

Kostek (zaprojektowany przez Paulinę Kordos) jest odpowiedzią na potrzebę powtórnego wykorzystania papieru. Zaprojektowany obiekt w formie kostki sześciennej składa się z 3 identycznych części połączonych gumą. Obiekt pozwala na przyjęcie dwóch pozycji siedzących, jednej półleżącej i jednej leżącej. Złożony w formie sześcianu jest taboretem, gdy odchylimy górną część i oprzemy o ścianę jest niskim fotelem (dobry dla studenta dla tymczasowej pracy z laptopem). Gdy odchylimy dwie części i oprzemy o podłogę możemy przyjąć pozycję półleżącą, a rozłożone wszystkie częsci tworzą rodzaj maty. Obiekt jest wykonany ze ścinków zgniecionego papieru, spojony klejem celulozowym w formie nadajacej prostopadłościenność. Elastyczne łączenie samoczynnie składa wszystkie elementy w sześcian.

Świetne pomysły, prawda?! Gorąco polecam wszystkim ich bloga i mam nadzieję, że jeszcze nie raz będzie można o nich usłyszeć! A jesli ktoś chciałby posłuchać mojej z nimi rozmowy to zapraszam do  wysłuchania audycji Radia Novum w  Radia Wnet.

Na potrzeby dziedziny Interakcja Człowiek Komputer stworzono lub zaadoptowano z innych dziedzin nauki wiele metod pozwalających na zrozumienie potrzeb użytkowników, które mają na celu wspomaganie procesu projektowania innowacyjnych rozwiązań technologicznych. Powszechnie używanymi metodami są kwestionariusze, grupy fokusowe czy analizy eksperckie. Tego typu metody zwykle są całkiem niezłe w dostarczaniu szczegółowych danych demograficznych a także pozwalają zebrać opinie o wadach i zaletach danego systemu, jednakże rzadko dają one dogłębne zrozumienie potrzeb użytkowników. Jednym z alternatywnych zestawów metodologicznych zorientowanych na użytkownika są metodologie ogólnie znane jako “participatory design” (współtworzenie). Metodologie te opierają się na założeniu, że projektanci, choć dobrzy w swoim zawodzie, zwykle niewiele wiedzą o kontekście i specyfice zadań, dla których mają projektować lub przeprojektowywać dany system. Stąd w założeniu team projektantów używa narzędzi metodologicznych, które pozwalają na werbalizację  problemów, wad i zalet a także alternatywnych rozwiązań, i od użytkowników, i od członków zespołu projektowego. Aby usystematyzować poznanie owych potrzeby i problemów w kontekście danego zadania, Beyer i Holtzblatt  stworzyli, w oparciu o metody pochodzące z psychologii, antropologii i socjologii, metodę zwaną Contextual Inquiry (w skrócie CI).

CI pozwala w systematyczny sposób zebrać i przeanalizować zapis potrzeb użytkowników i opiera sie na trzech zasadach:

1. zbieranie danych musi odbywać się w kontekście zadania, któremu dany system ma służyć;
2. obserwator i użytkownik wspólnie odkrywają kolejne aspekty danego zadania i
3. badanie musi być oparte o jasno zdefiniowany zestaw potencjalnych problemów związanych z danym systemem.

Potrzeby użytkowników są werbalizowane w oparciu o otwarte pytania zadawane przez obserwatora. Opierając się na zebranych danych obserwator powinien być w stanie szczegółowo opisać proces wykonania danego zadania a także jasno zidentyfikować sposób, w jaki technologia mogłaby wspomagać ten proces. Po zakończeniu wywiadu dane analizowane są przy użyciu metod takich jak „affinity diagrams” czy „card sorting”, a wnioski służą za bazę do podejmowania decyzji o nowych produktach lub o zmianach w istniejących systemach.

Główną zaletą metody CI jest to, że pozwala ona na zebranie szczegółowych danych o sposobie wykonywania zadań użytkowników, a także procesów myślowych, w oparciu o które te zadania są wykonywane. Takie wnioski pozwalają nie tylko na stworzenie innowacyjnej propozycji projektu danego systemu, ale także na szczegółowe umotywowanie każdej decyzji projektowej. Adwersarze tej metody przyznają jednak, że niełatwo jest zrozumieć, co użytkownicy naprawdę robią i dlaczego to robią, a także jakie potrzeby względem rozwiązań technologicznych wynikają ze sposobu wykonania danego zadania.

Częstymi pułapkami, w które obserwator może wpaść, są:

1. zbyt szeroko zakrojone sformułowanie potencjalnych problemów związanych z użyciem systemu;
2. rozłączenie opisu procesu wykonanego przez użytkownika od zakresu zadań danego systemu i
3. nieobiektywna interpretacja sposobu zaspokojenia danej potrzeby użytkownika.

Dwie pierwsze pułapki są nietrudne do uniknięcia poprzez rzetelne przygotowanie się do wywiadu i przedyskutowanie zakresu wywiadu z innymi specjalistami. Ostatnia pułapka jest chyba najbardziej niebezpieczna, ponieważ jest trudna do zauważenia i zweryfikowania, i w konsekwencji może prowadzić do stworzenia systemów opartych na błędnych wnioskach. Powodem do powstania tej pułapki jest to, że CI, mimo, iż pozwala na szczegółowe poznanie potrzeb użytkowników, nie proponuje jednak żadnego systemu zgłębienia istoty tych potrzeb. W konsekwencji współzależności pomiędzy zebranymi danymi mogą się okazać niemożliwe do zidentyfikowania  a wskazówki projektowe sformułowane na ich bazie mogą okazać się zbyt ogólne. Dlatego przy przeprowadzaniu badań przy użyciu CI trzeba koniecznie pamiętać o tym,  żeby na podstawie uzyskanych danych stworzyć “model interakcji”, który powinien być następnie zweryfikowany z użytkownikami. W ten sposób można uniknąć tego, że rozmowa z użytkownikiem była jedynie punktem do odhaczenia na liście kroków projektowych a sprawić, że użytkownik stanie się rzeczywistym podmiotem procesu projektowego.

W zeszłym tygodniu po raz kolejny uświadomiłam sobie potencjalną słabość wywiadów środowiskowych w zrozumieniu potrzeb użytkowników, szczególnie w przypadku, kiedy o tych potrzebach nie rozmawia się z samym użytkownikiem a z jego przedstawicielem. Już słyszę komentarze, że trzeba było się wybrać do właściwego użytkownika zamiast obwiniać metodologię, ale czasami się nie da. Czasami też rozmowa z użytkownikiem jest mało efektywna, bo użytkownik nie zdaje sobie sprawy, że projektant naprawdę nie ma pojęcia, jak dane zadanie się wykonuje…

Ostatnio pracuję nad aplikacją, która ma zmniejszyć poziom stresu u pacjentów w pogotowiu psychiatrycznym. Eindhoveńskie pogotowie psychiatryczne jest  w wielu aspektach bardzo innowacyjne, szczególnie jeśli chodzi o podejście do swoich pacjentów. Około 80 % osób jest do pogotowia przywożonych bez swojej własnej zgody: albo przez policję, albo przez pogotowie, a czasami też przez rodzinę, która lepiej uświadamia sobie potencjalne zagrożenie dla pacjenta i innych  (około 20% osób zgłasza się na pogotowie z własnej woli i w znacznej większości przypadków są to pacjenci powracający).  Taka osoba pozostaje na pogotowiu pomiędzy 7 a 21 dni. Pacjenci przywiezieni na pogotowie są często w takim stanie psychicznym, który nie pozwala ani na rozpoczęcie terapii, ani na kontakty z innymi pacjentami. W tradycyjnych centrach pomocy kryzysowej tacy pacjenci zamykani są w izolatkach, gdzie pozostają dopóki nie wyrażą zgody na współpracę. Takie izolatki także istnieją w eindhoveńkim pogotowiu, ale tutejsi lekarze niechętnie uciekają się do tak ekstremalnych rozwiązań. W ramach poszukiwania programu dającego podobne efekty a jednocześnie pozwalającego pacjentowi utrzymać choćby najmniejszy kontakt ze światem zewnętrznym, tutejsi lekarze zdefiniowali i wprowadzili w życie program, który nazywa się “kamerprogramma” czyli  “program pokojowy” (z tym, że słowo pokój odnosi się do pomieszczenia a nie do pojęcia ideologicznego:).  Podstawowym założeniem tego programu jest  namówienie pacjenta do współpracy poprzez przyznanie mu praw. W praktyce przekłada się to na to, że każdy nowo przybyły pacjent ma do wyboru albo znalezienie się w izolatce, w której praktycznie nie ma żadnego kontaktu ze światem zewnętrznym  (oprócz krótkich wizyt pielęgniarza), albo, w zamian za zgodę na choćby najmniejszy krok terapeutyczny (np. przyjęcie lekarstw lub zgody na rozpoczęcie terapii z psychiatrą) dostaje mozliwość wyboru własnie “kamerprogramma”.

“Kamerprogramma” wygląda następująco: pacjent zostaje ulokowany w pokoju, który wygląda na zwykły pokój i może zdecydować na to, czy pokój ten ma zostać zamknięty, czy nie. Jednocześnie poprzez zgodę na uczestnictwo w programie pacjent zobowiązuje się, że samowolnie z tego pokoju nie wyjdzie. Pacjent może też poprosić o dostarczenie różnych przedmiotów: książek , muzyki, papieru do rysowania a nawet laptopa. Co więcej pacjenta mniej więcej co godzinę odwiedza pielęgniarz i razem opuszczają oni pokój w celu zażycia wybranej przez pacjenta rozrywki (może być to spacer, zapalenie papierosa, czas na uprawianie sportów, czy oglądanie telewizji).  Czas takiej przerwy jest dostosowany do wcześniejszego zachowania pacjenta (czyli im bardziej pacjent współpracuje, tym o więcej może poprosić) a także do jego stanu psychicznego. Jeśli, na przykład, pielęgniarz zauważy widoczny wzrost poziomu stresu (np. w trakcie jakiś zajęć grupowych), wtedy może natychmiast zakończyć daną przerwę i wrócić z pacjentem do pokoju.

“Kamerprogramma” funkcjonuje w Eindhoven od trzech lat i jest chyba całkiem sporym sukcesem: do dziś nie zdarzył się ani jeden przypadek zniszczenia czegokolwiek w pokoju (a mieszczą się tam takie przedmioty, jak zasłonki, untesylia łazienkowe, itp.) ani też żadna próba samookaleczenia. Zarządzający pogotowiem chcieliby jednak zwiększyć atrakcyjność “kamerprogramma” i chcieliby to zrobić z dwóch powodów: żeby dalej rozwinąć system wyborów i nagród (czyli nagradzania dodatkowymi atrakcjami każdej decyzji pacjenta związanej z kolejnymi aspektami terapii) a także aby mieć jak najwięcej argumentów przekonywujących najtrudniejszych pacjentów o wyborze “kamerprogramma” (czyli de facto zgadzających się na terapię) a nie obstających przy decyzji o pozostaniu w izolatce. Dlatego zgłosili się do wydziału Wzornictwa Przemysłowego na mojej uczelni z prośbą o zaprojektowanie, zaimplementowanie i przetestowanie aplikacji świetlnej, która uatrakcyjniłaby pobyt w pokoju programowym.

Jako, że pierwszym krokiem do projektowanie jest zrozumienie potrzeb użytkowników, umówiliśmy się na wywiad środowiskowy z jednym z pielęgniarzy odpowiedzialnych za prowadzenie pacjentów przez “kamerprogramma”. Przygotowaliśmy około 60 pytań pytań otwartych dotyczących procesu przyjmowania nowych pacjentów i wysyłania ich na “kamerprogramma”; tego, jak cały taki program wygląda, jakie są jego wariacje, jakie są wyniki, jego wady i zalety i z czym się to wszystko wiąże dla pacjenta. Rozmowa trwała około dwóch godzin. Naszym celem było dogłębne zrozumienie mechanizmu funkcjonowania całego programu po to, żeby określić zakres projektu a także zidentyfikować jego warunki brzegowe (i tu bardzo chcieliśmy być precyzyjni, z racji tego, żeby nie zaburzyć naszym designem całego procesu terapeutycznego).

Pomimo naszych ciągle powtarzanych i zapewne bardzo uciążliwych pytań, wyszliśmy z rozmowy z uczuciem, że choć rozumiemy więcej niż przed, to jednak nadal więcej nie wiemy, niż wiemy. I to skłoniło mnie do dzisiejszej refleksji na temat wywiadów środowiskowych. Bo przyczyną takiego wyniku nie była przecież ani niechęć rozmówcy do udzielenia nam wyczerpującej informacji, ani też nie nasze nieprzygotowanie. Główną przyczyną takiego wyniku był fakt, że usiłowaliśmy wydobyć z naszego rozmówcy wiedzę, która jest tzw. wiedzą ukrytą czy też wiedzą milczącą (z angielskiego: tacit knowledge). Wiedza ukryta, to to, co wiemy jednocześnie nie zdając sobie sprawy z tej wiedzy. Takim typowym przykładem wiedzy ukrytej jest znajomość zasad gramatycznych w rodzimym języku. Choć każdy Polak wie, jak się odmienia dane słowo (np. słowo dwa, dwie, dwóch, dwojgiem, itp.) to większości byłoby trudno przypomnieć sobie specyficzną zasadę gramatyczną, która leży u podstaw takiej a nie innej odmiany. Podobny fenomen można zaobserwować wśród ludzi, którzy są profesjonalistami w danej dziedzinie. Wiele z rzeczy, które robią w miarę nabywania doświadczenia np. zawodowego, zaczynają robić mechanicznie i w znacznym stopniu nieświadomie i zwerbalizowanie informacji na temat tych właśnie procesów jest dla użytkowników bardzo trudne. Dlatego często w trakcie wywiadu środowiskowego po prostu pomijają tego typu aspekty.

Kolejną przyczyną ukrytą za brakiem szczegółowego opisu procesów przez użytkowników jest założenie istnienia wspólnego poziomu wiedzy na temat danej dziedziny. Osoby przeprowadzające wywiady środowiskowe zwykle są przygotowane do rozmowy, co sprawia wrażenie, że  znają się na danym temacie. To powoduje, że badany zakłada pewien poziom wiedzy badającego i mimowolnie pomija niektóre szczegóły związane z przedmiotem badania. Tak właśnie było w przypadku “naszego” pielęgniarza. Od początku próbowaliśmy się dowiedzieć, jak wygląda dzień pacjenta w trakcie “kamerprogramma”. I choć badany starał się nam jak najdokładniej taki opis podać, to co rusz potykaliśmy się o naszą niewiedzę a jego wiedzę ukrytą, tak trudną do zwerbalizowania. W dodatku badany założył choćby podstawową wiedzę u nas związaną z leczeniem chorób psychiatrycznych. To spowodowało, że ogromnie trudno było nam wydobyć od niego informację związaną na przykład z tym, jaki typ wizualizacji moglibyśmy w naszym designie użyć. A jest to aspekt ogromnie istotny, szczególnie w przypadku osób cierpiących na natręctwa, u których pewne kształty i pewne kolory mogą zwiększenie objawów.

Jak sobie z tym problemem poradzić? Rozwiązania oraz alternatywne metodologie są najróżniejsze. W tym konkretnym przypadku zdecydowaliśmy się dzień obserwacji, w trakcie którego zamierzamy towarzyszyć pielęgniarzowi zajmującemu się pacjentem w trakcie “kamerprogramma” a także na osobiste doświadczenie tego, jak można się poczuć w trakcie takiego programu (czyli spędzić kilka godzin w takim pokoju). Dodatkowo planujemy spotkanie z psychiatrą, któremu chcemy pokazać różne pomysły na wizualizacje i sprawdzić, czy mogłyby one mieć negatywny wpływ na pacjentów. Dopiero wtedy zabierzemy się za szczegółowe projektowanie, implementację i ewaluację.

Tematyka projektowania systemów wspomagających współpracę i komunikacje przez internet jest  od wielu lat w kręgu zainteresowań naukowców. W celu dyskutowania problemów związanych z projektowaniem tego typu systemów powstała nawet specjalna konferencja (Computer Supported Collaborative Work czyli CSCW), która dziś jest drugą najbardziej znaną konferencja naukową w dziedzinie Interakcja Człowiek Komputer. Problem ten stał się również tematem mojego doktoratu, a konkretnie zajmowałam się tym, jak projektować systemy komunikacyjne, tak, żeby z jednej strony pozwalały na przekaz  sygnałów niewerbalnych podobnych to tych, występujących w komunikacji bezpośredniej (twarzą w twarz), a z drugiej strony zachowały swoje unikatowe właściwości wynikające z np. faktu asynchronizacji komunikacji. Jednym z takich istotnych aspektów jest możliwość stosowania “białych kłamstw” w celu ochrony swojej prywatności, o czym pisałam w jednym z poprzednich postów i do którego tematu na pewno jeszcze kiedyś wrócę. Ale dziś chciałabym przedstawić ograniczenia różnych kanałów komunikacyjnych, które zostały zdefiniowane w roku 1991 przez Clarka i Brennana (w artykule: “Grounding in communication”), przedyskutować fazy w komunikacji o raz pokazać jak teoria Social Translucence może być użyta jako wskazówka projektowa do projektowania aplikacji komunikacyjnych, które pozwalają komunikacji przez internet upodobnić się do komunikacji twarzą w twarz.

Zastanawiając się nad tym, czym tak naprawdę jest proces komunikacyjny, Clark i Brennan zauważyli, że każdy typ komunikacji posiada swoje ograniczenia. Ograniczenia te są następujące:

• Jednoczesne występowanie – komunikujący używają wspólnego środowiska oraz jego elementów do ugruntowania swoich wypowiedzi
• Widoczność – komunikujący widzą się nawzajem  i mogą ugruntowywać swoje wypowiedzi przy użyciu znaków niewerbalnych takich jak wyraz twarzy i gesty
• Słyszalność – komunikujący porozumiewają się i ugruntowują swoje wypowiedzi za pomocą języka naturalnego
• Współczesność – komunikujący otrzymują swoje wypowiedzi mniej więcej w tym samym czasie, są one produkowane tak, że opóźnienia w komunikacji są łatwo zauważalne
• Równoczesność – komunikujący mogą jednocześnie wysyłać i otrzymywać wypowiedzi, co pozwala na “backchanneling” (czyli potwierdzanie otrzymania komunikatu przez stwierdzenia takie, jak “aha”, ”hm”, itp.)
• Sekwencyjność – komunikaty nie mogą być wysłane poza sekwencją (np. w komunikacji mailowej, gdzie bez otrzymania odpowiedzi na wysłaną wiadomość nie można kontynuować rozmowy)
• Weryfikowalność – komunikujący mogą zapoznać się z każdą wiadomością w dowolnym momencie, mogą śledzić historię komunikacji
• Korygowalność – komunikujący mogą zmieniać wiadomość, mają możliwość edytować swoje wypowiedzi przed przekazaniem ich drugiej osobie

I tak każdy kanał komunikacyjny pozwala na wzbogacenie komunikacji w jeden sposób a ogranicza inne. Na przykład: w rozmowie twarzą w twarz z łatwością korzysta się ze wspólnych elementów znajdujących się w pobliżu, żeby wspomagać swoje wypowiedzi, ale rozmawiający nie mają możliwości korekty raz wypowiedzianej opinii. W komunikacji przy użyciu maila taka możliwość istnieje, za to ograniczone są możliwości przekazu niewerbalnego. W komunikacji przez telefon również brakuje możliwości używania gestów, za to jest możliwość stosowania tonu głosu czy tzw. “backchanellingu” do wspomagania wymiany werbalnej. I tak dalej…  Taka pokrótka analiza pokazuje, że każdy typ komunikacji ma swoje wady i zalety, które posiadają wartość zależną od typu komunikacji oraz jego celu (np. w rozmowie z szefem z jednej strony ogromną wartość może mieć możliwość korekty własnej wypowiedzi, z drugiej wartością może być możliwość zobaczenia reakcji szefa na dane stwierdzenie). Jednakże każdy typ komunikacji bez względu na kanał komunikacyjny składa się de facto z trzech elementów:

- fazy prezentacji, gdzie jeden z rozmówców przekazuje swój komunikat

- fazy współdzielenia, gdzie oboje rozmówców weryfikuje to, że komunikat został przekazany

- fazy ugruntowania, gdzie oboje rozmówców sprawdza, czy zawartość komunikatu jest przez nich tak samo odebrana.

W komunikacji twarzą w twarz wszystkie te fazy wydarzają się praktycznie w tym samym momencie, a możliwość obserwacji werbalnych i niewerbalnych sygnałów sprawia, że proces ugruntowania (grounding process) jest procesem niemal synchronicznym i prawie niewidocznym. Jednakże w komunikacji przez internet tak nie jest.  Systemy co prawda wspomagają fazę prezentacji (czyli dają możliwość przesłania komunikatu od jednej osoby do drugiej), ale już nie najlepiej radzą sobie z fazą współdzielenia i ugruntowania. Powodem do tego może być niewystarczające zrozumienie, co te dwie kolejne fazy oznaczają w komunikacji przez internet. I tu właśnie może przyjśc na pomoc teoria Social Translucence.

Teoria ta została zaproponowana przez Toma Ericksona i Wendy Kellogg z IBM w roku 2000. Wyjaśnia ona w jaki sposób można podejść do projektowania systemów do komunikacji i współpracy przez internet poprzez wyjaśnienie trzech kroków w przedstawianiu  informacji potrzebnej do udanej komunikacji, mianowicie:

- visibility: wizualizacji informacji potrzebnej do zainicjowania komunikacji

- mutual awareness: doprowadzenia do tego, żeby wszyscy użytkownicy wiedzieli,  jaka informacja jest znana  systemowi i jakie elementy zachowania danej osoby są widoczne dla innych

- accountability: wprowadzenie odpowiedzialności za nieodpowiednie zachowania.

Pierwszy element tej teorii jest w niektórych systemach zaimplementowany. Przykładami takiej właśnie informacji jest status dostępności, który można ustawiać w komunikatorach czy też możliwość zdefiniowania automatycznej wiadomości o nieodbieraniu maili w skrzynce mailowej.  I element ten można porównać z fazą prezentacji zdefiniowaną przez Herberta Clarka w jego teorii Common Ground (opisanej szczegółowo w książce “Using language”).

Co jest jednak problemem w systemach wspomagających współpracę i komunikację przez internet to to, że kolejne fazy czyli faza dzielenia i faza ugruntowania są już zdecydowanie rzadziej ujęte w formie designu. Według mnie można te dwie fazy bezpośrednio odnieść do kolejnych dwóch elementów teorii Social Translucence, czyli doprowadzania do tego, że wszyscy użytkownicy systemu są świadomi tego, co w systemie się dzieje (i nie mogą się wykręcić, że jakaś informacja do nich nie dotarła) oraz, że stają się oni odpowiedzialni za swoje działania w systemie. Przykładem na osiągniecie mutual awareness czyli stanu świadomości na temat tego, co dzieje się z odbiorcą komunikatu jest automatyczne pokazanie statusu dostępności użytkownika jako pierwszej linii rozmowy w komunikatorze Google GTalk. Taki mechanizm sprawia, że rozpoczynający rozmowę będzie na pewno zdawał sobie sprawę, czy przeszkadza drugiej osobie, co może wpłynąć na sposób sformułowania i przeprowadzenia tej rozmowy.

Taka informacja powinna już doprowadzić do odpowiedzialności za swoje zachowania w systemie, ale tak się nie zawsze zdarza. Dlatego w  innych systemach istnieją mechanizmy pozwalające na otwarte egzekwowanie odpowiedzialności za niewłaściwe zachowania. Typowym przykładem są oceny transakcji na portalach zajmujących się pośrednictwem w sprzedaży (jak np. allegro).  Fakt, że każdy może wyrazić opinię na temat zachowania drugiej osoby (oczywiście zdefiniowanej poprzez ramy serwisu, z którego się korzysta) sprawia, że użytkownicy stają dużo bardziej świadomi swoich własnych zachowań w systemie.

Według mnie teoria Social Translucence w sposób jasny i przejrzysty objaśnia założenia teorii Common Ground obrazującej fazy komunikacji międzyludzkiej i wskazuje za to, w jaki sposób projektować systemy wspomagające współpracę i komunikację przez internet, tak, żeby pozwalały one na stworzenie mechanizmów sprawiających, że ludzie będą komunikować się przy pomocy technologii z równą gracją jak twarzą w twarz.

AR zdecydowanie wprowadza kolejną zmianę w sposobie codziennej interakcji międzyludzkiej. Na demo Binga, czterech researcherów pokazuje co na żywo dzieje się w hali targowej. Kiedy  skierowali kamerkę na siebie i pokazali wielkiego kraba, od razu pomyślałam o tym, że już niedługo mój mąż wysłany przeze mnie na zakupy będzie mógł  w AR pokazać, co wybiera i zapytać: Czy to jest na pewno to, co chciałaś…? Jednym z większych wyzwań dla AR w tym kontekście jest zaprojektowanie aplikacji, które pozwolą na efektywną integrację różnych aspektów interakcyjnych w tym samym momencie i w taki sam sposób, w jaki wydarzają się one w rzeczywistości. I tu przychodzi mi do głowy wizja Ambient Intelligence (AI) wymyślona i rozpropagowana przez Emila Aartsa i Stefano Marzano w latach dziewięćdziesiątych. AI to równoznacznik technologii, która w inteligentny sposób jest wpisana w przedmioty codziennego użytku. Do dziś wiele zostało zrobione w temacie implementacji technologii w różne przedmioty, ale stosunkowo niewiele wydarzyło się w tematyce implementacji inteligencji. I może tej inteligencji tak naprawdę nie będzie trzeba wkładać w przedmioty aż tak wiele, jak kiedyś myślano. Może AR sprawi, że inteligencja ludzka zostanie efektywnie wykorzystana do podejmowania nieoczywistych technologicznie decyzji systemowych.

Jednakże, aby taka wizja stała się choćby prawdopodobna istotnym jest stworzenie mechanizmów socjalnych, które pomagają na efektywne działanie w grupie, na eksploatowanie inteligencji socjalnej ludzi. I tu znowu warto będzie zajrzeć do badań naukowych w tematyce HCI w latach dziewięćdziesiątych i we wczesnych latach 2000, gdzie wiele prac podejmuje tematykę współpracy zawodowej. W wielu aplikacjach zaprojektowanych w celu wspomagania pracy na odległość lub koordynacji dużych projektów przykłada ogromna wagę do tworzenia więzi socjalnej pomiędzy użytkownikami systemu. W przypadku kupowania kraba przez mojego męża pewnie taka więź nie będzie potrzebna, ale w przypadku np. inteligentnego sterowania oświetleniem w mieście, gdzie duża liczba nieznajomych musi wspólnie podjąć konstruktywną decyzję, mechanizmy wspomagające tworzenie więzi socjalnej na pewno się przydadzą.

W tej chwili poziom zrozumienia współzależności socjalnych w AR jest na poziomie rozwoju sześciolatka, który musi nauczyć się skomplikowanych zasad funkcjonowania w społeczeństwie aby zrozumieć co jest akceptowalne a co nie. Ale jeśli projektanci UX skorzystają z wiedzy dostępnej zarówno w socjologii i psychologii (gdzie teorie takie jak Common Ground czy Team Cohesion definiują zasady budowy zachowań ludzkich) jak i w dziedzinie CSCW (Computer Supported Collaborative Work) proces tworzenia wzorców interakcyjnych może okazać się mniej skomplikowany niż to się teraz może wydawać. I myślę też, że wykorzystując tę wiedzę, projektanci UX mają szansę stworzyć nowe i unikatowe sposoby interakcji socjalnej w AR. Jeśli natomiast aspekt socjalny zostanie zepchnięty w kąt, AR może poważnie na tym ucierpieć, jako, że zabraknie w niej wykorzystania potencjału ludzkiego, a rozwiązania technologiczne pozostaną indywidualistyczne oraz asocjalne. Tylko jak tego dokonać?

Ważne będzie zrozumienie codziennych zachowań ludzkich w celu „przetłumaczenia” ich na naturalistyczną interakcję w AR. Ludzie posiadają nieograniczoną umiejętność rozpoznawania sygnałów socjalnych w kontaktach bezpośrednich. Jesteśmy czuli na tembr głosu, na wyraz twarzy, na mowę ciała. W dziś szeroko dostępnych technologiach (emailu, komunikatorach, sieciach społecznościowych) wiele z tych cech nie jest w żaden sposób wspomaganych. Ma to oczywiście swoje zalety (jak na przykład możliwość „białych kłamstw”) ale ma też swoje wady, jako, że prowadzi do interakcji , które są niesocjalne wbrew intencjom użytkowników. AR ma szansę na zminimalizowanie tego typu sytuacji, jeśli projektanci skupią się na projektowaniu aplikacji w oparciu o normy społeczne (jak zrobił to jakiś czas temu Facebook, kiedy wprowadził dzielenie się informacją na swój temat jedynie z grupą znajomych a nie z całym światem).  Do tej pory gros badań naukowych w dziedzinie HCI skupiało się na projektowaniu interakcji dla jednego człowieka, a niewiele jeszcze wydarzyło się w kwestii projektowania interakcji modelujących zachowania w grupie. Moją ulubioną teorią w sposób bardzo prosty ujmującą zależności międzyludzkie w interakcji grupowej jest teoria Social Translucence stworzona przez Thomasa Ericksona i Wendy Kellogg z IBM-u w roku 2000, która była podstawą mojej pracy doktorskiej, ale o tym w kolejnym wpisie…

P.S. Ruszył następca blogu: nierobcietegowdomu.pl  zwany tym razem nierobcietegosami.pl, który współtworzę wraz z Marcinem Brodziakiem i Karolem Stośkiem. Bardzo serdecznie zapraszamy!!!

Aga: Jaka jest rola projektanta UX w Google?

Jake: Istnieje wiele różnych rzeczy, którymi projektant UX się zajmuje. To często zależy od typu projektu, w którym jesteś, a także moment, w którym ten projektu się znajduje. Na przykład, zadaniem projektanta we wczesnych etapach projektu jest  robienie badań na temat potrzeb użytkowników, kontekstu dla danego produktu a także łączenie tych potrzeb z tym, co dany produkt stara się rozwiązać. Zajmujemy się również tworzeniem wire-frames, diagramów interakcyjnych a także niektórych prototypów. Kolejne bardziej zaawansowane prototypy tworzone są już wspólnie z inżynierami.  W Googlu nikt nie zamyka się w swoim pokoju, siedzimy w przestrzeni otwartej, co stwarza możliwość rozmowy z inżynierami i menedżerami w każdej chwili. Zawsze można po prostu pójść do inżynierów i zapytać, jak łatwo pewien pomysł może być zaimplementowany a także co inżynierowie myślą o danej koncepcji z ich perspektywy.

Co to jest bardzo ciekawe jest to, że w Googlu pracuje bardzo niewielu projektantów i niewielu menedżerów w porównaniu do tego, co widziałem w innych miejscach, więc często też trafiają się sytuacje, w której projektant musi rozwiązać wiele kwestii, które zazwyczaj znajdują się w gestii menadżera. Musisz rozmawiać z różnymi ludźmi , żeby dowiedzieć się, w jaki sposób najlepiej połączyć różne elementy systemu ze sobą. Obowiązkiem projektanta jest zadbać o stronę projektu związaną z użytkownikiem, tak, że znajduje się on w centrum decyzji i negocjacji związanych z rozwojem i kierunkiem projektu. Co więcej projektant jest sam odpowiedzialny za to co powinno być zrobione w kolejności. Jako , że każdy team i każdy projekt ma swoje własne unikatowe podejście, nie ma czegoś takiego jak dyskutowanie specyfikacji w celu przejścia od jednego punktu do drugiego. Tak, że często zadaję sobie pytanie: co powinienem teraz zrobić? I zwykle muszę dochodzić do tego samodzielnie.

Mitch: Jest  to rzeczywiście wielkie wyzwanie, żeby  Dowiedzieć się, jakie jest kolejne wyzwanie dla projektu w danym momencie i  pomoc zespołowi osiągnąć ten cel,  jest prawdopodobnie największym wyzwaniem dla wszystkich projektantów. Ale nie zależy to od różnic w podejściu poszczególnych zespołów, także różni projektanci UX mają różne zestawy umiejętności, tak więc niektórzy z nich są najszczęśliwsi, kiedy od razu mogą zabrać się za budowanie prototypów, podczas gdy inni  są są dużo lepsi  w tworzeniu koncepcji oraz zbieraniu różnorodnych pomysłów do kupy. Tak, że to co ma być kolejnym krokiem w projekcie jest tan naprawdę  wynikiem negocjacji między projektantem UX i zespołem inżynierskim. Takim kolejnym krokiem nie zawsze musi być kolejna wersja systemu czy aplikacji, może to też być  decyzja o tym, że jest potrzebna burza mózgów lub wręcz konstruktywna dyskusja na temat podejścia do kolejnych kroków w projekcie.

Jake: Co jest niesamowite według mnie to to, jak dobrzy inżynierowie w Google są, w tym, co robią. Dasz im zwykły mock-up a oni na tej podstawie potrafią zbudować system dokładnie tak,  jak im to zasugerowałem.  Inżynierowie są też wstanie bez problemu rozwiązać wiele kwestii na własną rękę, więc nie musisz dla nich definiować każdego kolejnego  kroku, szczególnie przy projektowaniu nawigacji i interakcji. I tylko wtedy, gdy dochodzi do sytuacji, że nie są pewni, co robić dalej, zwracają się do nas z prośbą o poradę. To sprawia, że twoja praca może zajść o wiele dalej, bo nie musisz spędzać dużo czasu wyjaśniając, co należy zrobić, gdy użytkownik kliknie na dany link.

Mitch: W mojej poprzedniej pracy  tworzyłem koncepcję rozwiązania, a następnie rozpoczynały się negocjacje: i różne elementy były usuwane, i usuwane, i usuwane. Tutaj inżynierowie zwykle mówią:” Tak, możemy zaimplementować, to co zaprojektowałeś” i wtedy czuję jakbym nie był wystarczająco wymagający, jakbym niewystarczająco eksperymentował z niektórymi bardziej szalonymi stylami interakcji. Czasami zastanawiam się, czy kiedyś trafią na ścianę;  czy będą potrafili zbudować jeszcze to czy tamto. A oni ciągle i ciągle tworzą to, co zaprojektowałem, choć przy projektowaniu czasami zastanawiam się, czy dany pomysł jest tak naprawdę możliwy do implementacji.

Aga: Mówiliście wiele o współpracy pomiędzy projektantami i zespołami. A w jaki sposób współpracują za sobą projektanci UX?

Mitch: Taka współpraca wygląda nieco inaczej w Zurychu w porównaniu Mountain View, gdzie projektanci UX są zgrupowani są w jednym miejscu i współpracują ze sobą całkiem sporo.  W Zurychu jesteśmy zwykle zaangażowani w różne projekty i bardzo rzadko zdarza się, żeby dwóch projektantów trafiło do tego samego projektu. Ale jak tak się zdarzy, to współpracują ze sobą bardzo blisko. Kiedy Jake i ja pracowaliśmy razem w Gmailu, siedzieliśmy obok siebie pracując nad różnymi aspektami projektu, a co jakiś czas jeden z nas rzucał: Hej, spójrz na to – co o tym myślisz?

Jake: Myślę, że jest to dla nas wyzwanie. Zajmujemy się  różnymi rzeczami  i mamy tendencje, żeby  bez opamiętania wciągnąć w swój projekt. Oczywiście, współpracujemy z projektantami z innych ośrodków. Ja swoje projekty zwykle wysyłam do Mountain View i dyskutuję potrzebne zmiany za pośrednictwem czatu lub wideokonferencji. Ale to, czego mi bardzo brakuje, to możliwość  dostania tego typu opinii dokładnie wtedy, kiedy nad czymś pracuję. Dlatego brakuje mi takiej bezpośredniej interakcji z innymi projektantami z mojego projektu, odległość powoduje, że  tracę okazję,  aby zadać jakieś  pytanie, zapytać, co myśli, kiedy się nad czymś trudnym głowię.

Aga: Jak widzicie przyszłość zespołu UX w Google w Zurychu?

Mitch: Myślę, że planem  jest, żeby Zurych  stał się centrum UX dla regionu EMEA. EMEA jest ciekawy i zróżnicowany obszar składający się z wielu różnych krajów i kultur, a my  staramy się wspierać  rozwój produktów Google, tak, aby zawrzeć te różnice. Staramy się również zapewniać wsparcie UX dla różnych biur EMEA, które nie mają swoich własnych projektantów  UX. Niedługo wydarzy się tu  wiele dobrych, ciekawych i trudnych rzeczy, a niektóre z nich już się wydarzają. Jest to również naszym zadaniem badanie różnych potrzeb obecnych w różnych krajach i przekazanie tej wiedzy z powrotem do firmy, żeby Google mógł tworzyć  produkty, które spełniają wymagania tak różnych odbiorców.

Jake: Tak, jak Mitch powiedział: Europa, Bliski Wschód i Afryka są dużym kawałkiem świata, a naszym zadaniem jest identyfikowanie tak różnorodnych  potrzeb  naszych użytkowników i sprawianie, że nasze produkty  staną się jeszcze bardziej przydatne – myślę, że jest to naprawdę ekscytujące miejsce do pracy.

Rok temu wyjechałam do Zurychu do Googla na pięciomiesięczny projekt badawczy. I jak było do przewidzenia,  biuro okazało sie wyglądać jak plac zabaw dla dorosłych chłopców, jedzenie było pyszne i pracowali tam przedstawiciele 62 narodowości. Ale co tak naprawdę sprawiło, że ta przygoda stała się niezapomnianą , to ludzie, z którymi miałam okazję współpracować. Aw szczególności dwie osoby: Mitch Hatscher z Niemiec i Jake Knapp ze Stanów Zjednoczonych. Mitch jest jednym z pierwszych projektantów UX zatrudnionych w Google Zurich. Jake jest projektantem UX w Gmailu i człowiekiem,  który był moim “zawsze gotowym do pomocy” doradcą i fantastycznym sparing partnerem. I pod koniec pobytu,  ryzykując naciągnięcie ich życzliwości do akceptowalnych granic, prosiłam ich, aby trochę opowiedzieli o Google Zurich i ich doświadczeniach w firmie.  Dziś pojawia sie pierwsza część tego wywiadu, na kolejną zapraszam za tydzień.

Aga: Jakie były początki grupy UX w Google w Zurychu?

Mitch: Na początku biuro w Zurychu zajmowało się głównie projektami infrastrukturalnymi, które nie wymagały wiedzy UX. Ale po tym jak pojawiło się kilka projektów z faktycznym interfejsem użytkownika (np. Endoxon) a także pojawiły się projekty zainicjowane przez tutejszy lab (np. niektóre prace związane z Gmailem), pojawiła się też potrzeba  lokalnego wsparcia UX. W tym czasie jedyną opcją była pomoc  z centrali Google w Mountain View w Kalifornii. W pewnym punkcie inżynierowie w Zurychu zaczęli prosić o lokalnych specjalistów, i to był moment, kiedy Google utworzył dwa stanowiska dla projektantów.  I tak, w marcu 2007 ja i jeszcze jeden kolega zaczęliśmy pracować w Zurychu jako projektanci UX. Kiedy przyszliśmy do pracy, nie było żadnej struktury do wdrażania tego typu projektów. Po tygodniu kursów wprowadzających tu na miejscu pojechaliśmy do Mountain View na dwa tygodnie  podstawowego szkolenia UX.  Dzięki naszej ówczesnej menadżerce udało nam się zdefiniować pierwszy projekt, którym mieliśmy się zająć po powrocie do Szwajcarii.

Wspaniale było zobaczyć, jak chętnie każdy chciał z nami współpracować  i jak bardzo doceniany był nasz wkład. Potem spotkaliśmy  Aarona, jedengo z inżynierów, którzy już wczesniej zorganizował grupę, tzw grouplet, inżynierów zainteresowanych UX. Wkrótce (chyba w kwietniu 2007) połączyliśmy siły z grouplecie i rozpoczęlismy organizowanie UX Office Hours, gdzie projekty bnie posiadające własnego projektanta mogły przyjść i poprosić o poradę. A ponieważ grupa musiała rosnąć, szybko przeszliśmy szkolenia rekrutacyjne, a dwa miesiące później uczestniczyliśmy już w rekrutacji kandydatów na nowych UX-ów.

Aga: Jak to było przenieść się z Seattle do Zurychu?

Jake: Zacząłem pracować w Google tuż przed Mitchem. Ale zanim jeszcze dołączyłem do firmy, wiedziałem, że mieli siedzibę w Zurychu. A ponieważ ja i moja rodzina już bralismy pod uwagę spędzenie rok lub dwóch w Europie, od razu zainteresowałem się możliwością przyjazdu tutaj, bo połączenie Google i Europie było bardzo atrakcyjne. Ale zanim mogłem to zrealizować, musiałem spędzić rok w Seattle. Od początku kontaktowałem się Mitchem, żeby dowiedzieć się, co dzieje się w Zurychu i ustawić moją pracę w Stanach tak, aby była powiązana z tutejszymi projektami.  Kiedy przyjechałem w Zurychu wiele się już tu zmieniło dzięki staraniom Mitcha. Było zatrudnionych kilku projektantów UX. I nawet nie byłem pierwszą osobą, która przeniosła się do Zurychu z innego miejsca. Po moim przyjeżdzie dołączył też Steve Rogers, nowy dyrektor ds. EMEA UX, i  czuje się jak nasza grupa rośnie, jest coraz bardziej zorganizowana i coraz mniej zależna od wsparcia z Mountain View.

Aga: Czym odróżniają się od siebie biura Google?

Jake: Pracowałem już w czterach biurach: w Kirkland; w Seattle, w Mountain View i oczywiście  w Zurychu. Biuro w Kirkland jest najbardziej zbliżone do biura w Zurychu: oba są podobnej wielkości i oba mają swoje “osobowości”, które odróżniają je od innych biur Google. Biuro w Seattle było bardzo małe i stosunkowo nowe, kiedy tam pracowałem, więc nie wiem, czy już wyształciło swój własny charakter.

Porównując  Zurych z amerykańskimi biurami najbardziej uderzające są różnice kulturowe. Czasami wręcz trudno powiedzieć, czy pewne rzeczy to tylko specyfika danego biura czy właśnie różnice kulturowe.  Co to jest podobne dla wszystkich biur satelitarnych (niezależnie od tego czy są one zlokalizowane w USA czy w Europie), muszą one intensywanie współpracować z macierzystym Moutnain View.  Co jest szczególnie problematyczne w Europie to róznica czasowa, a także czas spędzony w podrózy, żeby tam dotrzeć. Kiedy pracowałem w Kirkland, mogłem być w Moutnain View przez kilka dni w miesiącu. Dzieki temu mogłem zbudowac i utrzymać mocne więzi z innymi kolegami i zespołami, z którymi współpracowałem. To jest po prostu niemożliwe do zrobienia, kiedy jest się w Europie.

Aga: Co zauważyłam kiedy przyjechałam do Google to mała liczba  projektantów UX w Google w ogóle, a w szczególności w Zurychu. Jaki jest wpływ UX w Google?

Jake: To bardzo zależy od tego, kiedy projektant dołącza do projektu. Jeśli przystepujemy do niego na samym początku (czyli w idealnym dla nas momencie), Jeśli możemy wiąć udział w fazie badań użytkowników, ocenić różne możliwości  projektowe to wtedy jesteśmy w stanie w pełni zaangażować się w kształtowanie takiego projektu. Ale może się zdarzyć, że dołączymy do projektu, który już trwa w najlepsze i wtedy staramy się jak najlepiej wspierać to, żeby projekt naprawdę rozwiązywał problemy użytkowników i zaoferował jak najlepszą interakcjęi interfejs użytkownika.

Ale wracając do piewrwszego pytania: myślę, że wpływ zespołu UX w Google bardzo różni się od roli tego typu zespołów w innych firmach. Google to firma inżynierska i zespoł UX jest naprawdę niewielki, ale pomysł stawiania użytkownika na pierwszym miejscu naprawdę bardzo pomaga.  Inżynierowie naprawdę wierzą, że użytkownik to najważniejszy „element” projektu  i chcą w jak najlepszy sposób swych użytkowników zadowolić.

Oczywiście, czasem powoduje to kolejną lawinę problemów, zwłaszcza jeśli starasz się przekonać swoich kolegów do myślenia użytkowników, które nie jest koniecznie takie samo, jak ich podejście do problemu. Ale ogólnie rzecz biorąc, ludzie w Google naprawdę chcą zrozumieć użytkowników i ich potrzeby, i bardzo cenią nasza pracę.  Inzynierowie chcą zrobić swoją robotę jak najlepiej i to własnie sprawia, że praca projektanta UX jest łatwiejsza i przyjemniejsza.

Mitch:  Zgadzam się z Jakem całkowicie: jest dla mnie zdumiewające jak bardzo moze różnić sie podejście firm inzynierskich. W firmach, w których pracowałem wcześniej, najczęściej musieliśmy walczyć z całą firmą, żeby kogoś przekonać o tym, czego chcą użytkownicy i byliśmy bardzo, bardzo szczęśliwi, gdy udało nam się uzyskać choć trochę lepszy UX dla danego produktu.  W Google każdy chce tworzyc świetne produkty. To prawda, że czasem inżynierowie nie rozumieją, jakie są cele i potrzeby użytkowników, ale chcą tworzyć produkty, któreludzie rzeczywiście będą chcieli używać, a to ogromna różnica dla projektantów UX. W większości  przypadków zamiast walczyć  ze specjalistą od UX, inżynierowie proszą o wskazówki i pomoc, a to jest dla nas bardzo luksusowa sytuacja. Często jest to dla nas bardzo duże wyzwanie, bo wszyscy tutaj są ekspertami w swoich dziedzinach i wszyscy mają bardzo silne osobiste poglądy, więc trzeba być bardzo dobrze przygotowanym przed udaniem się na każdą dyskusję. Ale nie trzeba tracic energii starają się ewangelizować UX, wszyscy tutaj doskonale wiedzą, jak ważnym elementem systemu jest dobry UX.

Aga: Jak jest zorganizowany dział UX w Google Zurych i w Google EMEA (region: Europa, Bliski Wschód i Afryka)?

Mitch: Organizacyjnie najwiekszą zmianą ostatniego czasu było to, że w Zurychu pojawił się Steve Rogers, nowy dyrektor UX EMEA.  Projektanci UX pracują już w trzech biurach w regionie EMEA: Zurychu, Londynie i Moskwie. Mamy trzy typy stanowisk związanych z dziedziną UX: pracownik naukowy UX, projektant UX i web developer. Co odróżnia UX EMEA od UX w Mountain view  jest to, że w Mountain View zespół UX jest podzielony na szereg podzespołów, które obsługują specyficzną tematykę (np. reklamy lub projektów aplikacyjnych), natomiast w Zurychu jesteśmy grupą ludzi, którzy jednocześnie wspierają projekty o bardzo różnorodnej tematyce. I zdarza się, że ta sama osoba pracuje w kilku często bardzo różnych projektach naraz. W Mountain View jest też tak, że dany menedżer jest również odpowiedzialny za działania UX w danym obszarze tematycznym, podczas gdy w Zurychu dyrektor UX jest odpowiedzialny za nas na poziomie personalnym, a w kwestiach tematycznych musimy raportować do kogoś ze Stanów.

Jake: Dla mnie zespół UX w Zurychu to jak  ”Drużyna A” znana z zerialu telewizyjnego: to grupa osób, która choć technicznie posiada menedżera, to nie jest tak do końca zorganizowana. Jest w niej pracownik naukowy, grupa projektantów i deweloperów, lecz także wiele osób zna sie na więcej niż tylko jednej dzedzinie. Wielu z naszych projektantów wie, na przykład,  jak budować prototypy.  A ponieważ jesteśmy jednym z mniejszych biur,  to musimy nauczyć się rozwiązać problemy dzięki umiejętnością które wspólnie posiadamy. Żeby uzyskac naprawdę dobry wynik musimy umiec robić swoją robotę i też choc trochę  znać się na tym, co robią inni.
Mitch: Dzięki temu udaje nam się uzyskać znacznie szerszy zestaw umiejętności i wiedzy na temat różnych produktów Google, w porównaniu do proejtantów w Mountain View, gdzie nie jest łatwo zmienić jeden obszar tematyczny na inny. Kiedywyznaczamy  ludzi do projektów, robimy to w następujący sposób. Pod koniec kwartału, prosimy kierowników projektów o przysłanie prośby o wsparcie UX dla ich projektu wraz z motywacją tej prośby. Następnie oceniamy te prośby pod względem nakładu pracy i na tej podstawie wyznaczamy odpowiedniego projektanta do danego projektu. W niektóre projekty jesteśmy w pełni zaangażowani, ale w innych omawiamy zakrez pracy UX zanim zdecydujemy się wziąć w nich udział. Na tej podstawie podejmujemy decyzje, które projekty naprawdę potrzebują wsparcia UX (jak, że z reguły mamy więcej projektów niż mozliwości) i tam alokujemy ludzi.

Jake: To jest kolejna niesamowita rzecz w Googlu: nikt tu nie boi się eksperymentować z nowymi procedurami i procesami organizacyjnymi. Jeśli okaże się, że dany proces nie działa, to albo sie go poprawia, albo całkowicie zmienia. Łatwo jest tu próbować nowych rzeczy. Tak, że praktycznie nigdy nie ma takiej sytuacji, że musisz przejść przez proces, który nie ma sensu lub jest bezużyteczny. Jeśli proces się nie sprawdza, to po prostu się go zmienia na lepszy.

Zainspirowana jednym z wykładów na uczelni,  zaczęłam się ostatnio zastanawiać, co tak naprawdę znaczy słowo: efektywność w kontekście badań użyteczności. Typowa odpowiedź to:   czas potrzebny do wykonania danego zadania przy użyciu danego narzędzia. Prawda to, choć niecała.  Bo rodzaje efektywności są tak naprawdę dwa:

• efektywność pragmatyczna (czyli optymalizacja wykonania danego zadania) i
• efektywność poznawcza (czyli optymalizacja wysiłku poznawczego potrzebnego dodanego zadania)

Czyli tak naprawdę pytanie o efektywny design to nie pytanie o to jak najszybciej wykonać dane zadanie a raczej, jaka jest najwłaściwsza droga do poradzenia sobie z danym problemem. Ale co to znaczy? Według mnie, żeby ocenić efektywność danego systemu trzeba ocenić trzy rzeczy:

• prostotę znaczeniową, która dla mnie oznacza, że użytkownik dostaje właściwe rozwiązanie we właściwej postaci
• umiejscowienie, czyli to, że użytkownik natyka się na kolejne elementy informacyjne i interakcyjne we właściwym miejscu i o właściwym czasie
• tempo, czyli to, że wszystko to odbywa się w odpowiednim tempie i przez odpowiednią ilość czasu.

No dobrze, ale jak to osiągnąć?  Jest na to kilka podstawowych zasad:

• przede wszystkim trzeba pokazać użytkownikowi właściwy kawałek informacji i instrukcji w momencie, kiedy może jej potrzebować. Najlepszym tego przykładem, na jaki natknęłam się ostatnio są strony portalu radiownet, gdzie prowadzimy z Łukaszem podcast o innowacji  (www.radiownet.pl/radio-novum). Ktoś wyszedł z założenia, że zakładanie radia to proces krokowy, więc i instrukcje można podzielić na odpowiednio małe kawałki i właściwy kawałek umieścić  na ekranie we właściwym momencie.

• Należy też zapewnić użytkownikowi wygodny sposób wykonania zadania, czyli zapewnić elementy interakcyjne pozwalające na kolejne kroki. Jest to pewnie łatwiejsze do wyobrażenia w kontekście projektowania przedmiotów użytkowych, jak np. czajnik, którego rączka nie powinna się nagrzewać w czasie gotowania wody (co wydarza się w przypadku naszego). Ale odnosi się to też do sfery cyfrowej, gdzie użytkownik powinien bezproblemowo znaleźć potrzebną mu funkcjonalność. Dla mnie przekłada się to bezpośrednio na prostotę interfejsu, ale także na redundancję, czyli na zapewnianie użytkownikowi więcej niż jednej opcji pozwalającej na zrobienie kolejnych kroków zadaniowych. Takim typowym przykładem może być umieszczanie kilku opcji to zalogowania się do sklepów internetowych lub więcej niż tylko jedna możliwość dostępu do listy oferowanych przez nie kategorii produktów.

• W każdym przypadku użytkownik powinien być prowadzony “za rękę” przez system. To oznacza, że sposób użycie kolorów, elementów interakcyjnych czy multimodalnych rozwiązań nie powinno być jedynie elementem dekoracyjnym, ale też podpowiedzią dla użytkownika pozwalającą mu na zorientowanie się gdzie jest, co ma do dyspozycji i co dalej może lub powinien zrobić. Dlatego tak istotnym jest konsekwentne umieszczanie powtarzających się elementów w tych samych miejscach.  Takim sztandarowym przykładem jest prezentacja fontów w edytorach tekstów. Samo napisanie nazwy czcionki  nie ułatwia wyboru użytkownika. Natomiast napisanie nazwy czcionki przy pomocy tej właśnie czcionki daje użytkownikowi potrzebna do dokonania takiego właśnie wyboru wskazówkę.

• Wreszcie istotnym jest zapewnienie użytkownikowi właściwych narzędzi potrzebnych do wykonania danego zadania. Tu chyba najlepszym przykładem IKEA, która nie tylko sprzedaje meble, ale też dostarcza użytkownikowi narzędzi pozwalających na ich zamontowanie.  W kontekście cyfrowym takim odpowiednikiem jest automatyczne wypełnienie za użytkownika danych osobowych, które znajdują się już w systemie, czy też dostarczenie mu bezpośredniej pomocy, kiedy poszukuje potrzebnej informacji. Może nie jest to typowy przykład, ale ja sama najczęściej zauważam taką potrzebę, kiedy zgłaszam artykuły naukowe do publikacji i potrzebuję stworzyć listę słów-kluczy. W niektórych serwisach naukowych taka lista jest osadzona obok pola wymagającego tej informacji, w innych jest podpięty link do odpowiedniej taksonomii, a w niektórych nie ma nic i samemu trzeba szukać i kombinować, jakie dokładnie są wymagania związane z tagowaniem artykułu.

• Na końcu jeszcze ważne jest to, żeby wprowadzać ograniczenia interakcyjne. Ograniczenia obniżają poziom niepewności użytkownika związany z tym, co robić w danym momencie i przyspieszają jego decyzje interakcyjne. Ale ograniczenia nie powinny być wprowadzane bez poinformowania użytkownika, kiedy będzie mógł daną czynność wykonać. Takim typowym przykładem ograniczeń jest  niewysłanie wiadomości mailowej bez wpisania jej treści.

Bo z tworzeniem systemów dla użytkowników jest jak z pisanie przepisu na sernik. Kucharz potrzebuje nie tyko właściwej informacji we właściwym momencie, ale też holistycznej wiedzy o tym co trzeba zrobić dalej, jakie narzędzia są to tego potrzebne i czego absolutnie nie można zrobić. Każda interakcja ma swój naturalny proces, swój naturalny rytm i strukturę. Dlatego, żeby wspomagać taki proces należy:

• umieszczać opcje tam gdzie naprawdę przynależą
• redukować złożoność opisową i wizualną
• dobrze zrozumieć proces  i wspomagać właściwe kroki i decyzje (również w sposób niebezpośredni)
• nie pokazywać użytkownikowi całości informacji, ale też zagwarantować, że ma całościowy obraz danego procesu
• zaproponować właściwą sekwencję kroków, czyli zasugerować, że wysłanie pustego maila nie jest może tym, co użytkownik chciał
• i wreszcie pytać o odpowiednią informację we właściwym momencie

I co dla mnie jest chyba zawsze myślą przewodnią to to, że większość projektantów tworzy dobre ale skomplikowane rozwiązania. Naprawdę dobrego projektanta poznaje się po tym, że jego rozwiązanie jest nie tylko dobre ale też proste.