Kategoria: PL

Potrzebny przewodnik po mapie

Do korzystania z nowych wersji Google Maps przydałaby się czasem instrukcja obsługi. To jedna z gorszych rzeczy jakie można powiedzieć o produkcie cyfrowym. Kiedyś Google w mapach zrobił rewolucję, podnosząc poprzeczkę o kilka poziomów. W zeszłym roku gruntownie przebudował ten produkt, robiąc przy tym parę rzeczy zdumiewających. Dałem im okrzepnąć, upewniłem się, że to co mi przeszkadza jako użytkownikowi jest po prostu złe. Zadając pytanie dlaczego to tak zostało zrobione, o czym zapomniano, warto się czegoś nauczyć o projektowaniu. Warto też spojrzeć krytycznie na „aktualne trendy w dizajnie”.

Zwykle nie krytykuję tu pracy innych. Zakładam, że to głównie problem biznesu, którego produkty użytkownicy porzucą, lub nie. Wyjątki to rzeczy interesujące ze względu na skalę i pozycję na rynku. Mapy takie są. Mapa to nie jest zwykły produkt. W świecie fizycznym ma szczególne znaczenie. Pominąwszy rolę w gospodarce, planowaniu i własności prywatnej, bez map byśmy się zgubili. Są częścią historii, wypełniając mapę człowiek podbił świat.

Raczej nie powinno się z mapami igrać.

Jak mi się zdaje, ogarniam złożoność tego produktu. Rozumiem wyzwania, z którymi się tu mierzono. Powiązane interakcje, w których coś z jakiegoś powodu się pokazuje, a coś znika. Warstwy, których nie widać. Mogę się domyslać, że mapa ze swoimi danymi będzie platformą do większej liczby usług, bardziej złożonych niż pokazywanie drogi.

Niektóre interakcje są w nowych Mapach zrealizowane wręcz wspaniale – od strony funkcjonalnej, technicznej oraz estetycznej. Zbyt często jednak decyzje o tym, co się ma pokazywać i jak to ma działać zostały podjęte źle. Główna praca w designie to myślenie i podejmowanie decyzji, z użytkownikiem w głowie. Decyzji o tym, jak produkt ma działać.

To by była pierwsza lekcja – „czym jest projektowanie?”.

Pamiętam pierwszy kontakt z nową wersją produktu. Sprawdzałem, gdzie są korki. Mapa zaproponowała mi użycie nowej wersji i po chwili zastanawiałem się, jak włączyć natężenie ruchu? Później wprowadzono ułatwienie – w wersji pecetowej widać link „natężenie ruchu”. Wtedy trzeba było.. wpisać takie hasło w wyszukiwarce. Chyba.

Lekcja druga: warto pamiętać podstawy, np. „Nie każ mi myśleć” Kruga.

Używam map na wszystkich ekranach. Kiedyś skusiłem się na aktualizację aplikacji iPadowej. Sprawdzam trasę i… dlaczego opis zajmuje prawie pół ekranu? Jak wygodnie prześledzić samą trasę? Nie chcę czytać listy nazw ulic i miejsc zakrętów, chcę oglądać mapę. Chowam podgląd, znika również trasa…

Ten scenariusz jest dość częsty: wykonujemy akcję, coś widzimy, chcemy zobaczyć to lepiej, więc próbujemy schować menu. Wtedy znikają kluczowe informacje. Np. pinezka wskazująca wyszukiwany adres. Gdy o tym myślę, nie jestem w stanie opowiedzieć jak dokładnie się to zachowuje. Nie jest łatwo się tego produktu nauczyć – a to już jest duży problem. I przy okazji lekcja – należy projektować tak, by użytkownik stopniowo się uczył. By był w stanie zapamiętać, jak go użyć.

Sprawdzanie tras i korków to podstawowe scenariusze używania mapy. Zmieniając je powinno się testować reakcje użytkowników. Testując z użytkownikami warto wyłapywać ich frustracje, a nie szukać potwierdzeń dla doskonałości swoich pomysłów. To lekcja kolejna, ważniejsza od poprzedniej.

Na mapie zwykle jest skala. Od setek lat. Gdzie jest skala na Google Maps mobile? Pojawia się na chwilę, gdy zmienia się wielkość mapy. Na tyle krótko, że nie jesteś w stanie jej użyć… To typowe u projektantów, usuwanie rzeczy. Czytali o minimaliźmie, więc usuwają.

Tymczasem skala jest czymś ważnym na mapie. Kropka.

Północy też nie zabierajcie. Choć w jakimś sensie już to zrobili. Na mobile były przyciski powiększania i powiększania. Jedną ręką dało się trzymać telefon, przybliżyć i oddalić mapę. Teraz rozsuwa się ją palcami, przy okazji zmieniając orientację. Nie jest to automat, ale łatwiej to zrobić niechcący. Ale zniknęły przyciski, więc dobrze?

OK, jestem stary.. skala, przyciski, ktoś powie, co za pierdoły. Dla pewności obserwuję syna. On jest „digital native”, co gorsza przyklejony do androida. Dla niego TO jest mapa, nie ten kawałek papieru, który rozkładam gdy gdzieś przyjedziemy. Też ma problem.

Chowanie rzeczy jest dobre. Interfejs, który ma tylko funkcje ważne i potrzebne w danym momencie to ideał… Tylko czy rzeczywiście się tylko chowają? O ile język materialny Googla jest dobry jako idea i może się podobać jego wygląd, niektóre jego składowe, głównie ze względu na estetykę, zużywają zbyt wiele miejsca. Wiadomo, design musi mieć czym oddychać. To nie musi być złe, ale waga decyzji o tym, czy coś pokazać rośnie.

Biała „przestrzeń estetyczna” zabiera miejsce treści. Ma też funkcję „miejsce na palec”. Problem zaczyna się, gdy tego wszystkiego jest za dużo. Problem się zwiększa, bo każda decyzja, każda funkcja zajmuje więcej miejsca. Na dole ekranu mobilnego pojawił się np. napis „w pobliżu miejscowości xxxx”. Jest tam cały czas i czasem jest idiotyczny. Opisuje miejsce, na które patrzymy i nie znika. Oglądam Sieldce, wiem, że to Siedlce, cały czas mam „w pobliżu miejscowości Siedlce”. Nie ma szans, że zapomnę i pomylę z Berlinem, jak to dobrze. Na pasku, który zajmuje jeszcze więcej przestrzeni dotąd wypełnionej treścią mapy. Dlaczego znika skala a nie to?

Taki trend: w związku z wzrostem znaczenia designu wszystko stało się większe. Paradoks? Nie, błędny zakręt ewolucji. Nie powinno się ograniczać dostępu do treści. Warto oszczędnie gospodarować przestrzenią i w jak najlepszym stopniu wypełniać ją znaczącą treścią właśnie. Lekcja przedostatnia.

Google ma na pokładzie utalentowanych ludzi, błyskotliwy zarząd, przychody rozwiązujące wszystkie problemy. Zatrudnia bataliony projektantów, stawia na design i publikuje znakomite dokumenty opisujące „język designu”. Ta firma nie powinna robić takich rzeczy. Dlaczego robi? Jak dochodzi się do projektowania dla samego projektowania? Może projektanci w Googlu mają za dobrze? Zrobili już swoje, przemalowali wszystko w bardzo krótkim czasie. Dostali medal i muszą coś robić, więc projektują.

Tu jest kluczowa lekcja, ale już na poziomie zarządzania. To też lekcja Steve Jobsa. Teraz, gdy wszyscy próbują nim być i największym – takim jak Bezos oraz aspirującym – takim jak Pani Mayer – to nie wychodzi, warto pamiętać o jego lekcjach. Ja zapamiętałem taką, w której mówił, że Apple nie ma zbyt wielu „zasobów”. Ma ich dość, ale nie ma ich tylu, żeby nie musieć dobrze wybierać, czym się zajmują…

Dwa światy, trzy różnice

Pracownicy banków, firm ubezpieczeniowych czy telekomunikacyjnych budujący produkty cyfrowe nie różnią się szczególnie od osób zatrudnionych w nowym, internetowym biznesie. Mogą mieć podobne kompetencje, podejście i zaangażowanie. Jednak świat, w którym działają jest inny i to co osiągną w większym stopniu zależy od organizacji, niż od ich możliwości.

Porównały te światy dwa blogi: SVPG i Monday Note. Pierwszy opisał różnice między kulturą produktową i informatyczną, drugi zajął się światem mediów. Oba aspekty są mi bliskie, z czystym sumieniem mogę polecić te wpisy. U podstaw różnic, które wymieniają wydają się leżeć odpowiedzi na trzy kluczowe pytania. To jak na nie odpowiadaja organizacje nie jest czymś o czym zdecydowały. To raczej kwestia DNA. Tak wyewolułowały, nie wiedzą, że można inaczej. Nawet jeśli wiedzą, często nie potrafią.

Zacznijmy od starożytności. Do poprzedniej dekady informatycy nie interesowali się konsumentem. Komputer osobisty służył mu najwyżej do grania (nieco przesadzam, celowo). Sukcesy rynkowe i pieniądze w informatyce oparte były o sprzedaż dla przedsiębiorstw. Oba człony są ważne – wokół nich zbudował się biznes. „Sprzedaż” miała wpływ na sposób prezentacji oferty, oznaczała duże sumy i długie kontrakty. „Dla przedsiębiorstw” określało rodzaj rozwiązywanych przez intormatykę problemów. Po 2000 roku to się zaczęło zmieniać – dziś większe pieniądze wynikają z robienia rzeczy, których używają ludzie (gdyby ktoś miał wątpliwości: Google, Amazon, Facebook, Apple).

Jakie są więc te fundamentalne różnice?

– Kto decyduje o sukcesie produktu? W informatyce o wyborze rozwiązania decydował kontrakt i sprzedaż, często na poziomie zarządu. Klikający nie miał wyboru. Prezes zamówił, księgowa musiała się nauczyć. Co więcej, opłacało się coś sprzedać, a do rachunku dopisać szkolenia. Nie była konieczna wiedza o użytkowniku końcowym, nie miały znaczenia użyteczność, wygoda i efektywnosć działania produktu. To są rzeczy w produktach cyfrowych ważne (choć nie wystarczające). Poza nimi jest jeszcze magia, związana choćby z budowaniem skali. Wpływ tego podejścia nie ogranicza się do wymyślania i budowania produktów. Obejmuje też takie sfery jak obsługa użytkownika. Obsesja na jego punkcie to wynalazek Amazona i podobnych. Oczywiście ich motywacją jest konkurencja, gdy jest niczym nie ograniczona, warto inwestowac w lojalnośc.

– Jak technologia zaangażowana jest w budowanie produktu? W podejściu tradycyjnym dział technologii buduje zlecone rzeczy. W produktowym – współtworzy je. Świetne jest porównanie SVPG do najemników i misjonarzy. Pierwszym mówi się co mają zrobić, drugich motywuje to, co budują. Chcą, żeby było jak najlepsze, rozumieją użytkownika, proponują rozwiązania i dbają o jakośc. W świecie cyfrowym biznes jest technologią, a technologia przewagą, której nie można pominąć. Tradycyjnie – jest czymś, co się zamawia. Jacyś informatycy to robią.

– Jak długo produkty się buduje? Tu mamy paradoks. W informatyce kojarzymy „bardzo długi kontrakt dla ZUS”, więc w zasadzie w nowym świecie powinno być „krótko i szybko”. Niestety prawda jest taka, że tu rozwój nie kończy się nigdy. W tradycyjnym rozumieniu działowi technologii się coś zleca, on to robi, potem jest to zrobione i koniec. Definicja-realizacja-wdrożenie-następny temat. W świecie produktów cyfrowych, wdrożenie to dopiero początek – zaangażowanie w rozwój produktu musi być długofalowe. To jak działa jest na tyle ważną przewagą, że osiąga się ją dopiero poprawiając coś działającego. Termin „zwalnianie zasobów” nie występuje. Nie występuje dlatego, że nic się nie zwalnia oraz nie ma zasobów. Ważniejsza od dowiezienia projektu jest umiejętnośc szybkiego rozwoju produktu.

Skąd to podejście wynika? Wyewolułowało. Tradycyjne długie nieudane projekty zamieniono w branży na trwające w podobnym czasie serie małych, dużo bardziej udanych. To okazało się efektywne. Po drugie określają je warunki rynkowe. Ponieważ dystrybucja produktów jest tania, konkurencja jest nieustanna, rynek wymusza ciągły rozwój. Autorzy Monday Note sugerują, że przyczyną może być głębokość kieszeni. Inicjatywy cyfrowe wydawców nie mogą liczyć na takie finansowanie jak startupy. Choćby Vox media, który niedawno pozyskał 45 mln USD od inwestorów. Pytanie czy poziom zaangażowania wynika z finansowania, czy sposobu myślenia o rozwoju.

Podział nie jest już taki czarno biały: produktowe podejście dla userów i tradycyjne dla firm. Coraz więcej w nowym świecie powstaje rozwiąząń dla biznesu – już nie tylko internetowego. Przykładem niech będzie Box, w którym wyzwaniem jest połączenie organizacji sprzedażowo-usługowej z kulturą rozwoju rodem z Google czy Facbooka. Tak przynajmniej twierdzi szef startupu Aaron Levie. Box musi do swojej organizacji dodać – powiedzmy to – gorszą część kultury. Zdrowy fundament już ma. Inni mają gorzej, bo najtrudniej zmienia się kulturę. Podejście tradycyjne i „model IT” jest tak zakorzenione w organizacjach, że łatwiej im będzie wyginąć niż się zmienić.

Co jednak nie jest niemożliwe.

Szukając Pareto

Poszukiwanie prostoty jest wysiłkiem. Trzeba go podjąć, jeśli chce się zrobić tylko znaczące rzeczy. Ten paradoks okazał się najciekawszym wątkiem z poprzedniego wpisu „Reguła prostoty”. Co sprzyja takiemu poszukiwaniu, zwłaszcza w pracy zespołów?

– Rozmiar. Ma olbrzymie znaczenie, to oczywiste i nieoczywiste zarazem. Peter Drucker już w 1954 pisał, że dobry zespół to 3-4 osoby. Bardzo często się o tym zapomina. Z każdą dodatkową osobą, dowolna rzecz z tej listy będzie trudniejsza. Przyczyny? Społeczne, zwłaszcza związane z „komunikacją”, matką wszelkich korpo problemów.

– Myślenie. Zalecane na każdym etapie, zwłaszcza przed. Niestety, wg aktualnych badań [HBR] myślenie grupom wychodzi słabo.

– Słuchanie. Nie tylko własnego głosu, co jest jedną z najprzyjemniejszych aktywności. Również innych, zwłaszcza użytkowników. Nie trzeba, czasem wręcz nie wolno, robić tego co mówią. Warto wyłapywać informacje na temat ich potrzeb, sposobów korzystania z produktów i problemów jakie z nimi mają.

– Otwartość rozmowy. Jeśli chcemy mieć różne głosy i opinie, trzeba sprawić, że się pojawią. Trzeba stworzyć klimat, który zapewni, że wypowiedzą się nawet introwertycy. Czesto to oni mają najwięcej do powiedzenia. Na retoryce krzykaczy w dłuższym terminie niewiele się buduje, wyniki bezlitośnie się z nią rozprawiają.

– Mierzenie. By znać wyniki, potrzebne są dobre miary. Takie pirackie, pokazujące, czy rzeczywiście coś zadziałało. Ich poszukiwanie nie jest banalne. Warto też zerkać na koszt i próbować mierzyć swój czas w złotówkach.

– Pamięć. Jeśli coś działało kiedyś, jest szansa, że zadziała znowu. Jeśli nie działało, można spróbować to zrobić lepiej. Raczej nie ma sensu próbować tego samego, w ten sam sposób. Czasem jest to demotywujące, bo niestety niewiele rzeczy naprawdę działa.

Jest tu pułapka. Często rozwiązanie realizowane jest źle i na podstawie wdrożenia wyciąga się wnioski, że jest nieskuteczne. Może powodować to detal, czasem „nie działanie” wynika z przyjętej miary. Jeśli w coś wierzymy, warto tego spróbować na 2-3 sposoby.

Temat pamięci powiązany z tzw. budowaniem wiedzy w organizacji. „Uczenie się” jest częstą wymówką w projektach „wprawdzie się nie udało, ale wiele się nauczyliśmy”. To jest przereklamowane. Najczęściej wszyscy zachowują jakby coś było robione pierwszy raz. To o tyle dziwne, że do dyspozycji jest cały arsenał przypadków opisanych wokół, a podczas rozwoju stale buduje się jakąś historię.

I mówiąc szczerze jeszcze nie mam na to sposobu.

– Elastyczność. Gdy coś zadziała, warto to drążyć i eksploatować szukając maksimum. Ścisłe trzymanie się z góry założonego planu utrudnia takie zwroty.

– Autorefleksja. Podsumowania czyli Post mortem pomagają w budowaniu pamięci. To trudny do stosowania zwyczaj (nikomu się nie chce, gdy jest już po wszystkim). Ciekawą wersją jest „Pre mortem”, w którym próbujemy napisać podsumowanie projektu przed jego rozpoczęciem. Wymieniamy co się udało, oraz co poszło źle. To umożliwia odkrywanie niebezpieczeństw.

– Małe kroki. To dośc oczywiste  —  każdego słonia trzeba jeść po po kawałku. Próbować i testować. Postęp jaki się uzyskuje zamykając małe etapy jest motywujący. Wszystkie wymienione tu przepisy lepiej działają w krótkich iteracjach.

To warunki, które mogą wpłynąć na pracę zespołów w średnich i dużych organizacjach. Pewnie inaczej jest w start-upach na wczesnym etapie rozwoju. Praca indywidualna to odbrębny temat. Dla wszystkich, jest jedna wspólna reguła: ćwiczyć. Całe czytanie mądrości w internecie (choćby takich jak ten wpis) nie ma bez stosowania ich w praktyce większego sensu.

Wszyscy czytają to samo, sukcesy odnosi niewielu.

Reguła prostoty

„Simplicity – art of maximizing the amount of work not done – is essential”

To jedna z 12 zasad zwinnego tworzenia oprogramowania: „sztuka maksymalizacji pracy niewykonanej”. Całość w połączeniu z manifestem Agile (2001 rok) to podstawa metodyk, które zrywają z fikcją podejścia kaskadowego. Jeśli ktoś nie zna tematu, a w jakiś sposób zajmuje się rozwojem oprogramowania, powinien o tym poczytać. Materiałów jest dużo, wszystko co ważne można znaleźć zaczynając od Wikipedii.

Ta zasada definiuje prostotę i podkreśla, że jest kluczowa. Lubię ją, bo jest uniwersalna, działa nie tylko w świecie programowania. Mówi, by nie tracić czasu na rzeczy, które nie przynoszą efektu. Żeby skupiać się na istocie. To podejście spójne z Pareto – za 80 proc. efektów odpowiada 20 procent działań. Jak napisał P. Drucker „nie ma pożytku z efektywnego wykonywania pracy, która nie powinna być wykonywana”.

Kto budował ten wie, że jak niewiele funkcji w produktach ma znaczenie i jak trudno znaleźć zmianę, która przyniesie efekt, coś poprawi (zwiększy sprzedaż lub zaangażowanie użytkowników). Wie też, jak łatwo utonąć w detalach i scenariuszach, które nie mają znaczenia. W rozwoju nie jest ważna liczba wytworzonych rzeczy, tylko wynik. W działaniu nie jest ważna liczba przepracowanych godzin, tylko efekt. By go osiągnąć potrzebny jest dobry wybór środków a potem dbałość o detal. Może to dotyczyć zmian, ale też choćby poszukiwania kanałów promocji, które działają i są efektywne.

Podejście wynikające z tej zasady czasem wydaje mi się sprzeczne z wartościami powszechnie uważanymi za wartości. Np., że aby coś zrobić, należy się narobić. Jeśli nie siedzieliśmy po nocach, jeśli nie pojawiła się krew, pot i łzy, to jak możemy oczekiwać, że pokonamy konkurencję? Nie wiem czy to powszechne, czy tylko polskie, ale jeśli, to skąd po 50 latach bezproduktywnego komunizmu trwa w nas taki kult pracy? Wcale mi on nie imponuje.

W dłuższym horyzoncie zachowanie prostoty wspiera rozwój i utrzymanie – rzeczy mniej skomplikowane utrzymuje i modyfikuje się taniej i szybciej.

Często autorzy przydługich niejasnych dokumentów czy maili sięgają po cytat z B. Pascala „napisałbym krócej, gdybym miał więcej czasu”. Słusznie, prostota wymaga wysiłku. W pisaniu jest on potrzebny, by dotrzeć do sedna i osiągnąć przejrzystość. Jest takie redaktorskie porzekadło „o połowę krótszy artykuł będzie miał dwa razy więcej czytelników”. Również lepiej zapracuje krótszy, jaśniejszy i bardziej skupiony na sednie dokument. Ten wysiłek, podjęty odpowiednio wcześnie, potem owocuje – sensowniejszym działaniem, lepszymi decyzjami.