W systemie projektowym aplikacji od dawna leży jeden token:
animationSlow = 350 milisekund. Stoi tam, bo zaprojektowałem aplikację
z myślą o trybie senioralnym — co czwarta osoba w potencjalnym
sąsiedztwie ma 60+ lat. Wolniejsza animacja to nie ozdoba. To czas potrzebny,
żeby zauważyć, że coś się wydarzyło, i nie zgubić się w przejściu.
Przy audycie UX, który zrobiłem na początku kwietnia, otworzyłem pliki ekranów powitalnego i logowania. W obu — hardcoded 150 milisekund. Wpisane ręcznie, twardo, bez sięgnięcia po token.
Sprawdziłem dalej. Sytuacja powtarzała się na większości ekranów.
System projektowy istniał. Kod o nim nie wiedział
Token został zdefiniowany dawno temu, w jednym pliku, jako pojedyncze źródło prawdy o tym, jak długo ma trwać „wolna” animacja w aplikacji. Każdy deweloper, który pisałby kolejny ekran, miał po niego sięgnąć — i ekran automatycznie respektowałby tryb senioralny.
Ale dewelopera nie było. Był ja, pracujący z AI, w trybie sprintów, w którym co kilka godzin powstawał nowy ekran. Każdy ekran w izolacji. Każdy potrzebował animacji. Każdy dostawał ją z głowy — bo „chcę żeby było płynnie” — i domyślną liczbą po stronie programisty jest 150 albo 200, bo tak się robi „fajne”, responsywne UI.
Token istniał i był ignorowany — bo nikt nie spisał reguły kiedy go używać. Design system był jak biblioteka, do której nikt nie zagląda, bo nie ma oznakowania, gdzie co stoi.
To boli, dopiero gdy zobaczysz to oczami osoby, dla której pisałeś
Z perspektywy 30-latka 150 ms vs 350 ms to detal. Praktycznie nieodróżnialny.
Z perspektywy 70-latka — to różnica między „widzę, jak ekran się zmienia” a „nie wiem, czy coś się stało, czy aplikacja się zepsuła”. Wolniejsza animacja daje czas na rozpoznanie: aha, teraz przechodzimy z menu do listy ogłoszeń. Szybka po prostu odpala kolejny widok bez bramy między nimi.
A jednocześnie, w drugiej części tego samego audytu, wyszło coś gorszego: w menu istniał link „Moje treści”, a w głównej zakładce był ekran „Moja aktywność” pokazujący te same rzeczy. Dwie nazwy, jedno miejsce — senior otwiera apkę i nie wie, dokąd ma kliknąć po własne ogłoszenie. To nie była literówka. To było złamanie najprostszej zasady: jedna rzecz, jedna nazwa, jedno miejsce.
Fix był szybki. Lekcja zostanie
Sprzątanie zajęło kilka godzin. Każde miejsce z hardcoded wartością czasu animacji poszło przez token. Menu i ekran „Moja aktywność” dostały jeden spójny szyld. Aplikacja zaczęła w końcu robić to, co od dawna było zapisane w jej dokumentacji.
Lekcja, która została na dłużej, brzmi tak: design system nie działa przez samo istnienie. Token w pliku to nie reguła. Regułą jest commit hook, który blokuje hardcoded wartości czasowe w kodzie. Albo lint, który podpowiada „użyj tokenu animationSlow zamiast wpisywać 150”. Albo — najprostsze, najtańsze — pisemna notatka u góry pliku ekranu: „animacje przez token animationSlow, nie ręcznie”.
Nie zrobiłem żadnego z tych trzech zabezpieczeń, gdy zakładałem token. Założyłem, że pamiętanie wystarczy. Pamiętanie nigdy nie wystarcza — nawet w jednoosobowej firmie, gdzie pamiętać ma tylko jedna głowa. A może zwłaszcza tam, bo nie ma drugiej osoby, która by przy code review zapytała: „czemu nie token?”.
Czyjaś babcia, która kiedyś otworzy tę apkę, żeby zobaczyć, czy hydraulik z trzeciej ulicy ma czas w czwartek — nigdy nie dowie się, że istniał ten audyt. Po prostu nie zgubi się w przejściu między ekranami. A to jest dokładnie to, do czego ten token był od początku.