Przekazywanie projektów inżynierom – poza komentarzami w Figmie
Dlaczego same komentarze w Figmie nie wypełnią luki w przekazywaniu projektów inżynierom i co naprawdę działa w małych zespołach.
By Ellis Keane · 2026-04-06
Najlepsze narzędzie do przekazywania projektów inżynierom to takie, którego inżynierowie nigdy nie otwierają
Im więcej projektanci inwestują w doskonalenie przekazywania w Figmie – auto-layout, tokeny projektowe, adnotacje trybu deweloperskiego, dokumentacja komponentów – tym gorzej wygląda faktyczne przekazywanie projektów inżynierom. Nie dlatego, że praca projektowa jest zła – zwykle jest genialna – ale dlatego, że cały ten wysiłek istnieje w narzędziu, które inżynierowie odwiedzają niechętnie, szybko przeglądają, a potem zamykają, żeby budować to, co im się wydaje, że widzieli.
Byłem po obu stronach. Zaczynałem jako projektant (no, „projektant" – budowałem strony dla lombardów w New Hampshire, więc bądźmy wspaniałomyślni z tym tytułem), a teraz piszę większość kodu inżynieryjnego dla Sugarbug. Problem przekazywania projektów inżynierom to nie problem narzędzi, to problem przepływu pracy. Informacja istnieje, po prostu jest w złym miejscu o złym czasie.
Typowe przekazywanie projektu inżynierom wygląda mniej więcej tak: projektant spędza trzy dni szlifując ramkę w Figmie, dodaje dwanaście komentarzy wyjaśniających decyzje dotyczące odstępów i przypadki brzegowe, taguje inżyniera i czeka. Inżynier otwiera Figmę, patrzy na ramkę przez około dziewięćdziesiąt sekund, myśli „jasne, mam to", zamyka kartę i buduje coś, co jest w 80% poprawne i w 20% błędne w sposób, którego rozwiązanie zajmie kolejny tydzień wymiany. Dwanaście komentarzy? Przeczytał może cztery.
Przekazywanie projektu inżynierom to nie plik rzucany przez ścianę. To kontekst, który musi istnieć tam, gdzie pracuje inżynier – w zadaniu, w PR-ze, w kodzie – nie w narzędziu projektowym, które odwiedza raz.
Dlaczego komentarze w Figmie mają niewłaściwy kształt do przekazywania
Używam Figmy codziennie i szczerze ją lubię (co w tym momencie jest prawdopodobnie wadą charakteru). Ale komentarze w Figmie są zoptymalizowane pod współpracę projektant-projektant, nie pod przekazywanie projektów inżynierom, a ta różnica ma większe znaczenie, niż większość zespołów zdaje sobie sprawę.
Fundamentalna niezgodność polega na tym: komentarze w Figmie są przestrzennie zakotwiczone do ramek i komponentów. Istnieją wewnątrz pliku projektowego. Ale inżynierowie nie pracują wewnątrz plików projektowych – pracują w zadaniach Linear, PR-ach GitHub i swoim IDE. Kiedy projektant zostawia komentarz na ramce „ten dropdown powinien się zwijać na urządzeniach mobilnych poniżej 640px", ta informacja jest teraz uwięziona w Figmie. Nie staje się zadaniem. Nie pojawia się w przepływie pracy inżyniera. Istnieje w równoległym wszechświecie, o którego odwiedzeniu inżynier musi pamiętać, a (tu jest bit, który naprawdę ma znaczenie) odwiedzanie Figmy nie jest częścią naturalnej pętli pracy inżyniera, tak jak sprawdzanie Linear czy przeglądanie PR-ów.
Wynik jest przewidywalny: krytyczne decyzje projektowe giną, nie dlatego, że ktoś jest nieostrożny, ale dlatego, że informacja jest w złym narzędziu. To jak zostawienie karteczki na biurku kogoś, kto pracuje z domu.
Gdzie projektanci zostawiają kontekst
- Komentarze w Figmie – przestrzenne, zakotwiczone do ramek
- Adnotacje trybu deweloperskiego Figmy – szczegółowe, ale wymagają otwarcia Figmy
- Wątki na Slacku – konwersacyjne, po tygodniu nie do wyszukania
- Dokumentacja systemu projektowego – kompleksowa, ale rzadko sprawdzana w trakcie sprintu
Gdzie inżynierowie faktycznie patrzą
- Opis zadania Linear – pierwsza rzecz, którą czytają przed rozpoczęciem
- Opis PR-a GitHub – odniesienie podczas implementacji
- Komentarze w kodzie – odkrywane podczas przeglądu
- IDE – gdzie spędzają 90% czasu
Co naprawdę działa (od kogoś, kto robi jedno i drugie)
Przez ostatni rok budowania Sugarbug byłem projektantem i (głównie) inżynierem, co oznacza, że miałem niezwykłe doświadczenie przekazywania sobie samemu i mimo to tracenia kontekstu. Jeśli nie mogę zapamiętać własnych decyzji projektowych z zeszłego wtorku, to nie ma szans, żeby osobny inżynier wyłapał wszystko z wątku komentarzy w Figmie.
Oto co naprawdę zadziałało w procesie przekazywania projektów inżynierom w naszym zespole – i nic z tego nie obejmuje pisania lepszych komentarzy w Figmie.
1. Zapisz decyzję projektową w zadaniu, nie w pliku projektowym
Zanim inżynier zacznie budować, kontekst projektowy musi istnieć w zadaniu Linear (lub czymkolwiek, czego używa twój zespół). Nie link do pliku Figmy z „patrz projekty" – to wymówka i każdy o tym wie. Zadanie powinno zawierać:
- Co: Zrzut ekranu lub wyeksportowana ramka (nie link do Figmy – PNG, który inżynier może zobaczyć bez otwierania kolejnego narzędzia)
- Dlaczego: Uzasadnienie kluczowych decyzji. „Wybraliśmy panel wysuwany zamiast modala, ponieważ użytkownik musi widzieć listę podczas edycji" – jedno zdanie, które oszczędza trzy rundy „dlaczego nie modal?"
- Przypadki brzegowe: Co dzieje się na urządzeniach mobilnych? Co z długim tekstem? Co, gdy nie ma danych? Jeśli o tym myślałeś, zapisz to. Jeśli nie myślałeś, powiedz to (szczerze, „nie rozwiązałem jeszcze pustego stanu" jest bardziej przydatne niż cisza)
2. Przeglądy projektów odbywają się w zadaniu, nie w Figmie
Kiedy dostaję opinie projektowe podczas implementacji, chcę je w wątku zadania Linear, nie jako komentarz w Figmie, którego mogę nie zobaczyć przez dwa dni. Zadanie jest moim jedynym źródłem prawdy dla pracy – jeśli opinie tam żyją, zobaczę je następnym razem, gdy sprawdzę zadanie, a to kilka razy dziennie. Jeśli żyją w Figmie, zobaczę je, kiedy przypadkiem otworzę ten plik, co może nigdy nie nastąpić.
To nie znaczy, że nigdy nie należy używać komentarzy w Figmie. Są świetne do współpracy projektant-projektant, do oznaczania konkretnych detali wizualnych i do rozmów o samym projekcie. Ale w momencie, gdy opinia staje się „inżynier musi coś zmienić", musi przenieść się do przepływu pracy inżynieryjnej.
stat: "Większość" headline: "komentarzy w Figmie pozostawała niezauważona przez ponad 48 godzin, gdy polegaliśmy na nich w przekazywaniu" source: "Doświadczenie naszego zespołu z 3 miesięcy nieformalnego śledzenia"
3. Zamknij pętlę zrzutami ekranu, nie założeniami
Najtańszą formą walidacji przekazywania projektu jest zrzut ekranu. Kiedy inżynier kończy implementację komponentu, wkleja zrzut ekranu do PR-a lub zadania i taguje projektanta. „Czy to się zgadza?" zajmuje dziesięć sekund i wyłapuje 20% odchylenia przed wdrożeniem. Żadnego spotkania, żadnego rytuału porównywania z Figmą – tylko PNG i pytanie.
Zaczęliśmy to robić dla każdego UI PR-a i liczba rozmów „to nie pasuje do projektu" spadła praktycznie do zera. Rozmowy, które pozostały, dotyczą prawdziwych przypadków brzegowych, których projekt nie uwzględnił, co jest w porządku – to jest coś, co powinno być omawiane, a nie podstawowe „użyłeś 16px paddingu zamiast 12px".
4. Pozwól kontekstowi przepływać między narzędziami automatycznie
Tu wspomnę o Sugarbug, bo dosłownie zbudowaliśmy go, żeby rozwiązać ten konkretny problem. Nasz projektant zostawia komentarz w Figmie o zmianie odstępów. Sugarbug przechwytuje ten komentarz, łączy go z odpowiednim zadaniem Linear i PR-em GitHub, a inżynier widzi go w swoim przepływie pracy bez otwierania Figmy. Przekazywanie projektów inżynierom przestaje być ręcznym rytuałem kopiowania i staje się czymś, co po prostu się dzieje.
Ale jeśli nie używasz Sugarbug (a większość z was nie używa, wciąż jesteśmy przed premierą), wersja ręczna to: wyznacz kogoś jako „most przekazywania", kto codziennie sprawdza komentarze w Figmie i kopiuje istotne opinie do zadań Linear. To żmudne, ale działa, i jest nieskończenie lepsze niż nadzieja, że inżynierowie będą pamiętać, żeby sprawdzać Figmę.
Jeśli nie mogę zapamiętać własnych decyzji projektowych z zeszłego wtorku, to nie ma szans, żeby osobny inżynier wyłapał wszystko z wątku komentarzy w Figmie. attribution: Chris Calo
Twoja checklista przekazywania projektów inżynierom
Jeśli wyniesiesz z tego artykułu jedną rzecz, niech to będzie ta: rozwiązaniem nie są lepsze narzędzia (no, nie głównie – choć jedno buduję, więc bierz to z przymrużeniem oka). Rozwiązaniem jest ustanowienie norm dotyczących tego, gdzie żyją decyzje projektowe, i upewnienie się, że to „gdzie" jest wewnątrz naturalnego przepływu pracy inżyniera.
- [ ] Wyeksportuj kluczowe ramki jako PNG do zadania Linear (nie tylko link do Figmy)
- [ ] Zapisz „dlaczego" dla każdej ważnej decyzji projektowej w opisie zadania
- [ ] Wymień znane przypadki brzegowe (mobilne, puste stany, długi tekst) – lub wyraźnie zaznacz, czego jeszcze nie rozwiązałeś
- [ ] Przenieś opinie dotyczące implementacji z komentarzy Figmy do wątku zadania
- [ ] Wymagaj zrzutu ekranu w każdym UI PR-ze przed podpisaniem przez projektanta
- [ ] Wyznacz osobę „most przekazywania", jeśli nie masz narzędzia łączącego Figmę i Linear automatycznie
Często zadawane pytania
Q: Dlaczego komentarze w Figmie zawodzą jako narzędzie przekazywania projektów inżynierom? A: Komentarze w Figmie istnieją wewnątrz pliku projektowego, odcięte od przepływu pracy inżynierów. Inżynierowie pracują w Linear, GitHub i swoim IDE – nie w Figmie. Komentarz na ramce nie staje się zadaniem, dopóki ktoś ręcznie go nie skopiuje, a ten ręczny krok jest miejscem, w którym przekazywanie się rozpada. To nie problem ludzi, to problem granicy narzędzi.
Q: Czy Sugarbug łączy komentarze z Figmy z zadaniami w Linear automatycznie? A: Tak – to jeden z konkretnych problemów, które zbudowaliśmy, żeby rozwiązać. Sugarbug pobiera komentarze z Figmy i łączy je z odpowiednimi zadaniami w Linear i PR-ami w GitHub, więc opinie projektowe pojawiają się w przepływie pracy inżyniera bez kopiowania między narzędziami. Używamy go sami codziennie, a różnica jest (szczerze) trochę zawstydzająca, biorąc pod uwagę prostotę pomysłu.
Q: Jaki jest najlepszy proces przekazywania projektów inżynierom dla małych zespołów? A: Zapisz decyzję projektową w zadaniu Linear przed rozpoczęciem budowy przez inżyniera. Podaj uzasadnienie, nie tylko wygląd. Jeśli podczas implementacji pojawią się przypadki brzegowe, omawiaj je w wątku zadania – nie w komentarzu w Figmie, którego inżynier musi szukać. Najprostszy proces jest często najbardziej trwały.
Q: Jak radzisz sobie ze zmianami projektowymi po rozpoczęciu prac inżynieryjnych? A: Traktuj je jak zmiany zakresu: udokumentuj zmianę w zadaniu z jasnym porównaniem przed/po, wyjaśnij uzasadnienie i pozwól inżynierowi ocenić koszt implementacji przed zatwierdzeniem. Najgorsze niepowodzenia w przekazywaniu zdarzają się, gdy zmiany projektowe przychodzą jako luźne komentarze w Figmie do pracy, która już została zbudowana – tak właśnie tworzysz zirytowanych inżynierów i sfrustrowanych projektantów.
Otrzymuj analizy sygnałów prosto do skrzynki.