Właściwe narzędzie do zadania: prawdziwy wróg to przekombinowanie
Niedawno audytowałem UX ciekawego produktu. Między innymi przechodziłem onboarding. Nie po to, żeby podziwiać, tylko sprawdzić, czy działa.
Zauważyłem nie wzorzec designu ani bibliotekę komponentów, lecz decyzję. Zamiast pełnego interaktywnego onboardingu z własnym kodem, mockami, gimnastyką z iframe’ami i nieskończonymi akceptacjami zrobili coś znacznie mądrzejszego.
Skopiowali istniejący UI kit w Figmie, zbudowali klikalny prototyp i użyli go jako onboardingu.
Bez czasu programistów. Bez backendu. Bez dymu i luster. Sama jasność.
Wtedy trafiła do mnie mądrość Daniego Rojasa, już nie o partyzantce, lecz o produkcie:
> „Właściwe narzędzie do właściwego zadania. Reszta to zmarnowane naboje”. — Dani Rojas, Far Cry 6.
Nie chodziło o software, ale cholera, pasuje idealnie.
Dlaczego to było genialne
W liczbach: 3–4 dni na złożenie. 0 godzin inżynierskich na kod onboardingu. Bez CI/CD, cykli QA, mocków i planowania sprintów.
Natywna implementacja oznaczałaby tygodnie frontendu, endpointy lub mockowane dane, QA i regresję, pipeline’y CI/CD, akceptacje interesariuszy oraz ból głowy dla wszystkich.
Zamiast tego: Figma → prototyp → link → gotowe.
Cel onboardingu nie wymagał fabryki. Wymagał drzwi.
Zasada, o której zapominamy
Ludzie mylą narzędzia z kompetencjami.
Wiedzieć, czego użyć, to umiejętność. Wiedzieć, czego nie używać, to mistrzostwo.
Jasności nie tworzą narzędzia. Tworzą ją decyzje.
Prawdziwy wniosek
Jeśli zadanie wymaga maczety, nie przynoś wyrzutni rakiet. Jeśli potrzebujesz prototypu, nie zatrudniaj trzech programistów do budowy imperium.
I na bis: właściwe narzędzie do zadania to nie frazes. To strategia, która się skaluje. Reszta jest ego w technicznym przebraniu.
