Skróciak: kontynuuję serię artykułów o pracy z potrzebami użytkownika (user needs) wg. modelu GDS. Dzisiaj będzie o tym, dlaczego ważne jest projektowanie z jednoczesnym używaniem mózgu zorientowanego na próbę zrozumienia, o co chodzi i końcowemu użytkownikowi, i biznesowi – a nie tylko użytkownikowi.
Jeżeli spojrzysz na to, jak w GDS piszą o swoich wygibasach, zauważysz jeden ciekawy cytat:
„Start with needs – user needs not government needs” („Zacznij od zbadania potrzeb – potrzeb użytkownika, nie rządu.”)
Kij w mrowisko: wielokrotnie na pewno spotkałeś się z twierdzeniem obecnym od dawna w świecie UX, które mówi, że powinniśmy zawsze tworzyć rozwiązania tak, by za wszelką cenę spełnić wymagania użytkownika. Sentencja powyżej zdaje się komunikować to samo. Wielu „świeżych” projektantów czyni z tego stwierdzenia broń, zasłaniając się nim i argumentując decyzje, które każą biznesowi wkraczać w tereny ekstremalnego kompromisu. Niestety, cudów nie ma, a my nie powinniśmy być upartymi osłami. Założenie sobie klapek na oczy i ignorowanie potrzeb biznesu doprowadzi do frustracji klienta. Powodów może być kilka:
- Klient może mieć jasno zdefiniowane KPI (key performance indicators – zestaw metryczny, za pomocą którego będzie mierzył wydajność budowanego systemu). Często takie KPI nakładane są przez instytucje rządowe i po prostu muszą być spełnione, nawet, jeśli nie mają wiele sensu. Można to kwestionować, ale rzeczywistość pokaże Ci, że nie wygrasz.
- W organizacji klienta może panować upolityczniona atmosfera, czyli tzw. lizanie pup i głaskanie po główce wewnątrz siatki mocno szemranych zależności; to też będzie ciężko Ci przeskoczyć. Można (i o tym kiedyś napiszę) starać się, ale przygotuj się na trudności, czasem bardzo niemiłe.
- Przekonanie klienta o tym, że pozjadał wszystkie rozumy. A Tobie może zależeć na tym, by wykonać na przykład jeden jeszcze projekt i z tego powodu strategicznie myśląc nie marudzić.
- Do spełnienia są finansowe cele, które wychodzą poza ramy projektu (często w połączeniu z pierwszym punktem). Przykładem może być praca dla organizacji, która otrzymuje społeczne finansowanie i wymaga uwierzytelnienia wydatków, czego dowodem powinien być projekt spełniający założenia inwestorów.
Śmierdzący świat, wiem. Ale zaraz, chwileczkę – czy to czasem nie brzmi zbyt negatywnie i, czy ja nie próbuję Ci powiedzieć, żebyś nie przejmował się potrzebami użytkownika, negując niejako założenia GDS?
Choć może się tak wydawać, to wcale nie. Albowiem pełna wersja cytatu powinna zostać rozbudowana do:
„Zacznij od badania potrzeb użytkownika, ale weź pod uwagę potrzeby biznesu. Spraw tak, żeby rozumienie jednych i drugich doprowadziło do rozwiązania, które spełnia oba rodzaje zapotrzebowania.”
Dobrym przykładem dla zilustrowania tego zdania może być to, co projektanci GOV.UK poczynili z tzw. accessibility statement, lub raczej dlaczego z niego zrezygnowali. Obecny na prawie każdej rządowej stronie z biurokratycznego i poprawnego politycznie piekłaaccessibility statement informuje często obywateli UK o narzędziach wspomagających dostępność, jakich powinni używać, o kompatybilności z różnymi technikami (na przykład, ARIA) i mówi „och, jacy my jesteśmy mega – wspieramy tych, co dostęp mają utrudniony”. Cały trick polega jednak na tym, że takie deklaracje można roztrzaskać o kant czterech liter. Jest tak ze względu na to, że niepełnosprawni użytkownicy internetu po prostu wiedzą, jak go używać, a techniki dostępności są na tyle zunifikowane, że nie ma sensu opisywać ich po raz pięćsetny. W efekcie accessibility statements to nic innego jak zawalające witryny internetowe strony bez żadnej znamiennej treści.
Jednakże GOV.UK dostępne być musi – jak każda dobra strona – i tym samym wypełnić jedną z design principles o projektowaniu w sposób przystępny i użyteczny dla wszystkich. Co więc zrobiła drużyna GDS? Po prostu: zaprojektowała stronę, która jest dostępna z definicji. Semantycznie poprawna, odpowiednio wyposażona w ARIA, logicznie poukładana i wizualnie przejrzysta. Z dobrze napisaną treścią. Voila. Potrzeba użytkownika: spełniona. Wszystko działa. Potrzeba organizacji: spełniona. Jedni i drudzy zadowoleni, bez nadmiernego obciążenia. I lania wody bez sensu.
Co zrobiłby projektant-dupa słysząc o tym, że jego klient potrzebuje deklaracji na temat dostępności? Zamontowałby taką na stronie i cieszył się, że spełnił oczekiwania użytkowników i klienta. Pomimo deklaracji strona mogłaby na zawsze pozostać niedostępna jak Wanda, co nie chciała Niemca, ale klient cieszyłby się wypełnieniem swojego założenia. Tak się nie robi.
Mądry mógłby włożyć teraz kij w oko mnie, bo nie trudno doszukać się projektów, w których maczałem palce, co to ani dostępne nie są, ani nie przestrzegają powyższej reguły, świecąc na lewo i prawo accessibility statements. Proszę pamiętać jednak o tym, że często to, co wychodzi z fabryki a to, co mamy przed oczami po tym, jak palce zamoczy w zupie drużyna kliencka to niestety dwie różne rzeczy. Powyższy przykład dobrze jednak ilustruje zagadnienie.
Jak zrozumieć potrzeby użytkowników? Do tego powinieneś zaangażować się w badania dwojakiego rodzaju: jakościowe i ilościowe. Chociaż tak naprawdę, to w tym przypadku obydwa badania są bardziej jakościowe niż ilościowe. Pierwszym ich rodzajem jest rozmowa, obserwacja i wnioskowanie na podstawie tychże. Przeprowadzać badania powinieneś i z klientem (próbując zrozumieć, jakie ma cele i co wie o swojej grupie docelowej) i, z użytkownikiem końcowym.
Badania „ilościowe” w tym wypadku sprowadzają się głównie do mądrej analizy dostępnych danych dostępu do systemu (lub podobnych systemów). Często oznacza to grzebanie w Google Analytics, WebTrends, Omniture czy podobnych.
I o tych dwóch metodach będzie więcej w następnym odcinku. Pewnie w przyszłym tygodniu.
Dodaj komentarz