Od wczesnej Figmy do design engineering w Windsurf

Notatki z podcastu Dive Club, w którym Andy Zhang, design engineering lead w Windsurf, opowiada o swojej ścieżce kariery, filozofii produktu i praktycznych aspektach pracy na styku designu i engineeringu. Wszystkie przemyślenia, obserwacje i strategie przedstawione w artykule pochodzą od rozmówców podcastu.

TL;DR

Kultura mentoringu w wczesnej Figma pozwalała stażystom podążać za ciekawością zamiast tylko wykonywać zadania
Design engineering to „woda w kubku” – wypełnianie luk w zespole między debuggingiem a strategicznym myśleniem
Użytkownicy preferują 2–3 świetne funkcje nad 500 przeciętnych – sukces tkwi w wzorcach projektowych
Wzorce należy ustanawiać wcześnie – późniejsze dodawanie jest kosztowne technicznie i dla użytkowników
Kultura bez ego napędza innowacje – zespoły współpracują lepiej i tworzą produkty przewyższające sumę części
AI zmienia sposób myślenia – różne narzędzia umożliwiają odmienne podejścia do problemów
Kod przestaje być barierą dla designerów – kluczem jest rozbijanie systemów na atomowe części

Mentoring jako fundament kariery w tech

Andy Zhang trafił do Figmy jako jeden z pierwszych stażystów, gdy startup liczył mniej niż 10 osób. Jego mentor Jessica reprezentowała podejście wyróżniające kulturę firmy.

Zhang wspomina, że typowe myślenie o stażach polega na otrzymywaniu zadań do wykonania. W Figma jednak miał możliwość podążania za własną ciekawością. Jessica z własnej inicjatywy dopytywała o zainteresowania i dostosowywała projekty do celów rozwojowych. Następnego dnia wracała z zadaniami idealnie dopasowanymi do tego, czego Zhang chciał się nauczyć.

Szczegół jako obsesja

Kultura uwagi na detale w wczesnej Figma była legendarna. Zhang opisuje dwugodzinną debatę z Rasmusem nad wyborem między słowami „delete” i „remove” w interfejsie. Rasmus analizował każdą fizyczną analogię związaną z tymi słowami.

Ta obsesja na punkcie detali stanowiła normę, nie wyjątek. Przykłady tej kultury obejmowały:

2-godzinne debaty nad jednym słowem w interfejsie użytkownika
Spontaniczne lekcje – Rasmus rysował przy lunchu schemat działania kompilatorów Go
Sesje po pracy – Evan Wallace tłumaczył multiplayer i operational transforms
Brak wahania w podchodzeniu do każdego z pytaniami technicznymi

Design engineering jako odpowiedź na potrzeby produktu

Historia koszykówki i networking

Zhang trafił do Windsurf w nietypowy sposób – przez grę w koszykówkę. Podczas przerwy w poszukiwaniu pracy wspomniał koledze z drużyny o poszukiwaniu roli w product design/engineering.

Kevin Howe, lead engineer w Windsurf i świetny koszykarz, tej samej nocy przysłał opis roli. Mimo braku formalnego job description, zaproponował szybkie działanie. Po rozmowach kwalifikacyjnych w piątek, zadaniu rekrutacyjnym w weekend i rozmowie w siedzibie firmy w poniedziałek, Zhang podpisał kontrakt i poleciał do Azji tej samej nocy.

Ewolucja roli

W Windsurf Zhang zaczynał jako „growth engineer”, jednak rola ewoluowała naturalnie w kierunku design engineering. Kluczowym momentem było dostrzeżenie problemów, o których nikt nie myślał – głównie związanych z designem. Zhang przyjął filozofię: jeśli nikt nie będzie o nich myślał, to on zacznie o nich myśleć.

Woda w kubku

Zhang opisuje swoją rolę metaforą: inni inżynierowie w zespole to kamienie, a on stara się być wodą wypełniającą luki. Czasami oznacza to pisanie kodu, czasami debugging, a czasami strategiczne myślenie o produkcie. Kluczem jest elastyczność i brak przywiązania do konkretnej domeny.

Context switching jako filozofia

Zhang nie lubi przełączania kontekstu. Gdy projektuje dla wielu projektów, chce mieć pewność, że inżynierowie mogą skupić się tylko na swoich zadaniach. Dlatego często koncentruje się na bugach – to małe, atomowe zadania pozwalające innym zachować focus na większych projektach.

Filozofia produktu: mniej znaczy więcej

Jedna z najważniejszych lekcji Zhang wynikała z obserwacji zachowań użytkowników. Ludzie nie chcą tysiąca funkcji – preferują 2–3 naprawdę dobre.

Analogia McDonald’s

Zhang ilustruje to prostą analogią: podczas wizyty w McDonald’s nie zamierza zapamiętać całego menu. Zna swoje ulubione zamówienie i może ma pięć–sześć ulubionych pozycji. Outlier może mieć ich dziesięć, ale menu zawiera zdecydowanie więcej opcji.

Ta obserwacja ma fundamentalne znaczenie dla projektowania produktów – użytkownicy mają ograniczoną pojemność mentalną i wolą opanować kilka wzorców dobrze, niż walczyć z dziesiątkami różnych funkcji.

AI obniża koszty budowania

Paradoksalnie, era AI sprawia, że łatwiej jest budować funkcje, ale trudniej utrzymać prostotę. Zhang obserwuje, że koszt tworzenia drastycznie spadł dzięki narzędziom takim jak Windsurf.

W rezultacie, jeśli celem jest zachowanie prostoty mentalnego modelu, należy mówić „nie” wielu rzeczom. W przeciwnym razie można osiągnąć różne cele w izolacji, ale kosztem tego, co buduje się na najwyższym poziomie.

User advocate vs. engineer advocate

Zhang podkreśla kluczowe rozróżnienie: celem nie jest reprezentowanie inżynierów, ale użytkowników. Oznacza to mówienie „nie” rzeczom konfliktującym z problemami użytkowników, nawet jeśli zespół jest podekscytowany możliwością ich zbudowania.

Wzorce vs. funkcje

Zhang wyróżnia dwa kluczowe elementy sukcesu produktowego: filozofie i wzorce. Bez nich zespoły wysokiej autonomii mogą skończyć z 500 różnymi funkcjami, które nie współgrają ze sobą.

Wzorce są szczególnie ważne, ponieważ użytkownicy uczą się ich raz, a następnie energia potrzebna do wykorzystania jest bardzo niska. Najtrudniejsze jest ustanowienie wzorca, ale później łatwo go rozszerzać.

Degrees of freedom vs. invariants

Zhang wykorzystuje framework myślowy z engineeringu: gdzie są stopnie swobody w produkcie, a gdzie niezmienniki?

Na przykład w produktach AI:

Niezmienniki: architektura LLM (tokens in, tokens out), struktura agent conversations
Stopnie swobody: konkretne tool calls, UI dla poszczególnych funkcji

Poprzez zrozumienie tych niezmienników można projektować wzorce, których stopnie swobody odpowiadają stopniom swobody systemu. Kiedy coś wykracza poza te ramy, można stworzyć bardziej dedykowane rozwiązanie.

Pułapka stopniowego dodawania

Najgorsze, co można zrobić, to dodawać funkcje A, B, C bez wzorca, a następnie myśleć o jego wprowadzeniu. Energia potrzebna do usunięcia wszystkich trzech i dodania wzorca jest znacznie wyższa niż dodanie funkcji D.

Efekt śnieżnej kuli sprawia, że zespół wybiera łatwiejszą opcję i dodaje kolejne niespójne funkcje.

Proces twórczy w erze AI

Zhang porównuje swój sposób myślenia do działania LLM. Jego proces zaczyna się od pytania: jakich informacji potrzebuję, żeby podjąć najlepszą decyzję? Pracuje wstecz, zbierając kontekst o systemach engineeringu, designie, użytkownikach i konkurencji.

✅ Proces decyzyjny design engineera

Zbieranie kontekstu:

[ ] Ile muszę wiedzieć o systemie engineeringu i designie?
[ ] Czy użytkownicy znają podobne produkty?
[ ] Jaki problem dokładnie rozwiązujemy?

Pierwsza decyzja – czy w ogóle budować:

[ ] Research vs. building cost – koszt budowania i designu jest znacznie wyższy niż research, który można zrobić dość szybko
[ ] Jak to pasuje do naszych priorytetów?
[ ] Czy lepiej powiedzieć „nie” i skupić się na czymś ważniejszym?

Określenie scope’u i wykonanie:

[ ] Czy to ma być duży launch, czy mały test?
[ ] Mini-PRD + design review z zespołem
[ ] Uruchomienie równoległych wątków pracy

Text vs. visual design

Zhang zauważa praktyczny trade-off: czasami designów najlepiej dzielić się w formie tekstowej. Nie zawsze muszą to być prostokąty i kółka – pisze znacznie szybciej niż rysuje w Figmie.

Kiedy wizja jest krystalicznie jasna, bullet point mówiący „przycisk robi to” jest czasami skuteczniejszy niż szczegółowy mockup. Celem jest komunikacja idei, niekoniecznie wizualna.

Narzędzia do myślenia

Wcześniej był tylko jeden dobry sposób myślenia dla ludzi, ale teraz istnieje wiele różnych podejść. Dzięki narzędziom dostosowanym do różnych typów myślenia, nie trzeba już dopasowywać swojego myślenia do jednego medium.

Różne punkty wejścia w proces projektowy obejmują:

Mini-PRD tekstowy – gdy wizja jest jasna, tekst jest szybszy niż Figma
Prototyp w kodzie – bezpośrednie budowanie, gdy wiadomo jak zaimplementować
Design w Figmie – dla złożonych interakcji z wieloma stanami
AI voice mode na spacerach – dystans od problemu, niesztampowe myślenie

Kluczem jest dopasowanie narzędzia do problemu, nie odwrotnie.

Time-boxing i priorytetyzacja

Od Rasmusa Zhang nauczył się intencjonalnego zarządzania czasem. Blokuje w kalendarzu 2–3 godziny na debugging, a po tym czasie przechodzi do strategicznej pracy.

Czasami najlepsze, co można zrobić dla pracy, to nie pracować przez chwilę i po prostu pójść na spacer.

Przykład: kompresja systemu UI

Zhang opisuje konkretny przypadek, gdy miesiącami myślał nad jednym problemem: jak skompresować cały system UI w bardzo mały toolbar nad input boxem z kilkoma różnymi ikonami?

Chciał wyświetlić różne funkcje agenta w różnych przypadkach użycia, ale zrobić to w sposób mieszczący się w bardzo skompresowanej przestrzeni. To pokazuje, jak głębokie myślenie o wzorcach może wymagać miesięcy refleksji, ale następnie daje fundament dla wielu funkcji.

Balansowanie wielu ról

Design engineering wymaga ciągłego przełączania się między różnymi trybami myślenia. Zhang opisuje to jako sztukę, nie naukę – każdy projekt wymaga innego procesu.

Kluczem jest zrozumienie, jak wygląda praca z perspektywy każdej osoby zaangażowanej w projekt. Jako designer wie, jak napisać dobry PRD. Jako engineer rozumie, ile czasu potrzeba na research techniczny.

Orkiestracja jako kluczowa umiejętność

Wiele z roli Zhang polega na próbie orkiestracji rzeczy w taki sposób, żeby nie tylko budować coś wysokiej jakości, ale też robić to szybko.

Różnica między orkiestracją a wykonaniem jest kluczowa dla seniority. Czasami oznacza to wczesne zaangażowanie engineerów, czasami równoległe uruchamianie wielu wątków pracy. Celem jest minimalizacja nieefektywności w procesie.

Kultura low-ego jako przewaga konkurencyjna

Zhang podkreśla znaczenie kultury bez ego w Windsurf. Każdy członek zespołu był „low ego” – świadomy swojej wiedzy, ale też tego, czego nie wie.

Ten typ kultury pozwala ludziom tworzyć całość większą niż suma poszczególnych części. Umożliwia też lepszą współpracę i bardziej satysfakcjonującą podróż.

Charakterystyki kultury low-ego obejmują:

Świadomość ograniczeń – wiedzieć, co się wie i czego się nie wie
Gotowość do nauki – brak wahania przed zadawaniem pytań
Chęć dzielenia się wiedzą – spontaniczne sesje edukacyjne
Fokus na zespole – sukces grupy ważniejszy niż indywidualny
Otwartość na feedback – konstruktywna krytyka jako wartość
Brak defensywności – błędy jako okazje do nauki

Rady dla designerów wchodzących w engineering

Kod na pierwszy rzut oka wydaje się onieśmielający, ale kluczem jest rozłożenie go na atomowe części. Designerzy już myślą systemowo – o atomach, molekułach i wzorcach projektowych.

Praktyczne pierwsze kroki

Zhang sugeruje zaczynanie od podstaw: zrozumienie właściwości CSS jak display: flex, działania React componentów czy state management. Celem nie jest zrozumienie wszystkich systemów engineeringu, ale poznanie konceptów, bloków budulcowych i ograniczeń.

Learning muscle – najważniejszy meta-skill

Najważniejszym narzędziem dla designera nie jest zrozumienie engineeringu, ale zdolność uczenia się w miarę potrzeb.

Learning muscle to umiejętność budowania pewności siebie w uczeniu się nowych konceptów. Jeśli czujesz, że nauka jest bardzo trudna, prawdopodobnie potrzebujesz więcej praktyki lub zacząłeś od zbyt skomplikowanego konceptu.

Zhang radzi: nie należy zaczynać od concurrency czy operating systems. Lepiej rozpocząć od zrozumienia właściwości CSS lub tego, jak wygląda React component.

✅ Roadmapa dla designera

Zmiana sposobów myślenia:

[ ] Kod to system projektowy, nie magiczny język
[ ] Rozdziel boilerplate od logiki biznesowej
[ ] Wykorzystaj analogie (atoms w designie = components w kodzie)

Praktyczne działania:

[ ] Zauważ różnice między designem a implementacją
[ ] Zaproponuj poprawki: „Chcę spróbować to naprawić”
[ ] Screenshot + AI workflow: zrób screenshot różnic, zapytaj AI o różnice, potem napraw i poproś o wyjaśnienie zmian
[ ] Eksperymentuj z prostymi projektami (tic-tac-toe app)
[ ] Zacznij od padding/alignment – najprostsze poprawki dające widoczny efekt

Designerzy mają naturalną przewagę – potrafią zauważyć, gdy implementacja nie odpowiada projektowi. To doskonały punkt wyjścia do nauki poprzez poprawianie małych różnic między designem a kodem.

Przyszłość design engineering

Zhang wierzy, że design engineering będzie coraz ważniejszy w erze AI. Startupom potrzebni są ludzie potrafiący podnieść jakość produktu zarówno pod względem technicznym, jak i designerskim.

Sukces Windsurf pokazał, że ludzie doceniają nie tylko funkcjonalność, ale też przemyślany design. Wielu użytkowników mówiło, że design to powód, dla którego chcą korzystać z produktu.

Ostatecznie nie ma engineeringu bez designu i designu bez engineeringu. Design engineering to naturalna ewolucja w kierunku bardziej holistycznego podejścia do budowania produktów.

Praktyczne prompty AI dla design engineerów

Na podstawie rozmowy z Zhang i jego workflow, oto konkretne prompty możliwe do zastosowania w codziennej pracy:

🎯 Do analizy i dokumentacji

„Take everything that I’ve said and turn it into a document”

Kiedy użyć: Po spacerze z voice mode ChatGPT, gdy nakiełkowałeś myśli o problemie
Cel: Szybka konwersja chaotycznych myśli w uporządkowany, share-ready document
Wskazówka: Idealne po brainstormingu, gdy potrzebujesz struktury

🔍 Do analizy różnic design vs. kod

„What differences do you observe here?”

Kiedy użyć: Gdy widzisz rozbieżności między designem a implementacją
Cel: AI pomoże zidentyfikować konkretne różnice (padding, alignment, kolory)
Przygotowanie: Wrzuć screenshot designu i screenshot implementacji

„Great, let’s fix those. And then explain to me, like, what did you do? What changed? Why did that make the change?”

Kiedy użyć: Po zidentyfikowaniu różnic przez AI
Cel: Naprawienie + zrozumienie co i dlaczego się zmieniło
Wartość: Uczysz się engineering podczas naprawiania rzeczywistych problemów

💻 Do nauki kodowania

„Build me a tic tac toe app”

Kiedy użyć: Jako pierwszy projekt do analizy kodu
Cel: Szybkie prototypowanie + learning exercise
Dalsze kroki: Następnie analizuj każdy plik osobno

„What does this line do?”

Kiedy użyć: Podczas analizy wygenerowanego kodu
Cel: Understanding kodu linia po linii, bez przytłaczania
Strategia: Zamiast próbować zrozumieć cały system, rozbij na atomowe części

🚀 Do eksperymentowania

One-shot dump do narzędzi jak Lovable

Kiedy użyć: Gdy masz pomysł i chcesz szybko sprawdzić „what if”
Cel: Szybkie prototypowanie bez commitment do pełnej implementacji
Sposób myślenia: „Czasami dostaję coś naprawdę pomocnego i mogę podzielić się tym z zespołem”

🚶‍♂️ Voice mode workflows

ChatGPT voice mode podczas spacerów

Kiedy użyć: Gdy utknąłeś z problemem projektowym i potrzebujesz dystansu
Proces: Dumping thoughts → asking questions → being asked questions → synthesis
Efekt: „Czasami najlepsze co możesz zrobić dla pracy to nie pracować przez chwilę”

Te prompty bazują na rzeczywistych workflow, które Zhang i host podcastu stosują w swojej pracy. Kluczem jest eksperymentowanie – różne narzędzia AI działają lepiej dla różnych typów myślenia i problemów.

Kluczowy insight

AI paradox produktowy

Standardowo myślimy: Im łatwiej budować funkcje, tym lepszy produkt możemy stworzyć. AI obniża koszty developmentu, więc możemy dodać więcej funkcjonalności.

W praktyce okazuje się, że: Im łatwiej coś zbudować, tym trudniej utrzymać prostotę produktu. Zhang ostrzega: koszt tworzenia drastycznie spadł dzięki narzędziom takim jak Windsurf, jednak w rezultacie, jeśli celem jest zachowanie prostoty mentalnego modelu, należy mówić „nie” wielu rzeczom.

Dlaczego to jest istotne: Era AI wymaga odwrócenia logiki produktowej – zamiast pytać „co możemy zbudować?” należy pytać „czego nie powinniśmy budować?”. Sukces leży w samoograniczeniu, nie w możliwościach technicznych.

Test na jutro: Następnym razem gdy zespół zaproponuje nową funkcję bo „AI ją szybko zrobi”, zamiast myśleć o wykonalności spróbuj zapytać „czy to uprasza czy komplikuje mental model użytkownika?” i sprawdź jak zmieni się jakość decyzji produktowych.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w podcaście Dive Club.

Od wczesnej Figmy do design engineering w Windsurf – lekcje Andy’ego Zhang #EN248