Design handoff w Atlassian — jak Jade organizuje pliki Figma dla 400+ designerów #EN351

• Dwa podejścia do dev handoff: embedded designers pracują synchronicznie z devami i potrzebują minimalnej dokumentacji, traditional handoff wymaga szczegółowych annotacji w Figma, Confluence i Loom
• Framework „Good, Better, Best” to sposób Atlassian na eksplorację różnych poziomów user experience mimo constraints — daje designerom możliwość push-backu przeciwko scope
• Component spec w Confluence definiuje każdy element interfejsu (issue key, summary, agent vertical name) eliminując miscommunication między zespołami
• Stack narzędzi: Figma dla wizualizacji, Confluence dla definicji, Loom dla asynchronicznych walkthrough z możliwością powrotu
• Atlassian Way dzieli projekty na 4 fazy: Wonder, Explore, Make, Impact (oparte na double diamond)
• Organizacja plików: priorytetowe strony na górze oznaczone emoji, sekcje zamiast auto-layout frames dla lepszego linkowania
• Brak top-down mandate — mimo 400-500 designerów Atlassian nie wymusza jednego sposobu pracy, pozwalając na local setup dopasowany do zespołu

---

Poniższy tekst to notatki z odcinka podcastu Deep Dive, w którym Jay rozmawia z Jade z Atlassian. Wszystkie przedstawione przemyślenia, obserwacje i metody pracy pochodzą od Jade i opisują jej doświadczenia w organizacji plików Figma oraz procesie dev handoff w środowisku 400-500 designerów.

Według Jade kluczem do skutecznej współpracy nie jest maksymalna dokumentacja, lecz znalezienie balansu. Chodzi o trafienie w złoty środek — przekazanie zespołowi dokładnie tyle kontekstu, ile potrzebują, bez przesady.

Nie trzeba wypełniać każdego template do końca. Wystarczy zrobić to, co najlepiej przekaże intencję projektu. Dzięki temu można szybko się poruszać, bez tworzenia dodatkowych prezentacji czy ciężkich procesów dokumentacji.

W Atlassian pracuje około 400-500 designerów, jednak inżynierów jest jeszcze więcej. Podczas gdy designerzy spędzają większość czasu w Figma, deweloperzy pracują głównie w code editorze. Dlatego Confluence i Loom służą jako scentralizowane miejsca — neutralny grunt między dwoma światami.

---

Według Jade sposób przekazywania projektu developerom zależy od poziomu współpracy z zespołem. Dev handoff w Atlassian przyjmuje dwie formy.

W tym modelu Jade pracuje bezpośrednio z zespołem deweloperskim, dlatego uczestniczy w ich spotkaniach i wyjaśnia rozwiązania na bieżąco. Jest to proces synchroniczny, w którym kontekst przekazywany jest głównie werbalnie.

Dzięki temu dokumentacja w Figma może być znacznie lżejsza — bez szczegółowych annotacji. Taka struktura pozwala szybko poruszać się i iterować, unikając ciężkich procesów dokumentacyjnych.

Drugie podejście stosowane jest wtedy, gdy Jade ma mniej czasu na bezpośrednią współpracę z zespołem deweloperskim. W takim przypadku proces wymaga:

• Mniej bezpośredniego kontaktu z zespołem (fewer back and forth)
• Szczegółowych annotacji w Figma
• Pełnej dokumentacji w Confluence
• Filmów Loom z walkthrough
• Linków łączących wszystkie narzędzia

• Przygotuj szczegółowe annotacje w Figma
• Stwórz component spec w Confluence z definicjami wszystkich elementów
• Nagraj Loom walkthrough (intended flows, rationale, jobs to be done)
• Dodaj linki między narzędziami (Figma → Confluence → Loom)
• Zdefiniuj wszystkie elementy interfejsu (nouns) z przykładami
• Opisz edge cases i błędy
• Pokaż wszystkie stany komponentów (różne statusy, kolory)
• Edytuj transkrypt Loom (usuń wypełniacze typu „ums” i „ahs” jeśli potrzebne)

Jak podkreśla Jade, nie cała dokumentacja mieści się w Figma. Znaczna część znajduje się w Confluence i Loom, połączona linkami w głównym pliku projektowym.

Niezależnie od wybranego podejścia, Jade zaleca uwzględnienie następujących elementów:

• Oceń stopień integracji z zespołem (embedded czy zewnętrzny) — od tego zależy poziom wymaganej dokumentacji
• Przygotuj wizualne materiały w Figmie (adnotacje, specyfikacje komponentów, różne stany)
• Stwórz słownik pojęć w Confluence (centralne źródło prawdy dla definicji)
• Zdefiniuj przypadki brzegowe i logikę warunkową
• Nagraj asynchroniczne walkthrough w Loom (wyjaśnienie „dlaczego” oraz zamierzonych ścieżek)
• Połącz wszystko linkami (Figma → Confluence → Loom)

---

W Atlassian stosuje się framework „Good, Better, Best” do eksploracji rozwiązań projektowych. Jednak według Jade to nie tylko narzędzie komunikacji, lecz również sposób na ochronę jakości designu — zapewnienie, że praca projektowa nadal eksploruje możliwie najszersze spektrum rozwiązań, mimo ograniczeń takich jak timeline czy scope.

Framework dzieli propozycje na trzy kategorie:

• Best — najlepsza możliwa user experience (najprostsza, najbardziej uproszczona)
• Better — pośrednie rozwiązanie (np. pre-filtered content z innym framingiem)
• Good — podstawowa wersja (np. manualne filtrowanie przez użytkownika)

Jak wyjaśnia Jade, jako designer zawsze dążysz do rozwiązania „best”. Niemniej pod pewnymi ograniczeniami pojawia się nieunikniony trade-off, dlatego ten framework pomaga komunikować różne podejścia z zespołem.

Istotne jest również to, że w ramach każdego poziomu (Good/Better/Best) można zaproponować różne warianty. To nie są pojedyncze rozwiązania, lecz szerokie kategorie zawierające podwarianty.

Framework daje większą wolność w eksploracji i pozwala odrzucać wcześniejsze założenia. Co więcej, umożliwia push-back jeśli user experience naprawdę tego wymaga — można wtedy wrócić do rozmowy o scope i zakwestionować ograniczenia.

Zdaniem Jade Good, Better, Best jest bardzo użytecznym narzędziem, dlatego włącza go jako kluczową stronę w swoich plikach projektowych.

---

Według Jade kluczowe znaczenie ma wypracowanie wspólnego języka między designerami a deweloperami. Component spec eliminuje ryzyko nieporozumień i zapewnia, że obie strony mówią o tym samym.

W Confluence Jade tworzy szczegółową tabelę definicji, w której każdy element interfejsu (każdy „noun”) ma własną specyfikację. Issue key, summary, agent vertical name — wszystko jest dokładnie opisane.

• Nazwa elementu (np. issue key, summary)
• Dokładna definicja czym jest dany element
• Przykłady użycia
• Informacje o conditional logic
• Opis co się dzieje gdy danego elementu nie ma
• Mapowanie do odpowiadających elementów w Figma

Jak zauważa Jade, bez takiej tabeli współpraca staje się trudniejsza — pojawia się więcej rozmów, a ryzyko nieporozumień rośnie.

Typowy problem wygląda następująco: podczas długiego wątku na Slacku Jade w połowie rozmowy zdaje sobie sprawę, że z inżynierem mówią o zupełnie różnych rzeczach. Właśnie dlatego precyzyjne definicje mają zapobiegać takim sytuacjom.

Jade stara się pisać definicje w języku deweloperów, co pozwala na „mówienie w tym samym języku”. Deweloperzy mogą wejść do Figma i zobaczyć wszystkie ścieżki, jednak definicje są zapisane w sposób odpowiadający ich sposobowi myślenia — w „inżynierskim światopoglądzie”, jak to określa Jade.

Dzięki temu powstaje wspólne zrozumienie, nawet przy akronimach specyficznych dla firmy. Nowi członkowie zespołu mogą bowiem nie znać znaczenia pojęć takich jak „agent vertical name”.

Informacje często są zlokalizowane w konkretnym zespole, dlatego przy pracy cross-functional trzeba wyrównać wszystkich. W tym celu Confluence służy jako centralne źródło prawdy, podczas gdy Loom ułatwia asynchroniczną wymianę kontekstu.

---

W procesie handoff Jade wykorzystuje trzy główne narzędzia, przy czym każde z nich pełni odrębną rolę w ekosystemie dokumentacji.

Figma służy do prezentacji różnych stanów komponentów: statusów z odmiennymi kolorami, edge cases, błędów, ścieżek oraz prototypów. Wszystko, co wizualne, znajduje się właśnie w tym narzędziu.

Nie można jednak w pełni zdefiniować wszystkiego wyłącznie w Figma, dlatego Jade łączy je z Confluence.

Confluence pełni rolę centralnego źródła prawdy dla definicji, logiki biznesowej i przypadków brzegowych. Na stronach Confluence Jade umieszcza osadzony plik Figma, a poniżej — szczegółowe definicje wszystkich elementów. Znajdują się tam również informacje o procesie podejmowania decyzji oraz różne statusy zadań (np. treatment).

Jade stara się wyprzedzać edge cases i odpowiadać na pytania deweloperów, zanim jeszcze je zadadzą. Co się dzieje gdy użytkownik kliknie? Co gdy jest wylogowany? Te zagadnienia są omawiane w dokumentacji.

Filmy Loom to nagrania ekranu z omówieniem pliku Figma, podczas których Jade przechodzi przez zamierzone ścieżki i wyjaśnia proces myślowy oraz uzasadnienie za decyzjami projektowymi — jobs to be done, każdy stan komponentu, spec, prototyp, definicje.

Jak podkreśla Jade, można to wszystko omówić na spotkaniu i faktycznie tak robi dla wyjaśnienia wątpliwości. Niemniej Loom jest użyteczny, ponieważ zespół może do niego wrócić. To format do współdzielenia, do którego można później sięgnąć jako punkt odniesienia.

W filmach pojawiają się także komentarze, co umożliwia wymianę myśli w formie asynchronicznej dyskusji.

Czy Loom pomaga ograniczyć liczbę spotkań? Według Jade zdecydowanie tak.

Pomaga również w przypadku różnych wątków i rozmów. Jeśli spodziewasz się wielu uwag i konwersacji, spotkanie może być lepszym rozwiązaniem. Natomiast w przypadku aktualizacji designu lub dzielenia się uzasadnieniem decyzji — Loom sprawdza się doskonale.

Jade zauważa istotną rzecz: nie musisz samodzielnie wyrównywać całego zespołu. W niektórych projektach miała feature leada, który wyjaśniał wszystko zespołowi w jej imieniu, co znacznie ułatwiało proces.

Kluczowe spostrzeżenie: wystarczy dogłębnie wyrównać jednego inżyniera, który następnie przekaże wiedzę reszcie zespołu. Nie trzeba wykonywać tej pracy wielokrotnie — to sposób na skalowanie przekazu bez duplikowania wysiłku.

Jade zazwyczaj nagrywa jeden lub dwa ujęcia. Czasem bywa gadatliwa, dlatego Loom pozwala odczytać transkrypty i usunąć wszystkie wypełniacze typu „ums”, „ahs” czy pauzy.

Jest to pomocne, gdy nagranie musi być dopracowane. Niemniej przy wyjaśnianiu uzasadnienia Jade nie robi zbyt wielu ujęć i nie dąży do perfekcji. Na spotkaniu zrobiłaby to samo, więc Loom to odtworzenie tego samego procesu w formacie nadającym się do udostępnienia.

---

W Atlassian praca projektowa jest zorganizowana według struktury zwanej „Atlassian Way”, która bazuje na modelu double diamond i dzieli projekty na cztery fazy:

1. Wonder — początkowy research, szeroka eksploracja, zastanawianie się nad możliwościami
2. Explore — kontynuacja poszerzania perspektywy, dalsze odkrywanie opcji
3. Make — faza budowania rozwiązania (najwięcej rozmów z zespołami deweloperskimi i stakeholderami)
4. Impact — etap po wypuszczeniu feature (czego się nauczyliśmy? co dalej?)

Jade wykorzystuje tę strukturę w swoim template do dev handoff, oznaczając strony jako Wonder, Explore, Make i Impact. Dodatkowo stosuje kategorie Archived oraz To Do.

---

Jade wypracowała podejście do struktury plików, które sprawdza się w dużych zespołach.

• Cover z podstawowymi informacjami (faza projektu, deadline, owner)
• About page (zespół, stage of work, useful links)
• Priorytetowe strony na górze oznaczone emoji
• System emoji (🟢 work in progress, 🚧 aktualnie pracuję)
• Używaj sections zamiast auto-layout frames (lepsze linkowanie)
• Wyraźny podział: strony dla stakeholderów vs internal work
• Strony według faz Atlassian Way (Wonder, Explore, Make, Impact)

Zamiast konfigurować kontekst na wiele sposobów, Jade korzysta z about page, która zawiera informacje o tym, kto jest zaangażowany, do kogo zwrócić się z pytaniami, na jakim etapie prac znajduje się projekt (Atlassian Way) oraz przydatne linki.

Jade stosuje kilka wersji takiej strony. Condensed to bardzo szybka specyfikacja. Fleshed out zawiera pełny kontekst z problem statements, first principles i założeniami. Key pages służy osobom, które wskakują do pliku (choć Jade zauważa, że tego wariantu nie używają zbyt często).

Pole Owner odnosi się do designera, nie product managera. Chodzi o własność pliku — kogo zapytać w razie wątpliwości?

Najważniejsze strony dla stakeholderów znajdują się na górze. Jade oznacza je emoji: 🟢 zielone kropki wskazują strony, gdzie praca jest w toku, 🚧 symbol construction oznacza to, nad czym Jade aktualnie pracuje.

Istnieje również świadomy podział: exploration line. Wszystko poniżej tej linii to praca wewnętrzna (internal work), która może być mniej uporządkowana. To strony przeznaczone do pracy nad projektem — dyskusji, crit sessions i sparring z innymi designerami.

Ten podział jest celowy: strony dopracowane (polished) dla stakeholderów, strony bardziej chaotyczne (messier) dla procesu.

Obecnie Jade używa sections do strukturowania pracy, nie auto-layout frames na górze ekranów.

Powód? Gdy linkujesz do sections, pokazuje się to lepiej w innych kontekstach.

End to end journey map nie został stworzony przez Jade, lecz przez innego designera — Johna Vaughana, który skomponentyzował sposób ustawienia journey map.

Można zduplikować instancję i odłączyć (detach), aby manipulować elementami w środku. Framework wykorzystuje Figma variables i modes — gdy weźmiesz neutral emotion i umieścisz w thinking frame, automatycznie się aktualizuje.

Nie trzeba robić tego ręcznie. John dobrze to przygotował.

Instrukcje: copy and paste, następnie detach. Kopiujesz emotions, a gdy zmieniasz je na inną linię, zmieniają się automatycznie. Można również wstawić UI/screeny i mieć journey powyżej.

Według Jade starają się używać tego narzędzia tak często, jak to możliwe. Czasem robią user journeys także w FigJam — zależy co jest najlepszym sposobem komunikacji w danym momencie.

Czasem jest to high fidelity journey (wtedy template jest idealny), czasem tylko sticky notes w FigJam, bo rozmawiasz z zespołem na bieżąco. Wszystko zależy od celu, jakiemu ma służyć.

---

Design sparring to inaczej design crit — proces wykorzystywany przez Jade do zbierania opinii.

Jade przedstawia skalę gotowości projektu, co pomaga zorientować się, jakiego rodzaju uwagi są potrzebne.

Jak interpretować skalę gotowości:

• 90% gotowości — uwagi dotyczące mikrotekstów, ikon, drobnych szczegółów
• 30% gotowości — design jest wczesny, dopiero się wypracowuje; potrzebne są uwagi o ogólnych koncepcjach, wzorcach, copy

Orientowanie się wokół tej skali ułatwia proces zbierania konstruktywnych uwag.

• Context setting (5 minut)
• Określenie skali gotowości (30%, 60%, 90%)
• Przegląd projektu (tyle ile potrzebujesz)
• Wskazanie priorytetów — na czym zespół ma się skupić
• Uwagi przez komentarze lub stickies
• Podsumowanie po spotkaniu (przepisanie własnymi słowami)

To osobista praktyka Jade. Lubi przejść przez wszystko i przepisać własnymi słowami jako podsumowanie, co pomaga ustalić kolejne kroki.

Jade robi summary później, po spotkaniu. Podczas samego spotkania rozmawia z ludźmi i wyjaśnia komentarze, jeśli potrzebuje jasności.

Potem, po zakończeniu spotkania, siada i zastanawia się „okay, what next?”. Wypisywanie tego procesu jest dla Jade osobiście użyteczne.

---

W Atlassian pracuje około 400-500 designerów oraz jeszcze więcej inżynierów.

Kluczowa obserwacja Jade: ten template nie jest narzucany globalnie. Nic nie jest nakazywane odgórnie — Atlassian design nie mówi „musisz designować w ten sposób”.

To coś, co Jade uznała za przydatne i wypracowała z własnym zespołem projektowym. Można to nazwać lokalnym setupem — tak ten konkretny zespół robi projekty i znajduje to pomocne w pracy na dużą skalę.

Brak odgórnego mandatu wynika z tego, że każdy designer pracuje trochę inaczej. Weź elementy, które uważasz za użyteczne, resztę możesz zostawić. Dzięki temu nadal możesz się szybko poruszać.

To zawsze kwestia balansu. Template, który Jade pokazuje, jest najbardziej rozbudowany. W rzeczywistym projekcie realistycznie nie wypełnisz wszystkiego — i to jest w porządku.

Robisz to, co najlepiej przekaże intencję. Chcesz trafić w złoty środek — dokładnie tyle kontekstu, ile potrzebuje zespół. Bez tworzenia dodatkowych prezentacji do wyjaśniania kontekstu. Bez robienia tego w ciężki sposób.

Z jednym zespołem Jade przygotowała całą stronę Confluence, Loom oraz spec — ponieważ nie było zbyt wiele bezpośrednich rozmów. Z embedded team podejście jest znacznie lżejsze, co pozwala szybko się poruszać i iterować bez ciężkich procesów.

Ta filozofia się przewija: balance, just enough, unikanie ciężkich procesów. Chodzi nie o maksymalizację dokumentacji, lecz o optymalizację komunikacji.

Nawet z punktu widzenia design ops skonfigurowanie tego systemu jest przydatne. Za każdym razem gdy Jade chce przekazać szybki kontekst, nie musi odtwarzać tego od początku na górze pliku.

Przykład: zespół chciał szybko iterować, więc Jade przygotowała naprawdę zwięzły kontekst — oto problemy, to nasz użytkownik, oto założenia. Szybko przepchnąć projekt bez robienia tego w ciężki sposób, bez tworzenia nowych prezentacji do wyjaśniania kontekstu.

Jade strukturuje pliki tak, że ważniejsze strony dla stakeholderów są na górze (emoji jako oznaczenia), podczas gdy wszystko poniżej jest dla niej samej i może być bardziej chaotyczne.

---

W swoim template do dev handoff Jade ma przydatne komponenty do szczegółowego opisywania elementów.

Component spec to prawdopodobnie element stworzony przez design system team Atlassian. Pomaga specyfikować wszystko, gdy pracujesz z wieloma nowymi komponentami.

Widzieliśmy to na mniejszą skalę we wcześniejszym pliku (tylko kilka nowych komponentów), jednak jeśli masz ich dużo — to narzędzie jest bardzo przydatne.

Jade nie używa już tego dokładnie w tej formie z powodu aktualizacji Figma. Obecnie używa znacznie więcej sections do strukturowania pracy, zamiast auto-layout frames na górze ekranów.

Jade stosuje stickery, które można przyczepić do każdego ekranu: Copy updated, Design updated, Implemented — różne stany dla zespołu inżynieryjnego.

Czasem korzysta z annotations w Figma, które służą podobnemu celowi. Inne elementy to opisy (description) i dokumentowanie trade-offs. Wszystko zależy od tego, co jest najbardziej efektywne w danym momencie.

---

Wyrównaj jednego, nie wszystkich

Standardowo myślimy: Jako designer jestem odpowiedzialny za wyrównanie całego zespołu deweloperskiego. Muszę przeprowadzić wszystkich przez design, odpowiedzieć na każde pytanie każdego członka zespołu oraz upewnić się, że wszyscy rozumieją uzasadnienie i szczegóły.

W praktyce okazuje się, że: Wystarczy dogłębnie wyrównać jednego właściwego inżyniera (lub feature leada) — następnie on wyrówna resztę zespołu. Jak zauważa Jade, w niektórych projektach feature lead wyjaśniał wszystko zespołowi w jej imieniu, dzięki czemu nie musiała wykonywać tej samej pracy wielokrotnie. To sposób na skalowanie przekazu bez duplikowania wysiłku.

Dlaczego to jest istotne: Zmienia to podejście z „muszę być dostępny dla wszystkich” na „muszę dobrze wyrównać właściwą osobę”. Inżynierowie często lepiej tłumaczą techniczne szczegóły innym inżynierom niż designer, dlatego zyskujesz multiplier effect zamiast linear scaling.

Test na jutro: Następnym razem gdy planujesz design handoff, zamiast zapraszać cały zespół deweloperski na walkthrough, znajdź feature leada lub najbardziej zaangażowanego seniora w zespole. Wyrównaj go dogłębnie przez Loom i sync session, następnie poproś, żeby przekazał to zespołowi. Sprawdź, czy efekt jest lepszy niż grupowe demo dla wszystkich.

---

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 tutaj: [Podcast Deep Dive z Jay i Jade z Atlassian]