Jakiś czas temu padło pytanie jak powstaje Mobile dla Managerów i jaki mam do tego przygotowany warsztat pracy.
Wychodzę z założenia że narzędzia są drugorzędne w samym procesie pisania. Im mniej funkcji tym lepiej, więc szukałem narzędzi, które nie wprowadzają szumu, nie wymagają zbytniej nauki i pozwalają zautomatyzować co tylko się da.
Pierwszym i centralnym elementem całej układanki jest LeanPub – serwis, który pozwala na samodzielne pisanie i publikację książki elektronicznej. Pierwszy raz tutaj trafiłem, gdy została mi polecona książka Agile w Praktyce Andiego Brandta. W LeanPub szczególnie ciekawe, jest to, że można publikować i sprzedawać swoją pracę, zanim jeszcze zostanie skończona (to jest dopiero szatańsko leanowe podejście!).
LeanPub zajmuje się całą stroną techniczną automatycznie: wystarczy wrać pliki z tekstem, a system sam generuje spis treści, podpisy, odnośniki i to w niezależnych plikach epub, mobi i pdf. Mają też całkiem fajne statystyki i gotowy landing page – oszczędza więc dużo czasu, który można przeznaczyć na pisanie.
Choć z LeanPuba można korzystać przez stronę www to ja preferuję synchronizację plików przez Dropbox. LeanPub wygenerował sobie katalog po tym jak dałem mu dostęp do Dropa i tam siedzą wszystkie moje pliki związane z MDM. Zgodnie z rekomendacją – każdy rozdział to oddzielny plik tekstowy.
Na tym etapie wiedziałem już, że muszę nauczyć się Markdowna – czyli specjalnego języka ze składnią, która pozwala na dodawanie do standardowego tekstu tabel, obrazów, cytatów i innych upiększaczy. W czym Markdown jest lepszy od tego co oferują natywne formaty Pages czy Word? Przede wszystkim jest minimalistyczny i uniwersalny – nie ważne jak i gdzie ktoś czyta twój tekst to i tak wiesz, że będzie dobrze wyglądał. Inna sprawa, że LeanPub wymaga, aby się go nauczyć:)
Kiedy już byłem pewien, że bez Markdowna się nie uda, to stwierdziłem, że muszę znaleźć sobie takie narzędzie do pisania, które będzie mi pomagało (nie przeszkadzając). Ostateczny wybór padł na Byword 2 – trafiłem wtedy na promocję i zapłaciłem trochę mniej niż standardowe $10.
Byword na OSX jest świetny do długich sesji pisarskich, na które mogę sobie pozwolić tylko w weekendy. Kiedy jednak gdzieś w drodze wpadnie mi do głowy fajna myśl to zapisuje je w Simplenote na iPhonie. Kocham Simplenote miłością nieprzerwaną od ponad czterech lat. Każdą notkę związaną z książką oznaczam w tekście z tagiem #mdm i później tak przefiltrowane notatki przelewam do książki.
Jeśli chodzi o newsletter to korzystam z Tinyletter. Jest prosty i darmowy. Myślałem o bardziej rozbudowanych systemach mailingowych jak MailChimp czy polskie GetResponse czy Freshmail, ale wszystkie wydają mi się zbyt skomplikowane. Odstawiłem więc kombajny na bok. Tinyletter ma limit 5000 subskrybentów, który raczej ciężko będzie mi zapełnić, ale jeśli już tak się stanie to zawsze mogę przenieść się gdzieś dalej.
Czasami do newslettera wrzucam link do fajnego fragmentu z książki (jak ten). Wtedy otwieram macowe Pages, wybieram jeden z predefiniowanych szablonów (są bardzo estetyczne!) i wrzucam tekst. Ten, w większości przypadków, sam się dobrze układa.
Generuję sobie wtedy PDFa i wrzucam na Dropboksa do publicznego katalogu. Zanim jednak udostępnię ten plik to korzystam jeszcze z Bit.ly czyli skracacza liników. Bit.ly daje mi kontrolę na linkiem – zawsze mogę podmienić co jest pod nim, wiem też ile osób i skąd na niego klika.
Niedługo będę chciał się dowiedzieć więcej o moich potencjalnych czytelnikach i odpalę ankietę. Tutaj mój wybór padł na Typeform – przede wszystkim ze względu na ergonomię i responsywny design. Da się ją wypełnić zarówno na desktopie jak i smartfonie.
Okładkę także zrobiłem sobie sam bo kiedyś, bardzo dawno temu kupiłem w promocji Pixelmatora (teraz kosztuje $30) – czyli takiego młodszego brata Photoshopa.
Mimo tego, że ten blogpost jest długi jak na moje standardy to sam proces jest bardzo prosty i szybki (szukałem najłatwiejszych rozwiązań jakie były). Jedynie LeanPub na początku przytłacza swoimi możliwościami, ale warto przebrnąć przez ich manual i wszystko powoli staje się jasne.
Nam sam koniec: jeśli nosisz się z zamiarem pisania książki to mam prostą radę: po prostu zacznij. Narzędzia mają marginalne znaczenie – korzystaj z tych, które masz pod ręką i olej porównywanie funkcji konkurencyjnych programów bo wpadniesz w pułapkę wyścigu zbrojeń – zamiast zająć się pisaniem.
Mam taką osobistą zasadę, że nie lubię pluć sobie w moją długą brodę. Minimalizuję momenty gdy jestem zmuszony powiedzieć 'szkoda że tego nie zrobiłem’ więc miesiąc temu podjąłem decyzję, że kończe pracę w o2 i z początkiem sierpnia rozpoczynam walkę na własną rękę.
Jest kilka powodów: znalazłem zespół z którym dzielę wspólne zamiłowanie do jakości, branża mobile wrze i aż prosi o zastrzyk nowych kompetencji, a środowisko osób decyzyjnych dorosło do traktowania mobile’a poważnie.
To najlepszy możliwy moment.
Ale jest coś jeszcze, coś osobistego: potrzeba robienia rzeczy na nowo, na własnych zasadach. Sprawdzenie na własnej skórze jak rynek potrafi skopać dupę i jak wysoko wynieść. Plułbym sobie w brodę, gdybym nie spróbował. Resztę zweryfikuje czas.
Ps. Dziękuję wszystkim, których prosiłem o rady – jestem wam niezmiernie wdzięczny, szczególnie za szczerość.
Pps. Jeśli twoja firma potrzebuje top-notch rozwiązań mobilnych – napisz mi maila :)
25 kwietnia miał premierę mój największy i najbardziej ambitny projekt mobilny – Play24.
To dobry moment, aby podsumować cały proces projektowy i wyciągnąć wnioski – może to przyda się naszej społeczności projektującej aplikacje mobilne.
Background
Na początku istotne jest zrozumienie kontekstu naszej współpracy: LoveMobile (agencja mobilna, którą kieruję w ramach Grupy o2) zostało zaproszone przez Play do zaprojektowania odświeżonej wersji aplikacji Play24, ale nie byliśmy jedynym podmiotem uczestniczącym w całym procesie.
Play24 to system do samoobsługi konta u operatora. To oznacza, że aplikacja mobilna jest ściśle skorelowana z możliwościami backendu więc musieliśmy się dostosować do filozofii działania systemu, ale mieliśmy też duży wpływ na to jak on się rozwinie na podstawie naszych sugestii.
Przy procesie produkcji aplikacji uczestniczyły trzy podmioty: Play jako zleceniodawca, my (LoveMobile) i software house wybrany przez Play, wdrażający nasze szalone pomysły. Ten układ byl specyficzny, ale sprawdził się dobrze bo powstał u nas taki mały system checks & balances – my pilnowaliśmy, aby zasady mobile UX który chcemy wprowadzić były zachowane, software house stopował nas przed bujaniem w obłokach a Play patrzył czy wszystko idzie w dobrym kierunku i kontrolował sytuację.
Kick off
Naszym zadaniem było zaprojektowanie od zera części wizualnej i interakcji użytkownika z systemem w środowisku mobilnym. Aby zrobić to dobrze musieliśmy zrozumieć przede wszystkim kim jest użytkownik Play24 i w jaki sposób z niego korzysta. Rozpoczęliśmy od zbierania user stories (w których uczestniczył między innymi Paweł Lipiec ale chyba się nawet nie zorientował:) aby zrozumieć motywacje użytkowników. Z tego wyklarowały nam się trzy najważniejsze:
korzystam z Play24 bo boję się, że czegoś mi zabraknie („czy wystarczy mi megabajtów do końca dnia?”),
zaciekawiła mnie nowa reklamowana usługa Play („fajna jest ta Audioteka z Play – sprawdzę jak działa”),
coś mi się nie zgadza na koncie („gdzie jest moja kasa?!”)
I jeszcze jeden dodatkowy wniosek: ta aplikacja jest traktowana jako timesaver a nie timewaster – to oznacza, że korzysta się z niej aby szybciej zdobyć ważne dane niż aby szybciej płynął czas; to aplikacja czysto użytkowa.
Userflow
Mając obraz motywacji użytkowników rozpoczęliśmy projektowanie userflow, czyli określania jak będziemy „rozprowadzać” ruch użytkowników to aplikacji tak aby osiągnęli zamierzone cele. Ta praca zawsze przypomina mi trochę zadania architekta miejskiego, który musi optymalnie zaprojektować ruch uliczny – tak, aby każdy dotarł tam gdzie chce w jak najkrótszym czasie, bez niepotrzebnego błądzenia i stresów. My mamy o tyle łatwiej, że pracujemy na „clean slate”, bez wcześniejszych uwarunkowań poza dobrymi praktykami i możliwościami backendu.
Budowanie userflow to moment w którym spotykają się ze sobą research o użytkownikach zebrany na początku (user stories) i nasze wyobrażenia o tym jak powinna być logika aplikacji, jeszcze bez rozróżnienia na platformy. Są różne sposoby aby przygotowywać userflow, ale my preferujemy do pierwszego draftu kartkę papieru a później MindNode Pro, czyli świetny program do tworzenia map myśli.
Userflow lubi się szybko rozrastać, ponieważ wraz z czasem i pracą staje się coraz bardziej szczegółowy. Na przykład Play24 przy logowaniu sprawdza czy pod danym numerem jest podpięte konto prepaid czy postpaid i w zależności od tego pokazuje „Doładowania” albo ekran „Faktury” jako trzecią ikonę w menu – wprowadzenie takiego rozróżnienia w logice aplikacji powoduje dodanie oddzielnej gałęzi w userflow.
Naszym głównym celem na tym etapie było stworzenie logiki aplikacji tak, aby jak najmocniej ograniczyć liczbę operacji potrzebnych do zaspokojenia trzech motywacji wskazanych w user stories.
Mockupy
Wstępne mockupy rysowane przez Pawła Orzecha z LoveMobile
Chwilę po stworzeniu draftu userflow rozpoczyna się praca nad mockupami – najpierw low fidelity a później high fidelity.
Mockupy lo-fi mają za zadanie pokazać umiejscowienie CTAs (Calls to Action) i głównych elementów w aplikacji. To jest moment gdy zaczynamy myśleć niezależnie o wszystkich platformach na które projektujemy – od samego początku mieliśmy silne przekonanie, że aplikacje muszą być tworzone zgodnie z filozofią systemu operacyjnego na którym są zainstalowane (czyli odrzucamy uniwersalizm i portowanie).
Argument za takim podejściem jest prosty: nie chcemy aby użytkownik musiał uczyć się nowego interface’u skoro ma już pamięć (także mięśniową) natywnego, systemowego. Stąd też menu aplikacji w iOS znajduje się na dole, w Androidzie na górze a na tabletach po lewej stronie (chociaż w tym miejscu zdecydowaliśmy się na mały eksperyment inspirowany aplikacją Alien Blue).
Jeśli nasze papierowe rysunki zaczynają nabierać sensu przenosimy to na wersję cyfrową – korzystamy wtedy z Proto.io, które ma wiele świetnych funkcjonalności, ale dla mnie najważniejszą jest to, że można swój klikalny mockup przetestować w formie HTML5 bezpośrednio na telefonie.
Makiety lo-fi specjalnie robi się bardzo ogólnie i monochromatycznie aby nie rozpraszać się szczegółami, kontrastami i dominantami kolorystycznymi, bo na to przychodzi czas przy następnym etapie – czyli tworzeniu makiet hi-fi. Na etapie makiet hi-fi istotne jest siedzenie jednocześnie przy projekcie graficznym i zasadach tworzenia interface’ów dla iOS (Human Interface Guidelines) i Androida (User Interface Guidelines). Zgodność z tymi dokumentami jest bardzo ważna jeśli stawia się sobie jako cel maksymalnie dobry mobilny UX.
Jeden z pierwszych mockupów hi-fi Play24
Sam projekt graficzny zaczyna powoli przypominać to co widzicie teraz w aplikacji. Oczywiście dużo się będzie jeszcze zmieniać – jak chociażby widoczny tutaj switcher aktywny/nieaktywny czy kołowa „infografika” ze stanem konta.
Matryca
Mając już szczegółowy obraz userflow i makiety hi-fi stworzyliśmy matrycę projektu – po jednej na każdy system i typ urządzenia. Matryca jest doskonałym narzędziem komunikacyjnym z dwóch względów:
pokazuje holistyczny obraz procesów zachodzących w aplikacji a nie pojedyncze screeny
ułatwia szybką komunikację między wszystkimi podmiotami uczestniczącymi w projekcie
Plakaty z matrycami Play24 Android i iOS, które wiszą sobie w Playu:)
Każdy ekran na matrycy jest podpisany cyfrą i literą tak jak pola w szachach. Dzięki temu gdy dostawaliśmy poprawki do projektu to zamiast szukać w setkach piętrzących się screenshotów wystarczyło napisać że na ekranie iOS B4 trzeba poprawić X.
W moim odczuciu matryce okazują się najlepszym sposobem na przyśpieszenie pracy nad tak złożonymi projektami.
Ostatnie szlify
Cały projekt trwał dużo dłużej niż zakładaliśmy pierwotnie, bo mieliśmy głębokie wewnętrzne przekonanie, że nie możemy wypuścić półproduktu. To jest jeden z tych strasznych autoszantaży emocjonalnych, przy którym wpada się w pułapkę ciągłego poprawiania czegoś co jest „good enough”. My mieliśmy świra na punkcie każdego piksela i każdego cienia pod ikoną – do tego stopnia, że patrzyliśmy na przykład czy okres migania ikonki nowego powiadomienia w aplikacji jest już perfekcyjnie naturalny i przyjemny dla oka.
Takie podejście nie jest w dłuższym czasie niemożliwe do utrzymania i sabotuje projekt bo pozwala na przemycanie nieskończenie długiej listy poprawek, które są kosmetyczne i bez witalnego znaczenia dla produktu, a przesuwają shipping date. Z drugiej strony wiedzieliśmy, że taka aplikacja musi od razu być bardzo dobra pod każdym względem, więc obniżenie standardu w jednym miejscu spowoduje obniżenie standardu całego projektu.
Walczymy też na tym etapie z kwestiami, które wydają się z zewnątrz bardzo naturalne i logiczne, ale muszą być uwzględnione przy budowaniu „feelingu” aplikacji – czyli np. wizualne przedstawianie stanów usług (włączona/wyłączona/nieaktywna), stanów buttonów (nietapnięty/tapnięty/nieaktywny), czy rozróżnienia stylem ikonografii różnych systemów (iOS vs. Android).
Żmudna praca Michała Janiszewskiego nad szczegółami interface’u
Zajęliśmy się także dodatkowo mniejszymi pracami graficznymi które otaczają aplikację – na przykład takimi jak górna grafika na stronie Play24 w Google Play.
Efekt
Minął tydzień od premiery Play24, opinie na jej temat są w przytłaczającejwiększościpozytywne, nawet w komentarzach pod recenzjami, na Twitterze i w App Store (średnia 4.5 gwiazdki na 5 możliwych). Po 5 dniach od premiery aplikacja znalazła się na pierwszym miejscu w kategorii darmowych Utilities w polskim App Store oraz na ósmym w podobnym zestawieniu w Google Play.
W tym miejscu chcę podziękować wszystkim z którymi miałem przyjemność pracować przy Play24 – przede wszystkim pełnej otwartości na nowości ekipie Play i mojemu zespołowi w LoveMobile i o2. Efekt przerósł moje osobiste oczekiwania, ale wiem, że nie byłoby to możliwe, gdyby nie Wasza ciężka praca, 150% zaangażowania i ambicja aby stworzyć coś niesamowitego. Chyba nam się udało:)
