Niedawno obejrzałem wystąpienie o design engineeringu, które nazwało coś, co czuję od dawna. W sposobie, w jaki większość zespołów buduje software, jest luka i od dłuższego czasu mnie to uwiera.
Układ wygląda tak: masz projektantów, którym mocno zależy na tym, jak coś wygląda, i inżynierów, którym mocno zależy na tym, jak coś działa. Obie grupy są dobre w tym, co robią. Problem w tym, że nie mówią tym samym językiem. Projektant przekazuje plik z Figmy frontend developerowi, który nie do końca czuje typografię czy systemy spacingu. Inżynier próbuje wyjaśnić ograniczenia paginacji projektantowi, który nigdy nie musiał myśleć o zarządzaniu stanem. I gdzieś w tym handoffie, w tej luce między tymi dwoma światami, jakość po cichu umiera.
Design engineerowie żyją dokładnie w tej luce.
Kim właściwie jest design engineer?
Nie ma jednej idealnie czystej definicji, ale sedno jest proste: design engineer to osoba, która płynnie porusza się zarówno w kodzie, jak i w designie i nie traktuje tych obszarów jako osobnych bytów. To tłumacz. Potrafi spojrzeć na makietę z Figmy i już widzieć w głowie drzewo komponentów. Potrafi wziąć chaotyczne API backendowe i zamienić je w coś, z czego po prostu dobrze się korzysta.
Co ciekawe, design engineerowie nie są tacy sami. To całe spektrum. Część ludzi ma obsesję na punkcie ostatniej mili dopracowania — biorą feature, która jest „gotowa”, i dodają animacje, przejścia oraz drobne detale, które nadają jej życie. Inni siedzą głęboko w design systemach, budują biblioteki komponentów i dbają, żeby codebase był tak samo czysty i spójny jak sam produkt. Obie ścieżki są potrzebne. Wspólny mianownik jest jeden: wszyscy dbają o to, jak interfejs się czuje, i walczą o to dodatkowe dziesięć procent, które większość pomija.
Czym to się różni od frontend engineera albo projektanta?
Słuszne pytanie. Frontend engineer dostaje projekt i go implementuje. Sprawi, że będzie działać, będzie zgodne ze specyfikacją, będzie dowiezione. Często jednak brakuje mu wyczucia (za chwilę o tym), żeby samodzielnie podejmować decyzje o rzeczach, których nie było w specyfikacji. Większość projektów w Figmie jest statyczna. Nikt nie rozpisał, co się dzieje, gdy przycisk przechodzi ze stanu loading do in-progress i done. Frontend engineer widzi trzy stany i implementuje trzy stany. Design engineer widzi okazję, żeby ten drobny moment zamienić w coś zapamiętywalnego.
Full stack engineer ma umiejętności rozłożone jeszcze szerzej, od backendu po frontend. Próbuje dowieźć produkt i często prześlizgnie się po detalach, na których design engineer będzie siedział dłużej.
A projektanci? Ich praca kończy się w Figmie. Potrafią stworzyć coś pięknego, ale nie da się przeglądać strony internetowej w Figmie. Design engineer może rzecz zaprojektować i zbudować. Ten etap przekazania pomiędzy po prostu znika.
Dlaczego ta rola jest realnie potrzebna
Dla mnie najmocniej wybijają się trzy powody.
Problem slopu. W tej chwili toniemy w śmieciu generowanym przez AI. Ktoś odpala narzędzie do kodowania z AI, wpisuje „zrób mi stronę”, i dostaje fioletowe gradienty, zły spacing, niespójne kolory i kiepski copywriting. I najważniejsze: zwykli ludzie to czują. Może nie potrafią nazwać problemu, ale wiedzą, że coś jest nie tak. Nie ma tam ludzkiego ciepła. Design engineerowie są linią obrony przed tym zjawiskiem. Dopilnują, żeby to, co ląduje na produkcji, wyglądało jak zrobione z intencją, a nie przypadkiem.
Wyczucie. To jest najważniejsze i warto się przy tym zatrzymać. W wystąpieniu była świetna demonstracja dwóch wersji przycisku przechodzącego między stanami. W jednej wersji zmieniał się tylko tekst, a kontener miał stałą szerokość. W drugiej kontener płynnie dopasowywał się do nowej treści. Większość aplikacji albo zrobiłaby przycisk full-width, żeby ominąć temat, albo całkowicie odpuściła transition. Design engineer widzi ten moment i myśli: „tu mogę dodać coś, co ludzie zapamiętają”.
Szybkość. Dzięki narzędziom AI design engineerowie mogą szybko wejść w nieznany teren. Osoba z talku zbudowała pełne sound lab oparte o Web Audio API, mimo że wcześniej nie miała doświadczenia z sound designem. Przed AI to były minimum dwa tygodnie researchu. Teraz to kilka godzin. Ale kluczowy punkt jest taki: output z AI był brzydki. Surowe przyciski, brak stylu. Zadaniem design engineera było wstrzyknięcie wyczucia: inne akcenty kolorystyczne, morphing elementów, drobne smaczki, które zamieniają funkcjonalne narzędzie w doświadczenie. Ta ostatnia warstwa to różnica między „działa” a „ludzie lubią tego używać”.
OK, ale czym właściwie jest „wyczucie”?
Wyczucie to słowo, które często pojawia się online i wywołuje dziwne dyskusje. A to jest prostsze, niż zwykle się wydaje.
W talku pojawiła się analogia do znanego producenta muzycznego, który był przy powstawaniu wielu największych utworów. Problem w tym, że on sam nie jest typowym muzykiem. To raczej gość, do którego ludzie przychodzą z pytaniem: „to jest dobre czy słabe?”. I ufają jego osądowi. To właśnie wyczucie. Jako design engineer musisz być osobą w pokoju, która potrafi dostać projekt i powiedzieć: „zróbmy krok w tył, spróbujmy inaczej, poeksperymentujmy”. Potrzebujesz tego opiniotwórczego oka.
I to był świetny fragment: prowadzący mocno podkreślał, że wyczucie nie jest czymś wrodzonym. Można je wytrenować. Trzy drogi:
Studiuj. Oglądaj najlepsze produkty. Nie tylko ich używaj, ale analizuj. Spróbuj zrozumieć, dlaczego one dobrze się czują. Co robi typografia? Jaki jest timing animacji? Z czasem budujesz wrażliwość i wewnętrzne archiwum decyzji. W talku był fajny moment, gdy prowadzący przybliżył nawigację znanego produktu i zauważył, że podczas transition wewnętrzna treść delikatnie wychodzi poza kontener. Drobiazg, prawie niewidoczny. Taki wzrok bierze się z lat obserwacji i budowania.
Zauważaj. Trenuj się w wychwytywaniu niespójności. Było demo z trzema animowanymi elementami, gdzie dwa skrajne miały ten sam timing, a środkowy był lekko inny. Większość ludzi nie wyłapie tego świadomie, ale poczuje, że coś „nie gra”. To ten moment, kiedy użytkownik mówi „coś tu dziwnie działa”, ale nie umie wyjaśnić dlaczego. Design engineer powinien umieć to nazwać.
Buduj. Kopiuj najlepsze rzeczy. Jest to powiedzenie o kradnięciu jak artysta. Weź ciekawą interakcję z cudzej aplikacji, odtwórz ją, zmień kolory, zrób swoją wersję. Jeśli powtórzysz to wystarczająco wiele razy, zaczynasz budować instynkt: kiedy użyć sprężynowej animacji, kiedy spokojniejszego easing curve, kiedy zacieśnić letter spacing, a kiedy nic nie dotykać.
Balans między formą a funkcją
Mocno wybrzmiał dla mnie wątek o tym, kiedy nie dodawać animacji. Prowadzący opowiadał o błędzie z początku kariery, kiedy miał obsesję na punkcie blur effects i chciał, żeby wszystko się „morfowało”. Manager powiedział wtedy: „to nie jest to, czego ten produkt potrzebuje. Ludzie chcą czegoś szybkiego i ostrego”.
To totalnie zmienia perspektywę. Jeśli budujesz narzędzie używane setki razy dziennie, piękny loading spinner jest fajny za pierwszym razem i irytujący za setnym. To jak nieskipowalna cutscenka w grze — po chwili tylko spamujesz przycisk, żeby to przeszło.
Dobry model myślenia jest taki: nowość ma malejące korzyści. Jak power-up w platformówce, który pojawia się raz na level. Gonisz go, bo jest rzadki. Gdyby był wszędzie, nikogo by nie obchodził. Na landing page'u możesz sobie pozwolić na bardziej efektowne wejście. Ale w aplikacji używanej codziennie najlepszą animacją może być brak animacji. Gdy ludzie chcą po prostu załatwić sprawę, szybkość jest formą.
Jak realnie zostać design engineerem
Jeśli jesteś projektantem, masz przewagę na starcie. Masz już oko. Najtrudniejsze dla ciebie będzie nauczenie się zamiany projektu na działający kod. Zacznij od małych rzeczy. Weź coś, co zaprojektowałeś i spróbuj to zbudować, nawet jeśli na początku będzie toporne. Użyj AI, żeby skrócić drogę. Z czasem zaczniesz projektować w Figmie i równolegle widzieć, jak to będzie wyglądało w kodzie.
Jeśli jesteś inżynierem, masz drugą połowę kompetencji. Twoim zadaniem jest wytrenować oko. Studiuj produkty, których używasz codziennie. Zadawaj sobie pytanie, dlaczego wybrali taki font, taki spacing, taki styl przycisku. Potem próbuj odtworzyć te decyzje w swojej pracy.
Niezależnie od punktu startu, uczysz się przez budowanie. Jeśli nie budujesz, to się nie uczysz.
Temat portfolio
Tu też padł mocny konkret. Jeśli chcesz pokazać, że jesteś design engineerem, nie wrzucaj tylko wygładzonych mikrointerakcji na stronę portfolio. Pokaż, że naprawdę cię to kręci. Publikuj eksperymenty, nawet niedoskonałe. Pokazuj progres. Ludzie chcą zobaczyć troskę i konsekwencję, drogę od surowych prób do obecnego poziomu. Pokaż inspirację, pokaż swoją wersję, dodaj własny charakter. Taka autentyczność wyróżnia bardziej niż idealna siatka komponentów bez osobowości.
Dokąd to wszystko zmierza
Myślę, że idziemy w stronę świata, w którym większość zespołów produktowych będzie miała design engineerów jako rdzeń zespołu, a nie miły dodatek. AI sprawia, że każdy może wygenerować funkcjonalną stronę w kilka minut, więc próg „to działa” leży dziś praktycznie na podłodze. To, co odróżni dobre produkty od zapomnianych, to warstwa ludzka: troska, wyczucie i poczucie, że komuś naprawdę zależało na tym, jak z tego korzystasz.
Jesteśmy w trochę dziwnym momencie, czymś w rodzaju renesansu. Narzędzia do tworzenia nigdy nie były tak dostępne, ale przez to mamy też więcej szumu niż kiedykolwiek. Ludzie, którzy potrafią przebić się przez ten szum, budując rzeczy autentycznie dopracowane i autentycznie ludzkie, tam właśnie przesuwa się wartość.
No i tyle. Idź przeanalizować kilka stron. Skopiuj coś dobrego. Dowieź coś brzydkiego i potem zrób to mniej brzydkim. To w zasadzie cały playbook.