Pewnego wieczoru w drugiej połowie maja odpaliłem aplikację na telefonie — tę samą, którą buduję od września — i przez sekundę pomyślałem, że zainstalowałem jakąś starą wersję. Splash, czyli ekran powitalny, wyświetlił mi imię produktu, którego już od dawna nie używam. Tego sprzed kilku miesięcy. Logo odbijało się od dołu z animacją „pop-up” zerżniętą z bibliotek do prezentacji. Czcionka systemowa, ta sama, którą widzi się w trzech czwartych aplikacji bankowych. Wszystko grzeczne, wszystko standardowe, wszystko zupełnie nie to.
A jednocześnie w tym samym repozytorium — wręcz w tej samej gałęzi — leżał od dawna brand book. Dokument, który spisywałem jeszcze zimą. Mówił dokładnie: font Poppins, paleta cieplej-ziemista, animacja inspirowana papierem opadającym na biurko (nie bounce, nie elastycznym odbiciem), logo w prostokącie z grubą obwódką — bo cała estetyka produktu ma być brutalistyczna, nie miękka, nie korporacyjna.
Brand istniał. Aplikacja go nie odzwierciedlała.
Lista rozjazdów
Zacząłem spisywać. Po godzinie miałem listę, którą wstyd było czytać.
Font — brand book mówił Poppins. Aplikacja nigdy go nie zaimportowała, więc Flutter rzutował na czcionkę systemową — Roboto. Nie była brzydka. Była anonimowa. Akurat tego, czego brand miał uniknąć.
Splash — animacja „bounce”, okrągłe logo, stare imię produktu, gładkie przejście do dashboardu. Każdy z tych czterech elementów łamał inną zasadę z brand booka. Stare imię — bo zmieniliśmy je, ale ekran powitalny nigdy o tym nie dowiedział. Bounce — bo „papier nie odbija się”. Okrągłe logo — bo wszystkie elementy mają być prostokątne z grubymi obwódkami. Gładkie przejście — bo brak momentu „odznaczenia” przejścia (a senior potrzebuje zauważyć, że coś się stało).
Ikony — w połowie ekranów korzystałem z domyślnego zestawu ikon Material Library, która ma jeden styl. brand book mówił: jeden spójny zestaw ikon w wariancie „outlined”, zgodny z brutalistyczną estetyką. Ikony też dryfowały, każdy ekran dostawał te, które programista (czyli ja, czasem o północy) akurat pamiętał.
Onboarding — nie istniał. User po pierwszym uruchomieniu lądował na pustym dashboardzie bez tłumaczenia, czego się patrzy. Bez powitalnej sceny, bez ikonki „i” na ekranach, bez podpowiedzi. Mieliśmy dokumentację mówiącą, jaki powinien być pierwszy moment — i nic, co by jej odpowiadało w kodzie.
Jeden wieczór, dwa tematy, sześć sprintów
Dwa zadania, które od dawna były na liście — w głowie pod nazwami „dogonić brand” i „onboarding od zera” — zrobiłem w jeden, długi wieczór. Każde rozłożyłem na kilka mniejszych sprintów, znowu po znanej już zasadzie „jeden commit, jedna decyzja”.
Sprint pierwszy, pisanie podstawy: dodanie biblioteki czcionek, podpięcie
Poppins, ujednolicenie ikon przez Material Symbols (drugi zestaw, ten
z brand booka). Wszystkie ekrany przeszły bez żadnej zmiany w treści —
wystarczyło, że temat aplikacji odwoływał się teraz do właściwych zasobów.
Efekt był natychmiastowy: aplikacja przestała wyglądać jak generic banking app.
Sprint drugi — splash. Wymyśliłem od nowa, żeby był zgodny z brand bookiem: kremowa kartka wjeżdża z góry, pieczęć ląduje na środku z lekkim opadaniem. „Paper Drop” — bo dokładnie tak miało wyglądać. Bez bounce. Bez okrągłego logo. Z prawdziwym nowym imieniem produktu, drukowanymi literami w bloku.
Trzeci sprint — mała ikonka pomocy na każdym ekranie. W prawym górnym rogu, każdy ekran ma własny krótki tekst tłumaczący, co tu robi. Wzorzec podpatrzony z banków (tych, które robią to dobrze) i z aplikacji rządowych — tam, gdzie zakłada się, że użytkownik może być nowy przy każdym ekranie, a nie tylko na pierwszym uruchomieniu.
Czwarty — feature tours. Po pierwszym otwarciu konkretnej sekcji aplikacji wyskakuje krótka, dwu-trzy ekranowa animacja tłumacząca, czemu ta sekcja istnieje i jak działa. Zamiast onboarding-monolitu na powitanie, którego nikt nie czyta — onboarding na żądanie, dokładnie wtedy, kiedy user spotyka tę funkcję po raz pierwszy.
Piąty — ilustracje. Empty states (np. „nie masz jeszcze żadnych ogłoszeń”) dostały ręcznie wyglądające rysunki zamiast generycznych kafelków „nic tu nie ma”. Animowane przejścia między stanami, żeby przejście „pusty → coś się pojawiło” było widoczne, nie nagłe.
Szósty — dokumentacja. Co kiedyś było luźnym brand bookiem, teraz jest też katalogiem komponentów, w którym każdy element ma referencję do brand booka. Następna osoba (albo ja za pół roku) nie musi szukać. Otwiera komponent, widzi notkę „zgodnie z brand book §3.2 — paleta ziemista, font Poppins, animacja papierowa”.
Co naprawdę znaczy „aplikacja ma brand”
Najważniejsza lekcja z tego wieczoru nie była techniczna. Brand istnieje tylko wtedy, gdy implementacja mu odpowiada. brand book to nie jest brand — to jest opis brandu. Aplikacja, która ignoruje opis i pokazuje coś innego — nie ma brandu. Ma chaos pomalowany dobrze brzmiącym dokumentem.
To brzmi banalnie, ale jest jednym z najczęstszych miejsc, w których solo founderzy się gubią. Spisujemy w pierwszym tygodniu „identyfikację wizualną”, potem zaczynamy pisać kod i każdy nowy ekran odtwarza brand z pamięci. Pamięć pracuje średnio. Po trzech miesiącach ekran wygląda inaczej niż dokumentacja, po sześciu — inaczej niż wcześniejsze ekrany, po dziewięciu — nie wygląda już nijak.
Lekarstwem nie jest dyscyplina (nie pomaga). Lekarstwem są komponenty i tokeny (font, paleta, animacja, ikony) jako jedyne źródło prawdy w kodzie — tak, żeby napisanie ekranu „nie po brandzie” wymagało aktywnego wysiłku, a nie było domyślnym zachowaniem.
W maju nadrobiłem to wszystko jednym wieczorem. Następnym razem nadrobię to zaraz po napisaniu brand booka, nie po pół roku.
Najfajniejsze jest to, że przyszły użytkownik niczego z tego nie zobaczy. Otworzy aplikację, zobaczy kartkę opadającą z góry, pomyśli „o, coś ciekawego” — i pójdzie dalej, szukać, czy hydraulik z trzeciej ulicy ma czas we wtorek. Nie będzie wiedział, że jeszcze miesiąc wcześniej witała go animacja, która wyglądała jak wszystko inne na rynku. To jest dokładnie ten rodzaj różnicy, której się nie zauważa świadomie — a działa.