Od Figmy do Produkcji: Playbook Handoffu Designer–Developer
Pracowałem nad około czterdziestoma projektami, w których designer przekazywał pliki Figmy mnie lub innemu inżynierowi. Te, które wdrażały się gładko, i te, które się rozsypywały, nie mają prawie nic wspólnego z samą Figmą. Mają wszystko wspólnego z tym, czy handoff zawiera to, czego deweloperzy naprawdę potrzebują — a większość handoffów nie zawiera.
Ten artykuł to krótki, opiniotwórczy playbook, którego używam teraz z partnerami designerskimi. Pięć trybów porażki do uniknięcia i checklista, która zapobiega 90% ping-ponga.
Dlaczego handoff się sypie
Handoff rzadko sypie się dlatego, że designer był niechlujny. Sypie się dlatego, że obie strony mają różne modele mentalne tego, czym jest komponent. Designer widzi prostokąt z etykietą. Deweloper widzi komponent z propsami, stanami, responsywnością, wymaganiami dostępności, wariantami loading i stanami błędów. Plik Figmy rzadko pokazuje całą tę matrycę.
Pięć powracających porażek
- Brakujące stany: zaprojektowana jest tylko happy path. Hover, focus, active, disabled, loading i error są nieobecne lub niespójne.
- Nienazwane tokeny: kolory i spacing to zahardkodowane wartości hex i liczby pikseli zamiast nazwanych zmiennych, więc nic nie jest wielokrotnego użytku w kodzie.
- Brak breakpointów responsywnych: layout mobilny jest albo całkowicie nieobecny, albo narysowany na jednej arbitralnej szerokości, która nie pasuje do breakpointów deweloperskich.
- Niespójna skala spacingu: marginesy i padding używają wartości typu 13px, 17px, 22px — niezwiązane z żadną siatką 4px czy 8px.
- Niewidzialne interakcje: animacje, przejścia i mikro-interakcje są opisane w wiadomościach na Slacku zamiast w samym pliku.
Checklista handoffu, która naprawdę działa
- Design tokeny żyją w zmiennych Figmy — kolory, spacing, rozmiary fontów, promienie — a ich nazwy odpowiadają dokładnie configowi Tailwinda
- Każdy interaktywny komponent ma pięć stanów: default, hover, focus, active, disabled. Formularze dodają jeszcze dwa: loading i error
- Zaprojektowane są co najmniej dwa breakpointy: mobile (375px) i desktop (1440px). Tablet zwykle jest interpolowany, nie projektowany
- Spacing trzyma się skali 4px lub 8px. Żadnych 13px. Żadnych 22px. Nigdy.
- Nazwy komponentów w Figmie odpowiadają nazwom komponentów w kodzie. Button, nie Rectangle 42.
- Interakcje (przejścia hover, animacje modali, przejścia stron) są zapisane jako krótkie screencasty albo opisane w dokumencie Notion zalinkowanym z ramki
- Dostępność jest jawna: kolejność focusu, etykiety ARIA, zweryfikowany kontrast, opisana nawigacja klawiaturą
- Async review odbywa się w każdy piątek: designer i deweloper przechodzą razem przez plik Figmy, aktualizują to, co się rozjechało, i zamykają pętlę
“Najlepsze współprace designer–developer, w których brałem udział, traktowały Figmę i kod jako dwa widoki tego samego design systemu — nie jako upstream i downstream.”
Narzędzia, których naprawdę używam
Figma do designu, ze zmiennymi zmapowanymi jeden-do-jednego na tokeny Tailwinda. Storybook do dokumentacji komponentów po stronie dewelopera — każdy komponent w Figmie ma odpowiadający mu wpis w Storybooku. Loom do async walkthroughów, kiedy statyczny screenshot nie wystarcza. Linear do śledzenia zmian designu wymagających follow-upu od dewelopera. To wszystko. Żadnego Zeplina, żadnego Avocode, żadnego pluginu do handoffu. Overhead nie jest tego wart, kiedy design tokeny są zsynchronizowane.
Najważniejsze jednak jest podejście: potraktuj pierwszy sprint nowego projektu jako sprint kalibracyjny, w którym designer i deweloper dogadują się co do konwencji zanim cokolwiek wdrożą. Dwa dni kalibracji oszczędzają dwa tygodnie przeróbek.
Jeśli Twój zespół utknął w pętli handoffu i potrzebujesz perspektywy z zewnątrz — napisz do mnie. Uruchamiałem ten playbook z partnerami designerskimi od solo freelancerów po wewnętrzne zespoły produktowe, a poprawka zwykle okazuje się prostsza, niż się wydaje.
Potrzebujesz pomocy z Twoim projektem?
Porozmawiajmy o Twoich wymaganiach technicznych. Oferuję bezpłatną konsultację, podczas której omówimy architekturę, stos technologiczny i harmonogram.
Zobacz moje usługi