Skocz do linków, Skocz do treści

Troll zwany ROI i user experience

29 lipca 2010 13:10. Autor: Robert Drózd. Komentarze (2) »

Troll zwany ROI

Louis Rosenfeld powiedział kilka lat temu: „Myślę, że największym wyzwaniem dla każdego, kto cokolwiek projektuje jest uzasadnienie kosztów jego pracy. Pod każdym mostem czai się wielki, owłosiony, paskudny troll, a imię jego jest ROI.”

O tak. Temat przewija się bardzo często, gdy rozmawiam z kimś „spoza branży” o użyteczności. No dobrze, ale czy są jakieś dowody, że inwestycja w UX się opłaci? Pokażesz jakieś liczby? Gdzie jest ROI?

Kupiłem jakiś czas temu książkę „Selling Usability”. Poświęcona temu jak sprzedawać użyteczność klientom – przede wszystkim wewnętrznym. Co na przykład robić, gdy jesteśmy jedynymi ludźmi od UX w firmie? Jaki ma być cel naszych działań, bo przecież samemu nie da się zrobić wszystkiego?

Otóż według tej książki, naszym celem jest (w ostatecznym rozrachunku) uzasadnienie potrzeby naszego istnienia. :-) Co jest postawieniem całej sprawy na głowie.

Nikt nie każe uzasadniać jakie będzie ROI z tego, że w jakiejś firmie jest pani z pionu socjalnego, która rozdaje bilety i karty na basen. Albo jakie jest ROI z tego, że w recepcji nie jest brudno? „Przez posprzątanie recepcji i wymianę żarówek sprzedaż wzrosła o 30%”. Już widzę takie komunikaty.

Tak samo trudno byłoby się wytłumaczyć działowi marketingu. Formy promocji nastawione na branding, albo działania PR dają się mierzyć jedynie pośrednio. Da się to mierzyć wielkością nakładu (wzrost nakładów na UX o 100% spowodował wzrost przychodów o 30% itd.), ale gdzie właściwie tutaj zarabiamy?

Od wielu lat powtarzam, że w użyteczności serwisów są dwa podstawowe elementy: twarda i miękka użyteczność.

„Twarda użyteczność”

To są po prostu błędy krytyczne. Zrobisz coś, a miasto wyleci w powietrze, dane w formularzu się skasują, a sklep powie, że nie ma towaru, jakiego szukasz – choć towar w bazie jest.

Twarda użyteczność nie ma swojego aspektu pozytywnego. Dbamy tylko o to, aby klient nam się nie pogubił. Zadaniem badania użyteczności jest wychwycenie błędów i ich poprawienie.

Badanie twardej użyteczności jest pod względem swojego celu trochę podobne do testów oprogramowania, które sprawdzają czy system działa prawidłowo i się nie wywala po podaniu złych danych. Podstawową różnicą jest to, że użyteczności nie da się najczęściej zbadać automatycznie.

I tu rzeczywiście inwestycja w poprawę usability się opłaci – choć w stopniu ograniczonym przez „zapuszczenie” serwisu czyli jego obecny stan. Wyobraźmy sobie serwis bez krytycznych błędów, którego wydajność wynosi 100%. Sto procent użytkowników, którzy chcą zrealizować zadanie wykona to zadanie. Błędy sprawiają, że serwis ma wskaźnik 70%. No i badanie użyteczności pozwala nam na poprawienie się z 70% na 90%. To się przełoży na zarobki, ale ROI będzie dramatycznie różne dla różnych serwisów. Pamiętajmy, że poprawiając błędy krytyczne nigdy nie przekroczymy potencjału serwisu określonego jako 100%! Aby ocenić jakie uzyskamy ROI z poprawy użyteczności, to …serwis trzeba najpierw zbadać, choćby przez prostą analizę ekspercką.

„Miękka użyteczność”

Im bardziej z błędów przechodzimy do poprawy user experience, tym bardziej bagnista ścieżka, ale tym więcej możliwości skrótów. Mamy szczęście mogąc to przetestować. Zapuścimy test A/B i już wiemy, że niebieski kolor przycisku jest bardziej zauważalny, a tym samym o 2% skuteczniejszy w przyciąganiu klientów niż zielony.

Ale często tego przetestować się nie da.

  • Jaki jest wpływ długości pola wyszukiwarki, które ma 40 znaków zamiast 20? Mówię: z logów wynika, że 20% klientów wpisuje zapytania dłuższe niż 20 znaków i nie widzą całego zapytania na raz, co prowadzi do literówek i zdenerwowania. Błąd kosmetyczny. Jedna gwiazdka w raporcie. Czy warto do tego robić testy? I jaki wybrać wskaźnik sukcesu?
  • Jaki jest wpływ tego, że opis produktu czytasz z góry na dół w logicznie ustalonym porządku, a nie musisz biegać oczami we wszystkie strony? To są dziesiątki pojedynczych zmiennych, które są ze sobą powiązane i trudno wyizolować pojedynczy warunek.
  • Szalenie trudno będzie np. sprawdzić wpływ user experience na stopień powracalności klientów. Test wielowymiarowy z powrotem na stronę, jako konwersją? Nie wiem kto ma czas na takie zabawy. Patrzymy w statystyki, jak rozkłada się trend powracających (pomaga też analiza lojalności) i szukamy wniosków na podstawie tego co się zmieniło w serwisie i jego komunikacji. Ale ew. decyzji nie uzasadnimy liczbowo.

Kraina, gdzie już nie ma użyteczności

Gdy ktoś pyta o ROI, to często tak naprawdę użyteczność go nie interesuje. Optymalizacja sprzedaży to kwestia oferty, jej prezentacji, copywritingu, procesu perswazji. Nijak nie będzie to związane z użytecznością rozumianą jako miarę efektywności i wydajności w wykonaniu zadania. A co z ogólniej rozumianym user experience? Moje doświadczenie ze sklepem X i Y jest równie dobre, ale kupuję w Y, bo Y ma lepszą ofertę.

Dlatego jeśli ktoś pyta o ROI i tego typu wskaźniki w odniesieniu do user experience, należy przede wszystkim zapytać, co ma na myśli. Bo może wcale nie potrzebuje specjalisty od użyteczności, a specjalisty od marketingu.

W uzupełnieniu:

Podobne artykuły:

Być może zainteresują Cię następujące artykuły:

Zapisz się na kanał RSS bloga i dołącz do ponad 1500 czytelników RSS.

Zostań fanem WebAudit na Facebooku.

Komentarze czytelników

Śledź komentarze do tego artykułu: format RSS
  1. Łukasz Plutecki

    Dużo fajniej użyteczność sprzedaje sie w serwisach typu e-commerce. Tam często poprawa użyteczności, eliminacja błędów skutkuje efektami w postaci wzrostu sprzedaży, konwersji itd.

    Użyteczność e-commerce-ów wymaga jednak od konsultanta ‚czucia’ branży, wiedzy z zakresu handlu internetowego, marketingu i merchandisingu.

Komentarze z innych blogów

  1. Netface – Lepsze oblicze sieci» Archiwum blogu » Po co zwiększać usability na stronach internetowych?

    […] stronie http://www.webaudit.pl/blog/2010/troll-zwany-roi-i-user-experience/ znajduje się ciekawy podział na „twardą” i „miękką użyteczność”. […]

Zostaw komentarz

W komentarzu można (choć nie trzeba) używać podstawowych znaczników XHTML. Komentarze zawierające w podpisie słowa kluczowe mogą zostać potraktowane jako spam i usunięte.