Tebe Gada - Projektowanie i produkcja produktów
Menu

Tebe Gada

Projektowanie i produkcja produktów

Efekty pracy adeptów sztuki UX

tebe

Mam takie zawodowe hobby: lubię w produktach oglądać efekty pracy "projektantów UX". Bawi mnie to wielce, nawet w czasie wolnym. Pracuję z UXami, zajmuję się produktami i wszystko to jakoś ładnie się spina. Oglądam coś w sieci i wtedy kojarzę teorię albo przykłady z blogów czy "UX Magazine", na których opierali się twórcy. (Designerzy, zwłaszcza w Google też potrafią dać czadu, ale to inna historia)

Dziś na Deezerze miło przywitał mnie taki obrazek:

ux_praktyce

Teoria mówi, że użytkownika należy przywitać miłym słowem. Zwrócić się do niego osobiście, wtedy się lepiej poczuje i będzie miał z danym serwisem skojarzenie pozytywne. Sztuka to sensownie zaimplementować, bo ludzie są różni i różnie na komunikaty reagują - zwłaszcza jeśli interfejs wdraża się w różnych kulturach. Inkryminowany przypadek nie jest groźny lecz zabawny. Akurat na tym serwisie jestem non stop. Czekanie na mnie od 23:50 do 8:00 wygląda na patologię. Czy mam się niepokoić, czy kogoś bolało z tęsknoty? Hej, uspokójcie się tam, jestem i nigdzie się nie wybieram. Na dodatek tych dwóch albumów ostatnio słucham dość regularnie. O tej porze dałbym się skusić na kawę, zresztą już się robi...

Oczywiście to nie jest wina specjalisty UX, który chciał dobrze. Jednak działał w pewnej abstrakcji. Wszystko się wali (oczywiście nie tu), gdy rzecz się zaimplementuje i przychodzi rzeczywistość (nawet jeśli wirtualna).

W Allegro jest kawałek interfejsu, w którym podaje się adres. Tam również zaatakowali UX-owcy. Ich działanie wpływa na wrażenie, które mamy przy korzystaniu z formularza, który użytkownika atakuje dość agresywnie. Gdy zaczyna wpisywać tam np. kod pocztowy, juz po pierwszej cyfrze pojawia się ostrzeżenie i na czerwono "krzyczy", że liczb jest za mało. Powinno to robić, niekoniecznie tak mocno (nic złego się nie stało, to jest tylko ważne) ale dopiero po wyjściu z pola, albo 2-3 sekundach bezczynności. To wydaje się oczywiste. Wiem, ze UXowcy na pewno to dobrze zaprojektowali, spieprzył "informatyk"... To tak działa już ponad rok, od zmian w serwisie. (Nie piszę o Allegro bo go nie lubię, wręcz przeciwnie - duże, ważne, używam i w wielu miejscach sensownie się zmienia).

To, że coś nie działa szczególnie sensownie, choć wymyślone zostało zgodnie z książkami i blogami, nie jest dużym problemem. Ani komunikat w Deezerze, ani nieudolny kawałek Allegro nie wygonią nikogo z serwisu. Nie powodują żadnych zysków, ani większych kosztów. Gorzej, gdy podążanie za podręcznikiem pociąga za sobą spory koszt a nie tworzy żadnej wartości. W książce Lean Startup jest opisany przykład, który to świetnie ilustruje. W Startupie Grockit designerzy zaproponowali i doprowadzili do wdrożenia "lazy registration", zgodnie z obowiązującą w tym czasie modą. Dzięki niej użytkownicy mogli w pełni korzystać z serwisu zanim zdecydowali się w nim zarejestrować. Ta możliwośc była dość droga w implementacji i co ważne - w utrzymaniu (to zespół działań występujących w czasie, kiedy goście z UX pracują już przy innym serwisie, a Ty produkcie się martw). Autor książki zachęcił zespół Grockita do przeprowadzenia testu na dwóch grupach - korzystającej z tej formy rejestracji oraz zmuszanej w sposób tradycyjny do założenia konta. Okazało się, że to "lazy" nie miało żadnego wpływu na skuteczność pozyskiwania użytkowników i równie dobrze można było tego nie robić.

W każdym fachu mamy poziom "amator" i "specjalista". Mistrzowie UX to nie są osoby, które przeczytały najwięcej książek. To nie są nawet ci, którzy robią najlepsze makiety i prezentacje. To ci, którzy mają też wystarczająco dużo rozumu i doświadczenia by przewidzieć w praktyce skutki swoich pomysłów. Takie "Michałki" wychodzą dziś dość często, ponieważ jesteśmy na wczesnym etapie rozwoju specjalizacji. To też kolejny dowód na to, jak bardzo praktyka odbiega od teorii. Nie daje mi spokoju zdanie z komentarza do poprzedniego wpisu: w praktyce teoria o od praktyki różni się bardziej niż w teorii...

BTW. Przyszedłem tu, żeby napisać o swojej ulubionej zasadzie Agile, ale Deezer był dziś wyjątkowo inspirujący. Poprawiliśmy znowu interefejs bloxa, dzięki pracy Justyny i ekipy, pisanie w nowej, testowej wersji jest jeszcze przyjemniejsze. Za każdym razem, gdy coś zmienią muszę to przetestować.

Pokochać proces

tebe

Gdy organizacja chce sprawnie tworzyć popularne produkty, potrzebuje do tego dobrych ludzi. Od pewnej liczby zatrudnionych to jednak za mało. Potrzebny jest dobry proces - powtarzalny sposób robienia rzeczy. Musi być na tyle sensowny, żeby ludzie go rozumieli i akceptowali. 

W prezentacji nt rozwoju produktów znanej, dynamicznej firmy internetowej natknąłem się na schematyczną prezentację procesu.

Wygląda tak:

proces_rozwoju_spotify

Choć jest to ładnie pokazane, widać, że ma sporo etapów, które trzeba zrozumieć, więc nie jest bardzo proste. Zaskakujący może być aktywny udział managementu w kolejnych fazach procesu.

Zawsze jest między nimi furtka - zespół, autonomiczny, samodzielny i agilowy musi uzyskać akceptację / decyzję z udziałem managementu, żeby pójść dalej.

Jak na organizację, której to dotyczy, wydaje się dość sformalizowane. Przykład jest w miarę świeży. 

Kilka lat temu prowadząc rozmowy nt. procesu prezentowałem przy różnych okazjach taki obrazek:

aol_52_product_devWidać, skąd pochodzi. Prezentacja nt. tego jak działa AOL została upubliczniona przez Business Insidera.

Obrazek niżej pochodzi z 2009, z dużej polskiej firmy internetowej. W jakimś stopniu po wdrożeniu ten proces został porzucony, nie mam obowiązujego obecnie. Prawdopodobnie ten był niezbędnym etapem na drodze do Agile.

proces_rozwoju_allegro

Ta firma to Allegro. Pokazywany był na branżowej konferencji informatycznej. Ze schematem z AOL łączy go podejście - kaskadowe. Na początku wymyślamy coś dużego, potem projektujemy coś dużego, potem długo to robimy. Na koniec okazuje się, że wszystko wyszło idealnie... No to akurat się rzadko zdarza.

Pierwszy proces ma fazy, ale różni się treścią. Inaczej wymyśla się w nim rzeczy, robi się o wiele taniej, głównie po to, żeby sprawdzić pewne teorie. Dopóki coś jest projektem i koncepcją, pozostaje teorią. Prawdziwe liczby i użytkownicy bez większego wysiłku stale takie teorie obalają.

Pierwszy proces to Spotify. Dość dokładnie opisany jest tutaj. Wszystkim, którzy się zajmują tematem [czyli pewnie jakimś 10 osobom w pl ;-)] polecam uważną lekturę.

Zagrajmy w ustalanie priorytetów

tebe

Pisałem już jak ważne w rozwoju produktu jest priorytetyzowanie rzeczy, którymi się zajmujemy. Niedawno natknąłem się na niezły przepis na ten proces. Jego autorem jest Tom Conrad, który odpowiadał za rozwój Pandory, jednej z ważniejszych na rynku aplikacji muzycznych.

W tym podejściu wybór rzeczy do realizacji przypomina grę. Kolejne fazy są takie:

  1. Każdy zgłasza swoje pomysły odpowiadając na sprytnie postawione pytanie: czego głupotą byłoby nie zrobić w najbliższych trzech miesiącach. Czyli nie "co moglibyśmy zrobić" tylko "czego nie możemy nie zrobić". Już to wymusza refleksję. 
  2. Wszystkie pomysły opisuje się w podobny sposób - za każdym razem na takim samym slajdzie podając o co chodzi i jakie korzyści ma to przynieść produktowi.
  3. Szacuje się ilośc pracy potrzebną do zrealizowania każdej rzeczy.
  4. Tu zaczyna się praca grupowa. Tworzy się wirtualną walutę (np. papierowe dolary), które dostają osoby decydujące. Ich ilośc odpowiada liczbie dostępnych dni pracy ludzi, którzy są potrzebni, żeby to wszystko zrealizować.
  5. W czasie sesji głosuje się "wydając" przydzielone pieniądze na poszczególne funkcjonalności / zmiany. To co zostało sfinansowane trafia do realizacji.

Warto poczytać dokładnie tekst Conrada, ale kilka rzeczy w tym podejściu jest wartych omówienia.

Całość upraszcza proces analiz i wymiarowania pomysłów. Metoda jest zwinna, oparta na zdrowym rozsądku. W innych podejściach każde zadanie można modelować na różne sposoby i wrzucać do exceli, z których na koniec nic mądrego nie chce wyjść. Tu logika jest prosta - albo jesteśmy jako zespół / startup / organizacja do czegoś przekonani i to finansujemy, albo nie. By to zadziałało, w grupie decydujących warto.. mieć decydentów. Byc może nawet dając im trochę więcej pieniędzy niż pozostałym.

Ćwiczenie wymusza uczestnictwo i wciąga zainteresowanych. Dobrze zrealizowane zapewnia, że kluczowe dla produktu osoby aktywnie uczestniczą w decyzjach. Identyczna prezentacja wymusza myślenie o tym, co określona rzecz da. Nic nie dzieje się pod stołem - każdy krok jest omówiony, a równocześnie nie zajmuje to dużo czasu. Przy okazji rozmowy o kosztach i korzyściach wszyscy mogą lepiej zrozumiec proces rozwoju. Gra wspiera też tworzenie kultury priorytetyzacji w załodze.

Dośc kluczowy jest szacunek kosztów i ocena czasu pracy jaki mamy do dyspozycji. Tu najczęściej popełniamy błędy. Mylimy się szacując ile coś zajmie, dlatego trzeba to robić z uwagą, ale też dzielić rzeczy na takie (czytaj: względnie nieduże), by ich ocena była możliwa. Z drugiej strony nie można zakładać, że miesiąc pracy człowieka to pełne 20 dni na rozwój. Ludzie chorują, chodzą na urlopy, a przede wszystkim robią całą masę rzeczy, które zżerają ten czas. Utrzymanie, zebrania i maile zabierają więcej niż wam się wydaje. To warto liczyć i posługiwać się danymi zbliżonymi do historycznych.

Niedawno przećwiczyliśmy to w praktyce m.in. planując dalszy rozwój nowego Blox.pl. Zachęcam do próbowania w startupach i przedsiębiorstwach wszelakich.

BTW - świetnie się pisze w tym nowym edytorze Blox.pl

Wyceny, budżety i tricki

tebe

Ucieszył mnie wpis Davida HH, na temat wycen i budżetów w projektach. Radzi on, by wstępny szacunek czasu pracy uznawać za budżet i trzymać się go w czasie realizacji, poświęcając na projekt tylko tyle na ile go wstępnie wyceniliśmy. Na taki pomysł wpadliśmy pod koniec 2012 roku. Nie jest to łatwe, zwłaszcza w dużej organizacji, ale działa - warto się starać.

Osobom, które "tego" nie robiły, trudno się rzecz tłumaczy. Oczekują one zwykle, że ktoś odpowiedzialnie powie ile potrzeba pracy i czasu by stworzyć nową funkcjonalnośc czy usługę. Doświadczeni (w innych obszarach) menedżerowie mogą takie deklaracje uznawać za "nieprofesjonalne", ale nie ma czegoś takiego jak sensowna wycena w projektcie programistycznym, zwłaszcza, gdy powstaje w nim produkt dla konsumenta. Nie bez powodu jest to jeden z głównych wątków metodyk rozwoju oprogramowania, których jest bez liku. 

Dlaczego tak jest? Z wielu powodów, o których już pisałem. Przede wszystkim, w rozwoju praktycznie nie zdarza się, że robimy to samo po raz kolejny. Tylko w takiej sytuacji możnaby - zakładając identyczne zachowanie zespołu i czynników zewnętrznych - powiedzieć ile coś zajmie. Przeważnie to, co wiemy na początku o produkcie jest zbyt ogólne by można było powiedzieć ile zajmie. Wszystkie niejasności znikają z czasem - kiedy już w trakcie realizacji poznajemy co trzeba stworzyć, by osiągnąć konkretne cele. Żeby było trudniej, koszt realizacji każdej ze składowych projektu zależy od wybranego sposobu rozwiązania. Gdy już dobiegamy do mety, zaczynają się mnożyć błędy, których naprawianie wywołuje następne. 

Jeśli nie da się powiedzieć na kiedy i za ile, to jak w takim razie podejmować decyzje? Przecież każda zmiana powinna się opłacać - oczekiwane korzyści mają być mniejsze niż koszt realizacji. Tradycyjne podejście do projektów zakłada, żeby robić to dwustopniowo. Najpierw podejmujemy wstępną decyzję, potem robimy dokładne analizy, projekty i wyceny, wtedy podejmujemy decyzję właściwą. To jednak żółwi proces, dobry np. w banku. Tam - przynajmniej teoretycznie - można policzyć ile coś da. W rozwoju produktów tempo musi być znacznie żywsze, a korzyści tak bardzo zależą od reakcji użytkowników, że opowiadanie o nich zwykle ociera się o wróżenie. Dlatego warto przyspieszać weryfikację założeń o kosztach i zyskach.

Proponowane podejście wychodzi od zrozumienia ograniczeń, po czym je wykorzystuje. Nie udajemy już, że wiemy ile coś zajmie, ale nadal staramy się to w miarę dokładnie przewidzieć. Potem, realizując, tak podejmujemy decyzje, żeby się zmieścić w przyjętym budżecie i czasie. Wymaga to ofiar (pozornych), oraz dyscypliny (która zawsze jest trudna). Nic tak nie pomaga w realizacji jak narzucony termin - nie trzeba znać metodyk rozwoju oprogramowania, żeby wiedzieć, że praca zawsze wypełnia cały dostepny czas...

© Tebe Gada
Blox.pl najciekawsze blogi w sieci