„Mam świetny pomysł…” – specyfika projektów z dużym ładunkiem kreatywnym
Tags: buzzword, user experience
Czym charakteryzują się projekty informatyczne z dużym ładunkiem twórczym? Po pierwsze, jak można spodziewać się po projektach, w których udział bierze grupa osób kreatywnych, wszyscy mają świetne pomysły, jak przełomową nowość dostarczyć użytkownikowi. Po drugie – nikt tak na prawdę nie wie, które pomysły są dobre. Problemem staje się nie skąd je wziąć, a „które i jak wybrać”.
Niestety często okazuje się, że osoby kreatywne i/lub interesariusze nie zauważają drugiej części problemu. Istnienie pomysłu oznacza, że rozwiązanie zostało znalezione, teraz trzeba je już tylko wdrożyć. Nic bardziej mylnego. Wygląda na to, że zajść musi przełom w myśleniu, by na projektowanie user experience zaczęto patrzeć poważniej niż jak na kolejny buzzword – a warto, o czym świadczą sukcesy marek takich jak Apple, Research in Motion czy Google.
A narzędzi pozwalających na rzetelne podejście do innowacji user experience jest sporo. Z pomocą przychodzą metody projektowania interakcji kładące nacisk na poznanie użytkowników wraz z ich kontekstem psychosocjologiczny: bagażem doświadczeń, umiejętności, modeli mentalnych[i] - jak na przykład Goal-Directed Design promowane przez Alana Coopera, jednego z czołowych ekspertów (i wieloletniego praktyka) tej dyscypliny. Metody te oferują rygorystyczne podejście do chaotycznego z natury procesu kreacji[1], pozwalając na zrozumienie użytkownika, dając większą szansę dostarczenia czegoś, co będzie dla niego wartością.
Rzetelne podejście do projektowania user experience rozwiązuje dużą część problemów związanych z oddzieleniem pomysłów „dobrych” od „jakichkolwiek”. Ale interaktywna natura produktów cyfrowych oznacza, że nie można być pewnym czy spełnia on cele użytkownika, dopóki ten nie wejdzie z nim w interakcję. Właśnie dlatego skuteczna ewaluacja produktów informatycznych wcale nie jest tak prosta, a wszelkie metody polegające na wyrażaniu opinii o rysunkach koncepcyjnych czy zrzutach ekranu (na przykład focus grupy) są niespecjalnie rzetelnym narzędziem jeśli chodzi o ocenę projektu interakcji.
Kwestia weryfikacji jest jednak fundamentalna dla dostarczenia czegoś, co będzie wartością, zwłaszcza innowacyjną, dla użytkownika – inaczej tylko zgadujemy, że tak będzie. Branża gier komputerowych (a więc produktów, które są wydestylowanym user experience) rozumie to dobrze – żadne szanujące się studio nie obejdzie się bez tzw. playtestów – weryfikacji „fajności” gry wykonywanej na interaktywnych prototypach. Narzucać się tu może skojarzenie z badaniami użyteczności. Rzeczywiście, w wyniku testów grywalności czasem odkrywa się problemy dotyczące użyteczności, ale nie jest to ich głównym celem: one mają pokazać, czy i dlaczego testowany materiał jest dla graczy fajny – badane jest więc czyste user experience! Silne zorientowanie na weryfikację wynika z faktu, że żaden szanujący się projektant gier nie orzeknie autorytatywnie, czy coś będzie ciekawe dla wszystkich, czy nawet większości graczy, bo wie, że grę projektował w oparciu tylko o własny punkt widzenia. Wydaje się, że takiego podejścia brakuje w innych branżach informatycznych – w końcu przeważająca większość produktów jest używana przez ludzi. Od tego jak dobrze spełniają cele swoich użytkowników zależy ich sukces.
Oczywiście w myśleniu „zobaczmy co myśli użytkownik, a potem się zdecydujemy” istnieją też pułapki. Alan Cooper zauważył[ii], że posunięte do ekstremum podejście szybkich i częstych wydań z nastawieniem na permanentną beta-wersję i pytanie użytkowników o zdanie „po fakcie” może sprawić, że zarówno biznes jak i klienci tracą. Biznes, bo wymagający użytkownicy widząc produkt nie spełniający ich oczekiwań szybko przejdą do konkurencji. A wszyscy inni zostaną po prostu z kiepską usługą. Wymyślanie produktów przez marketing czy managerów nie znających drugiej strony barykady to kolejna pułapka – argumentem często jest, że przecież „nikt nie może uważać, że wie czego chcą użytkownicy”. A właśnie rygorystyczne podejście do projektowania z nastawieniem na poznanie użytkownika połączone z weryfikacją kolejnych prototypów taką wiedzę, przynajmniej częściowo, daje. Ale to tematy na osobny artykuł.
Każdy „rewelacyjny i przełomowy” pomysł oraz produkt, który z niego powstał, od korporacyjnej bazy wiedzy zwiększającej produktywność pracowników po najnowszą grę komputerową, przechodzi przez ostateczną weryfikację: zderzenie z użytkownikiem. Można na to zderzenie przygotować się tak by przypominało „padnięcie sobie w objęcia”. Można też wcisnąć gaz do dechy i udawać, że nie widzi się urwiska na końcu drogi.
——————————————————————————–
[1] Pojawia się czasem wątpliwość, czy metodologia projektowania nie ograniczy przypadkiem kreatywności twórcy. Odpowiedź raczej na pewno brzmi „Nie” –, zwłaszcza w „sztuce” użytkowej. Za przykład niech posłużą architekci – mają bardzo twardo określone reguły (czasem dosłownie rozgraniczające między życiem a śmiercią wielu ludzi), a nikt nie oskarży ich raczej o brak kreatywności
——————————————————————————–
[i] Goodwin, K., (2009) Designing for the Digital Age: How to Create Human-Centered Products and Services, Wiley Publishing, Inc., Indianapolis
[ii] http://www.cooper.com/journal/2001/01/the_iteration_trap.html

(7 votes, average: 4.43 out of 5)
Drukuj
Poleć znajomemu

Październik 27th, 2009 at 9:02 am
Świetny artykuł, kwintesencja moim zdaniem jest przedostatni akapit, w tym szczególnie: “posunięte do ekstremum podejście szybkich i częstych wydań z nastawieniem na permanentną beta-wersję i pytanie użytkowników o zdanie „po fakcie” może sprawić, że zarówno biznes jak i klienci tracą”, to w moich oczach porażka metod prototypowych, XP czy źle pojętego Agile… to metody uznające brak kompetencji analitycznych zespołu programistów i szukanie rozwiązania metoda prób i błędów, po drugie użytkownik raczej nigdy nie wymyśli czegoś czego do tej pory już nie używał a analiza wymagań i projektowanie operacje na user story to prosta droga do zamrożenia zastanej sytuacji..
Niezależnie od metodyki analizy, jeśli tylko pozwala ona “wyciągnąć” z zamawiającego prawdziwą wiedze o jego działaniach i ich celowości, nieskażona subiektywizmem pszczególnych, broniących swoich pozycji, pracowników, to krok w stronę dobrych i innowacyjnych projektów oprogramowania.
Październik 28th, 2009 at 9:43 am
W moim przekonaniu najważniejsze z punktu widzenia dobroci produktu dla użytkownika są dwie rzeczy:
1) solidne zrozumienie, czego mu tak naprawdę potrzeba
2) ciągła weryfikacja, czy to co powstaje rzeczywiście te potrzeby adresuje
W związku z powyższym absolutnie zgadzam się z drugim akapitem komentarza:) Trzeba pamiętać jednak o dwóch rzeczach: “zamawiający” to często nie użytkownik końcowy i o ile jego cele i motywacje są ważne (w końcu to pracodawca), o tyle to użytkownicy końcowi zadecydują o powodzeniu produktu. Trzeba więc umieć poznać i klienta i użytkownika. Aby zrobić to rzetelnie często trzeba wyjść poza deklaracje - istotne są też modele mentalne, przyzwyczajenia, motywacje, opinie, frustracje itd. czyli rzeczy do których poznania często tradycyjni analitycy informatyczni nie są przygotowani, a do badania których mają narzędzia na przykład psychologowie (popularne w kontekście projektowania interakcji są metody eksploracyjne jak wywiady pogłębione). Kluczowa jest też rzetelna metoda opracowywania wyników takich “badań terenowych”. Moim zdaniem aby zrozumienie użytkownika wykonać rzetelnie trzeba na temat spojrzeć bardziej interdyscyplinarnie.
Co do metod “zwinnych” to zgadzam się - źle pojęte prowadzą do testowania i ulepszana rozwiązań, które od początku są niedoskonałe. Ale moim zdaniem nie oznaczają one zespołów nisko wykwalifikowanych - wręcz przeciwnie (”luźny” proces wymaga więcej doświadczenia i dyscypliny jednostki) a podejście prototypowe uważam za kluczowe dla wspomnianej w punkcie 2) weryfikacji. Podejście nastawione na sprawdzania, czy to co robimy na pewno jest dobre jest kluczowe dla zapewnienia dobrego “kursu” projektu przez cały czas jego trwania. Ale tylko pod warunkiem, że od początku oparty jest o solidne fundamenty poznania dziedziny, użytkownika i klienta. Inaczej będzie to kręcenie się w kółko o którym piszesz.
Grudzień 17th, 2009 at 5:16 pm
zmieńcie czcionke i line-height w stylach CSS na większy… przeczytałęm pierwszy akapit i dalej juz mnie to zniecheciło ;]