Świat przyspiesza. Ktoś nawet wykonał badania, z których wynika, że ludzie w wielkich miastach chodzą ulicami szybciej niż 10 czy 15 lat temu. Pośpiech jest dobrze znany branży interaktywnej, w przypadku której oczekiwanie klienta, iż agencja pracować będzie w weekend i wieczorami, nie należy niestety do rzadkości. Kolejnym z objawów jest dążenie do dostarczenia produktu interaktywnego szybciej niż konkurencja, co akurat nie dziwi. Moim zamiarem nie jest jednak snucie rozważań nad czasem, ale przyjrzenie się niedostatkom procesu projektowania zorientowanego na użytkownika – UCD (ang. User-Centered Design). Chodzi między innymi o wpływ na czas wytwarzania, ale nie tylko.
Swego czasu Tomek Bienias polecił na Goldenline artykuł o prowokacyjnym tytule Getting to the customer – why everything you think about User Centered Design is wrong. Szczerze mówiąc, treść niespecjalnie mnie porusza, warto jednak wymienić kilka celnych uwag. Piszę o tym z pewnym opóźnieniem – do podjęcia tematu skłoniła mnie lektura kilku innych tekstów (zobacz listę źródeł na końcu notki). Oto wybrane kwestie.
Pierwsza zasada: wydawaj wcześnie i często
…po angielsku – release early and release often. Innymi słowy, hasło-klucz ery internetu w wersji beta. Eric Ries stawia sprawę jasno – lepiej popełnić „błąd biznesowy” – publikując wczesną wersję serwisu, niż przechodzić przez wieloiteracyjny proces projektowania.
Wypuszczając nawet niedoskonały serwis, jesteśmy w stanie bardzo szybko uzyskać reakcję potencjalnych odbiorców i zorientować się, czy projekt ma sens od strony biznesowej. Ries przytacza przykład strony docelowej (landing page), zapowiadającej dany produkt i zawierającej odnośniki do informacji o tymże produkcie – w które to odnośniki nikt nie kliknął. Miałoby to być przyczynkiem do stwierdzenia, że czas zwijać żagle, bo interes nie ma szans wypalić. Gdyby ta sama strona była przedmiotem testów, projektanci staraliby się wprowadzić zmiany, zamiast z miejsca zrezygnować z projektu w ogóle. Szybciej i w domyśle – taniej – przetestować na żywo i podjąć zdecydowane decyzje.
Każdy projekt interaktywny powinien być zatem doprowadzany do stanu „minimalnego produktu zdolnego do życia” (minimum viable produt, mvp). Produkt takowy powinien zawierać tylko te funkcjonalności, które odpowiadają na problem klienta – i nic więcej. Ma to pozwolić na ocenę, czy efekt naszej pracy sprawdził się na rynku w możliwie najwcześniejszej fazie.
Przyznam, że rozumowanie to wydaje mi się odrobinę dziwaczne i niepozbawione dziur. Diagnozowanie problemu ogranicza się do stwierdzenia symptomów choroby, bez dociekania przyczyn. Wszystko pięknie, jeżeli z dużą dozą prawdopodobieństwa jesteśmy w stanie stwierdzić, że powód niepowodzenia tkwi w samym produkcie. Rozstrzygnięcia z pewnością nie przynoszą proste statystyki klikalności. Tu dochodzimy do zasady drugiej.
Korzyść dla użytkownika miarą sukcesu biznesowego
Kura czy jajo? Czy projekt może być efektywny biznesowo bez bycia „pożądanym” przez odbiorców? Czy wystarczy produkt minimalnie oczekiwany (Minimum Desirable Product), aby osiągnąć sukces biznesowy? Pytania niemal retoryczne, jednak biorąc pod uwagę podejście Minimum Viable Product, zorientowane na szybką ewaluację efektywności biznesowej, być może wymagające jasnej odpowiedzi.
Minimum Desirable Product (zobacz źródła) to doświadczenie produktu wystarczające do stwierdzenia, jaką wartość ów produkt przynosi użytkownikom. Do zbudowania MDP nie może wystarczyć pojedynczy landing page, nie wystarczy także zliczać statystyki ruchu do stwierdzenia, że czy używanie serwisu przynosi rzeczywistą korzyść użytkownikom. Andrew Chan proponuje zastosowanie miar zorientowanych na korzyści (benefit-driven metrics). W przeciwieństwie do tradycyjnych pomiarów konwersji, powinniśmy skupić się na stwierdzeniu, czy produkt realizuje cele użytkowników. Jeżeli zbudowaliśmy serwis randkowy, pytanie brzmi, czy udało się doprowadzić do pożądanego przez użytkowników efektu (nie pytajcie proszę, na której randce).
A więc MVP kontra MDP. Produkt pożądany kontra zwrot z inwestycji, sztuka (copyright by Rafał Agnieszczak) vs biznes. Wydawałoby się oczywiste, że jedno nie istnieje bez drugiego, pytanie tylko o kolejność. Minimalnie biznesowo zdolny do oceny projekt niekoniecznie zaakceptowany zostanie przez grupę docelową, choć jest to stan wystarczający do dokonania takiej oceny. Z drugiej strony, projekt, którego wartość dla użytkownika można sprawdzić, ma szansę stać się przebojem rynkowym. Czy ktos ma wątpliwości, że należy zeswatać tę parę? Jak doprowadzić do szczęśliwego małżeństwa?
UCD i agile
User-Centered Design (UCD) zakłada zaangażowanie użytkowników do do wypracowania wizji projektu. Zdaniem autora artykułu „Getting to the customer – why everything you think about User Centred Design is wrong”, UCD jest podejściem zbyt abstrakcyjnym, mało uwagi poświęca praktycznej realizacji projektów. Inna wada to eksportowanie odpowiedzialności przez zleceniodawców. Na pewno duża część praktyków zetknęła się z problemem zatrudnienia zespołu badawczego dla usprawiedliwienia określonych decyzji biznesowych i projektowych. Zbyt często zdarza się, że nasze raporty są wykorzystywane jako przysłowiowa „podkładka” – przecież przestestowaliśmy prototyp, więc problem mają koledzy po drugiej stronie budynku…
Wreszcie, zarzut najpoważniejszy: użytkownicy – uczestnicy badań w procesie UCD – to nie klienci. Użytkownik to twór statystyczny, który wedle Jacoba Nielsena nie przewija stron, na co z pewnością autor badań ma liczne dowody (Grzegorz, czytasz to?). Klient z drugiej strony, to ktoś, kto wybrał Twój produkt i jest zdeterminowany dostatecznie do przewijania wbrew wszelkim regułom, choćby ekran był zaprojektowany nie do końca właściwie.
Jakie miałoby być lekarstwo? Co zapewni, że użytkownicy staną się rzeczywistymi klientami, dostarczającymi wartościowych informacji zwrotnych, zanim biznes skonsumuje budżet? Stajemy przed koniecznością sprawnego i efektywnego kosztowo wytworzenia produktu dobrze dopasowanego do potrzeb użytkowników. Odpowiedzią, której osobiście szukam, jest skuteczne połączenie metodyki UCD z filozofią agile – podejścia strategicznego z taktyką realizacji. Od nowego roku zaplanowałem spotkania z praktykami Scrum, zobaczymy, co z tego wyjdzie…
Źródła
- Sensowna krytyka UCD – dyskusja w grupie na Goldenline.pl
- Minimum Desirable Product
- Venture Hacks interview: „What is the minimum viable product?”
- Benefit-Driven Metrics: Measure the lives you save, not the life preservers you sell
- How UCD and Agile can live together
- Getting to the customer – why everything you think about User Centred Design is wrong