Godzenie potrzeb użytkownika i biznesu to nie łatwizna. Z pewnością przekonał się o tym każdy, kto kiedykolwiek odbył spotkanie z zarządem lub klientem. Nie wspomnę już o IT. Ciągle tylko kłody pod nogi... 😝

Niedawno ktoś zapytał mnie,  jak radzę sobie, gdy na spotkaniu okazuje się że, cała koncepcja idzie do wyrzucenia? – Zamykam się w sobie i wracam do biurka – odpowiedziałem pół żartem, pół serio.

Pół serio – bo przez bardzo długi czas z trudem przychodziło mi uzasadnianie decyzji projektowych, powołując się nawet na badania i dobre praktyki - często kwestionowane przez klientów. Pół żartem – bo po wielu bataliach udało mi się wypracować taki model projektowy, który z założenia godzi potrzeby i biznesu, i użytkownika.

User Centered Design -  fajnie, ale...

Koncepcja User Centered Design z oczywistych względów od lat cieszy się popularnością i uznaniem wśród projektantów. Osobiście uważam, że badania jakościowe są jednymi z najciekawszych narzędzi w pracy projektanta UX. Po pierwsze, pozwalają obcować z realnymi użytkownikami naszych projektów, a także obserwować ich emocje i doświadczenia. Po drugie, wskazują nam problemy, na które sami w życiu byśmy nie wpadli. To naprawdę zadziwiające, w jaki sposób i do jakich celów ludzie wykorzystują nasze produkty...

Niestety, obserwacje użytkowników i wywiady bardzo często są kwestionowane i raczej nie stanowią samodzielnej podstawy do inwestycji czasu i pieniędzy w development.  Są one obarczone błędem metodologicznym i bardzo trudno powtarzalne.

– Co mi po odpowiedziach sześciu użytkowników na krzyż? – To realna wątpliwość i retoryka, z którą spotkałem się na jednym ze spotkań z klientem. I mimo że jest dość brutalna, po głębszym namyśle trudno nie przyznać jej racji.

Biznes lubi liczby

Decyzje projektowe często wiążą się z ryzykiem biznesu - utraty zainwestowanych pieniędzy lub innych zasobów (np. czasu i pracy). Istnieje ono bez względu na to, czy tworzymy produkt od zera, czy też go modyfikujemy. To z kolei bezpośrednio przekłada się na odpowiedzialność osób, które takie decyzje podejmują. Dlatego też tabelki, wykresy i liczby to fundament każdej współczesnej organizacji i inwestycji. Ustandaryzowane, mierzalne, powtarzalne, weryfikowalne i bezpośrednio przekładające się na zasoby – idealne (?)

Zjawisko to odzwierciedla rosnąca popularność metodologii Data Driven Design, polegającej na uzasadnianiu i weryfikacji decyzji projektowych w oparciu o dane ilościowe.

Konwersja, współczynnik odrzuceń, klikalność, NPS, ruch i analiza porównawcza to obecnie najbardziej podstawowy zestaw metodologiczny, z którym każdy projektant powinien się zaprzyjaźnić.

Data Driven na sterydach

Zarówno User Centered, jak i Data Driven Design mają niewątpliwie swoje zalety i wady. Pierwsza metoda, skupia się głównie na produkcie i użytkownikach, nie do końca zaznaczając potrzeby biznesu. Natomiast druga działa dokładnie odwrotnie.

Kompromisowym rozwiązaniem wydaje się zatem połączenie obu modeli w jeden, który uwzględni jednocześnie potrzeby obu grup w oparciu o dwa typu informacji – ilościowe i jakościowe, a dodatkowo generować będzie dane do kolejnych analiz i rozwoju w formie testów A/B/X. Nie da się? Spróbujmy!

Na mobajlu trochę słabo widać. Użyj palców by przybliżyć, lub skorzystaj z wersji do pobrania na dole :)

W zaproponowanym modelu badania ilościowe (Quantitative) i jakościowe (Qualitative) mogą się wzajemnie uzupełniać. Ilościowe – identyfikują problem, jakościowe zaś, wykazują jego przyczynę. Ta z kolei zostaje rozdzielona według możliwości optymalizacji.

W kolejnym kroku (Desired effect) wyartykułowane zostają cele użytkownika i biznesu, a także kryteria akceptacji (Acceptance criteria), które następnie przekształcone zostają w unikalne rozwiązania (A i B). Wersje A i B z góry przewidują, że otrzymamy dane, które będziemy w stanie później zweryfikować i dzięki nim wybrać bardziej skuteczne rozwiązanie.

W ostatnim etapie wskazujemy sposób weryfikacji i porównaniawyników między wersjami oraz wobec stanu początkowego (How do we know that). Mogą to być dane z testów A/B, ponowne przeprowadzenie badań z sekcji "How do we know that" lub inne. W każdym razie, po wdrożeniu będziemy w stanie zweryfikować projekty według klucza, który już mamy.

Sama konieczność wdrożenia lub zmian w powyższym modelu jest zasadna tylko wtedy, gdy problem (Issue or change request) jest potwierdzony danymi lub dane wykazały problem, a przyczyna jest możliwa do optymalizacji. Reguła ta jest o tyle przydatna że, narzuca pewien model w komunikacji między uczestnikami projektu, gdzie wszyscy są w stanie zrozumieć czym uzasadnione są zmiany, lub czemu zostały odrzucone.

Czy warto się bawić w Canvasy?

Canvas to w rozumieniu UX i IT modele prac lub zbiory intencji potrzebnych do skutecznego zrealizowania projektu. Istnieje ich wiele – od tych wykorzystywanych w Scrumie, aż po biznesplany czy Value Management.

Spotkałem się z wieloma podejściami dotyczącymi wykorzystywania takich modeli w codziennej pracy. Niektórzy twierdzą, że wypełnianie pól i naklejanie posttipów na ścianę jest tylko dziecinną stratą czasu. W naszym przypadku modele/canvasy są jednak o tyle pomocne, że wprowadzają określony porządek prac, czynności i kierują naszą uwagę na określone problemy, które należy wziąć pod uwagę dla dobra produktu.

Ponadto ich niewątpliwą zaletą jest to, że z punktu widzenia pracy nad projektem stanowią podstawowy plan działań, który należy wykonać, żeby w ogóle rozpocząć pracę. Dodatkowo są łatwo konwertowalne do kart inicjatyw, specyfikacji technicznych, a nawet do uzasadniania decyzji projektowych na spotkaniach z klientem.

Czy warto? Moim zdaniem tak. Bez względu na to, jaki model wybierzemy, znacznie ułatwią nam życie, uzasadnią decyzje i zaprowadzą porządek w strukturalnym chaosie organizacyjnym.

Do pobrania - Pay with Tweet  😊