Overengineering w designie. Dlaczego sami sobie szkodzimy

Mam alergię na przekombinowanie. Widzę je wszędzie: w UI i kodzie, w brandingu, w marketingu. I czasami sam się na tym łapię.

Brand book na 60 stron dla 5-osobowej firmy.
Onboarding na 7 ekranów dla aplikacji z trzema funkcjami.
Persona której nikt nigdy nie spotka.

Brzmi znajomo? To overengineering w czystej postaci.
Większość z nas robi to nie dlatego, że chce, tylko dlatego, że tak działa nasz mózg.

Czym jest overengineering w UX?

Overengineering to robienie rzeczy bardziej skomplikowanych, niż faktycznie tego wymagają. Wspólny mianownik jest jeden: dorzucamy rzeczy, których nikt nigdy nie użyje, na sytuacje, które się nigdy nie wydarzą.

Steve Krug napisał biblię UX, „Nie każ mi myśleć".
Sam tytuł mówi wszystko: dobry projekt nie zmusza usera do myślenia. A jednak wolimy dodawać jeszcze więcej.

Dlaczego twój mózg dodaje, zamiast odejmować

W 2021 roku w Nature ukazało się badanie, które zmienia rozmowę o przekombinowaniu.
Klotz, Adams, Converse i Hales przeprowadzili osiem eksperymentów na 1500 osobach. Zadanie: ulepsz konstrukcję z klocków albo zmień projekt tak, żeby zadziałał lepiej.

Wynik był jednoznaczny. Większość ludzi domyślnie szukała rozwiązania przez dodawanie, nie przez odejmowanie. Co ważniejsze, ci ludzie nie odrzucali świadomie opcji odjęcia. Oni jej w ogóle nie widzieli.

Najmocniejsza liczba z badania: w wersji bez podpowiedzi tylko 41% osób próbowało rozwiązać zadanie odejmowaniem. Wystarczyło dorzucić jedno zdanie („usuwanie elementów jest darmowe"), żeby wskaźnik skoczył do 61%.

Complexity bias. Bo skomplikowane wygląda mądrzej

Ten drugi mechanizm działa w parze z pierwszym. Mózg traktuje skomplikowane wyjaśnienia jako bardziej wiarygodne, bardziej profesjonalne, bardziej zasłużone na zaufanie.

Marketingowcy doją to od dekad.

Krem „z peptydami" sprzedaje się lepiej, choć większość kupujących nie wie, czym są peptydy.
Farba do włosów „ammonia-free" wygląda na bezpieczniejszą, choć większość farb amoniaku nigdy nie miała.
Mleko „wzbogacone wapniem" brzmi pro, mimo że każde mleko ma wapń.

Ten sam mechanizm robi twoja agencja, kiedy sprzedaje brand book na 60 stron zamiast jednostronicowego brand summary. Robisz to ty, kiedy odrzucasz proste rozwiązanie, bo „wygląda jakby ktoś za mało popracował".

Cargo cult. Robisz jak Apple, choć nie jesteś Apple

Termin „cargo cult" powstał po II wojnie światowej. Mieszkańcy wysp Pacyfiku obserwowali, jak amerykańskie samoloty przywożą żołnierzom jedzenie, ubrania i sprzęt. Po wojnie samoloty przestały lądować. Tubylcy zbudowali więc z bambusa atrapy pasów startowych, wież kontrolnych i słuchawek, wierząc, że jeśli odtworzą rytuał, samoloty same wrócą.

Zupełnie jak twój szef, który wpada do biura i mówi „w X firmie robią to tak, my też tak zróbmy".

W branży kreatywnej cargo cult to plaga.

Figma ma rozbudowany design system, więc mikro studio jogi też „musi"
Apple robi mikrointerakcje na każdym przycisku, więc landing page dla księgowej też ich potrzebuje
Allegro ma onboarding na 5 ekranów, więc twoja aplikacja z jedną funkcją też

Skopiowałeś formę, pominąłeś powód. Figma ma design system, bo zatrudnia setki osób i ich produkt to platforma używana przez miliony designerów. Bez systemu zostałby chaos. Ty masz dwie osoby i trzy ekrany. Twój „design system" to dziesięć minut w Figmie i pięć kolorów w stylach.

I co gorsza, cargo cult często nie jest twoją decyzją. Klient przychodzi z briefem „a zróbmy to jak w ...". Agencja sprzedaje proces skopiowany z gigantów, bo tak się sprzedaje drożej. Tymczasem ty wiesz, że tej skali nie ma, i że ten proces nie będzie używany.

Dlaczego boimy się robić prościej?

Składa się na to kilka warstw psychologicznych:

Strach przed porażką. Każde “co jeśli” dodaje złożoności, a hipotetyczny edge case może nigdy się nie wydarzyć. Ból porażki bije radość z dowiezienia. To klasyczna asymetria opisana przez Daniela Kahnemana.
Sygnalizacja kompetencji. Proste rozwiązanie wygląda jak ściema. Skomplikowane wygląda jak „wiem, co robię".
Niejasny brief. Klient nie wie, czego chce, więc projektant „zabezpiecza wszystkie scenariusze". Tak rodzą się design systemy zbudowane pod produkt, którego jeszcze nie ma.
Krzywa doświadczenia. Junior jeszcze nie wie, jak overengineerować, więc zostawia projekt prostym. Senior widział, jak to wybucha kilka razy, więc wie, czego nie ruszać. Najgorsi paradoksalnie nie są początkujący, tylko mid-levele.

Jak przerwać tryb overengineeringu?

„Czy spełniłem podstawowe zadanie i czy nadal to działa, jak coś usunę?".

Brzmi banalnie ale nie jest.

Nie wpadaj w kult. Konwencje i standardy to co innego niż kopiowanie tego, co robi gigant. Twoja firma może ich ficzerów po prostu nie potrzebować.
YAGNI. You Aren't Gonna Need It. Zasada z extreme programmingu z lat 90. Nie buduj funkcji ani abstrakcji, dopóki naprawdę jej nie potrzebujesz. Każde „przyda się" przelicz przez „kiedy konkretnie i ile mnie to kosztuje teraz". Najczęściej okazuje się, że nigdy.
Zignoruj n=1. Jeśli jeden user prosi o ficzer, zapomnij. Jeśli dziesięciu, zanotuj. Jeśli stu, pochyl się nad tematem. Pojedynczy hipotetyczny scenariusz nie zasługuje na trzy tygodnie pracy. Wielu managerów się łapie na n=1.

Kiedy overengineering jednak ma sens

Żeby być fair, są sytuacje, w których lepiej dodać niż żałować. Lotnictwo, medycyna, automotive. Boeing nie ma trzech systemów hydraulicznych, bo lubi komplikację, tylko dlatego, że jeden zawodzi raz na miliard godzin lotu, a po niebie lata milion ludzi rocznie.

Tylko że to mniej niż 5% świata projektowego. Reszta to małe i średnie biznesy, freelancerzy, agencje, jednoosobowe brandy. Dla nich overengineering nie jest zabezpieczeniem przed katastrofą, tylko sposobem na utopienie czasu i budżetu w czymś, czego nikt nie zobaczy.

Podsumowanie

Overengineering w UI, UX, brandingu i designie to systematyczne dodawanie warstw, których nikt nie potrzebuje. Wynika z trzech mechanizmów psychologicznych: addition bias (badanie Klotz et al., Nature 2021, n=1500), complexity bias (skomplikowane = wiarygodne) i cargo cult (kopiowanie procesu firm z innej skali). Steve Krug w „Don't Make Me Think" sformułował podstawową zasadę UX: dobry interfejs to taki, którego user nie musi rozszyfrowywać. Najgorsi w overengineeringu są mid-level designerzy/developerzy, nie juniorzy ani seniorzy. Sposób na przerwanie: pytanie „co mogę zamiast tego usunąć?" przed każdą decyzją projektową. Dodatkowo zasady YAGNI, ignorowanie n=1 user requests i odróżnianie standardów od cargo cultu. Wyjątek: branże o wysokiej stawce (lotnictwo, medycyna), gdzie redundancja to obowiązek, nie grzech.