Åš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
Post a Comment