Notatki z rozmowy Jay’a (Sneak Peek) z designerami z wiodących firm technologicznych. Wszystkie przemyślenia, obserwacje i metody pracy pochodzą bezpośrednio od rozmówców. Checklisty i kluczowy insight to interpretacja na bazie przedstawionych informacji.
TL;DR
- Jeden wielki plik może działać – zespół Firefox używa Mobile Assembly File dla wszystkich projektów mobile, co ułatwia współpracę między strefami czasowymi
- Ready for dev zawsze na górze – finalne specs i handoff trafiają na szczyt hierarchii stron, chaos zostaje na dole
- Readme z linkami oszczędza godziny – miniatura ze statusem, linki do Slack channels i PRD to must-have dla każdego projektu
- Personal pages to klucz do portfolio – dedykowane strony dla każdego designera zachowują pełną historię iteracji bez zaśmiecania głównego flow
- Możesz być messy w szczegółach – najlepsi designerzy nie nazywają layerów, ale mają świetny system na wyższym poziomie
- Sekcje i kolory prowadzą przez workflow – kolorowanie różnych ścieżek (purple path vs blue path) pomaga nawigować po skomplikowanych procesach
- Template „Duplicate Me” to standardowy start – gotowa struktura zapewnia konsystencję, але każdy dostosowuje ją do swojego stylu
Materiał prezentuje rzeczywiste metody organizacji plików Figma stosowane przez designerów z Figma, Firefox, Webflow i innych firm technologicznych. Każdy rozmówca pokazuje nieco inny system, jednak pewne wzorce powtarzają się konsekwentnie.
Jeden wielki plik vs wiele małych – co wybierają top designerzy?
Większość zespołów tworzy osobny plik dla każdego projektu. Zespół Firefox wybrał jednak zupełnie odmienne podejście – używa jednego wielkiego pliku dla wszystkich projektów mobile, nazwanego Mobile Assembly File. To było początkowo eksperyment, który następnie stał się stałą praktyką.
Wcześniej zespół utrzymywał osobny plik per feature lub per core surface. Gdy rozpoczęli zmiany core design language, okazało się że lepiej mieć wszystko w jednym miejscu. Może brzmieć to niepokojąco, gdy dziesięć osób pojawia się w jednym pliku, jednak dla rozproszonego zespołu pracującego w różnych strefach czasowych rozwiązanie to okazało się bardzo efektywne.
Zamiast przeskakiwać między plikami i szukać właściwych informacji, wystarczy przełączyć się między stronami. Designer może szybko sprawdzić co dzieje się w playground’u menu lub jaki corner radius zostanie użyty. Taki układ buduje poczucie wspólnej odpowiedzialności za design language.
Dlaczego jeden plik działa dla Firefox?
- Łatwy dostęp do tego co się dzieje w projekcie bez przeskakiwania między plikami
- Możliwość szybkiego sprawdzenia pracy innych (corner radius, playground menu)
- Budowanie poczucia wspólnej odpowiedzialności za design language
- Doskonałe rozwiązanie dla zespołów rozproszonych czasowo
- Każda major surface (onboarding, toolbar, menu, homepage) ma swoją wydzieloną sekcję
Organizacja opiera się na podziale według major surfaces. Zazwyczaj jeden designer pracuje nad jedną surface, czasem nad kilkoma. Z kolei designer z Webflow prezentuje bardziej typowe podejście – osobne pliki dla różnych projektów, ale ze standardową strukturą. Ta metoda sprawdza się lepiej, gdy projekty są mniej powiązane lub zespół jest większy.
Hierarchia stron – od specs do graveyard
Wszyscy rozmówcy zgadzają się w jednej kwestii: to co najważniejsze musi być na górze.
Jeden z designerów wyjaśnia swój system od początku projektu. Na starcie dzieli wszystko na sekcje – strona nazwana crit lub check-ins, sekcja na explorations, następnie nowe strony tworzone w miarę potrzeb. Na samym końcu znajduje się cover i graveyard dla randomowych rzeczy, co do których designer nie jest pewien.
W miarę rozwoju projektu hierarchia się odwraca. Explorations zostają podzielone na różne rundy pracy, żeby można było do nich wrócić. Powyżej znajdują się reviews – crits, check-ins, product alignment – posortowane po dacie. Na samym szczycie, gdy projekt jest gotowy do handoff, pierwszą rzeczą jaką ktoś zobaczy jest end spec.
Jak wygląda handoff dla engineerów?
End spec zawiera dokumentację pracy – to co zespół robi, to co było wcześniej, oraz plany na przyszłość. Ważną zasadą jest umieszczenie static screens i prototype w jednym miejscu. Podczas handoff engineerzy wchodzą do end-to-end file, gdzie mogą zobaczyć zarówno statyczne ekrany jak i prototyp, następnie wybierają preferowaną formę.
Designer z Figmy stosuje podobne podejście. Wszystko co jest dev ready, trafia na górę z użyciem strzałek pokazujących zawartość sekcji – Milestone 1, Milestone 1 prototype, Milestone 2, components. Poniżej znajduje się emoji budowy jako separator. Wszystko pod tą linią to work in progress albo archived work linkujące do osobnego pliku.
Możesz być messy – ale tylko na dole
Designer z Figmy przyznaje się otwarcie: „Jestem super messy designerem. Nie nazywam swoich layerów.” Ma jednak świetny system na wyższym poziomie. Istnieje messy basement pliku, gdzie w zasadzie tylko ten designer wie co się dzieje, podczas gdy wszystko powyżej jest zorganizowane dla innych ludzi.
To daje permission to be messy w szczegółach. Kluczowy jest podział – ważne jest utrzymanie clear separation między tym co jest gotowe dla cross-functional partners a przestrzenią gdzie nie ma tylu zasad, dzięki czemu designerzy mogą swobodnie współpracować.
Personal pages – sekret dobrego case study
Designer z Webflow stosuje metodę personal pages. Tworzy osobną stronę, gdzie wpisuje co projektuje i datę. Strona ciągnie się w nieskończoność, a co ważniejsze – żadne poprzednie iteracje nie zostają usunięte ani nadpisane.
Wiele rzeczy które zostały tam zaprojektowane, pojawia się ponownie za tydzień. I znowu tydzień później. To rozwiązanie powstało jako odpowiedź na częsty problem designerów z uchwyceniem procesu do case studies czy storytellingu. Dzięki temu można bardzo łatwo wrócić do całej pracy wykonanej nad projektem.
Praktyczna korzyść pojawia się w rozmowach z zespołem. Wystarczy wspomnieć że mockupy dla danego pomysłu powstały tydzień temu, następnie wejść do personal page, spojrzeć tydzień wstecz i odnaleźć konkretną pracę.
Readme i dokumentacja – jak ułatwić życie zespołowi
Designer z Figmy pokazuje Readme template stosowany na początku każdego pliku – metodę podpatrzoną od koleżanki z zespołu. Zawiera tytuł projektu, informację do kogo się zwrócić, zespół, Slack channels oraz linki do PRD.
Szczególnie istotny element to link do Slack channel. Często podczas pracy nad projektem pojawiają się pytania o lokalizację rozmowy czy prośby o dodanie do kanału. Zlinkowanie tego z góry eliminuje ten problem całkowicie.
Designer odpowiada z filozoficznym spostrzeżeniem: chcesz połączyć swoje Slacki, pliki Figma i zlinkować wszystko ze wszystkim, ponieważ czym w ogóle jest źródło prawdy? Nie mamy tego już. To kluczowa obserwacja o współczesnej pracy. Source of truth nie istnieje, dlatego trzeba linkować wszystko ze wszystkim i dokumentować gdzie co się dzieje.
Status thumbnails i title cards
Kolorowe miniatury statusu to kolejna metoda – zielona oznacza shipped, żółta work in progress. W przeglądarce plików bardzo łatwo zobaczyć co zostało wysłane i nad czym trwa praca.
Niektóre zespoły tworzą title card jako component. Zawiera tytuł, zabawne emoji, informację kto nad tym pracuje oraz state projektu. Designer dodaje z humorem – Figma if you’re listening, chcielibyśmy trochę więcej kontroli first-class, ale na razie to działa.
Ta prosta metoda oszczędza mnóstwo czasu w projektach z dziesiątkami plików.
Wykresy Gantta dla kontekstu
Designer z Figmy dodaje uproszczony wykres Gantta bezpośrednio w Readme ze wszystkimi milestones i datami. Są to przybliżone daty, jednak nadal przydatne żeby zespół zobaczył – okay, zaczynamy od learning experiment żeby de-risk, potem kolejne etapy dla mobile.
Istnieje też bardziej szczegółowy wykres Gantta dla engineeringu, jednak ten uproszczony daje big picture ludziom bez żadnego kontekstu.
Kiedy to powstaje? Nie od razu. To się dzieje gdy zespół już projektuje i planuje projekt. Praca z PM nad podziałem na kluczowe etapy, gdzie z każdym milestone powstaje wizualna reprezentacja jak to będzie wyglądać.
Sekcje i kolory – wizualna nawigacja po workflow
Designer opowiadający o workflow-heavy projekcie pokazuje metodę używania sekcji. Zawsze układa cały workflow – był step one, step two, a w step two wiele rzeczy które można robić. Workflows dla step two są układane od lewej do prawej z oznaczeniem headerami, następna sekcja to step three, step four.
W tym konkretnym projekcie były dwie możliwe ścieżki. Zaczynasz od step one i wybierasz między dwoma różnymi sposobami alokacji budżetu. Tutaj pojawia się kolorowanie:
- Purple = Target Increase workflow wraz z odpowiadającymi panelami akcji
- Blue = Distribute Directly to Managers workflow wraz z jego panelami
- Gray = pierwszy i ostatni step wspólne dla obu ścieżek
Panele akcji są również dopasowane kolorami. Purple path ma swoje panele, blue path ma swoje – dosłownie jak Matrix, gdzie wybierasz purple path czy blue path.
Skala projektu? To był tylko pierwszy etap. Drugi etap miał może dwa razy więcej ekranów. Designer z Webflow pokazuje podobne podejście z sekcjami do dalszej organizacji płócien, z możliwością oznaczania jeśli pewne motywy wyłaniają się z tych stron.
Datowanie i archiwizacja – jak nie zgubić się w historii
Designer z Webflow wyjaśnia system datowania explorations. Daty są pomocne jako punkt odniesienia podczas pracy w weekly cycles. Gdy zaczynasz eksplorować i patrzeć na wiele divergent solutions, strona może stać się przytłaczająca.
Rozwiązanie polega na dzieleniu rzeczy między stronami tydzień po tygodniu. Zamiast mieć wszystko zrzucone na jednym canvas wymagającym przeszukiwania, można oznaczać strony jeśli pewne tematy się wyłaniają. Nie musisz przeskakiwać przez wszystko żeby znaleźć coś – możesz szybko znajdować rzeczy.
Temporary archive i kiedy przenosić
Designer pokazujący długi projekt (kwiecień-wrzesień) utrzymuje sekcję „temporary archive”. Zawiera rzeczy których nie używamy, ale są nadal istotne do referencji – może w dyskusjach, podczas przeglądania pliku czy review z leadership.
Nazywa się temporary, ponieważ w pewnym momencie te rzeczy muszą zostać przeniesione. Archive było kiedyś dużo większe – może sześć stron. Są jednak wyciągane w pewnym momencie, bo inaczej plik nie jest już zarządzalny.
Gdzie je przenosić? Do osobnego archive file. Zespół utrzymuje archives dla products, gdzie można zobaczyć pliki z wcześniejszymi explorations, które nie są już konieczne do przeglądania.
Template i standardy – jak zaczynać nowe projekty
Designer pokazuje standardowy template używany w zespole. Zaczynają każdy nowy projekt bazując na template nazwanym Duplicate Me, ponieważ zawiera wszystko czego potrzeba żeby zacząć.
Cztery standardowe strony:
Main
- Wszystko co jest ready to go, finalized, ready to ship and build
- Filozofia: ludzie są zachęcani żeby wskakiwać bez względu na to kim są i mieć przestrzeń żeby zrozumieć co się dzieje
Wireframes
- Working area i scratch pad
- Miejsce na iteracje
Research
- Screenshoty i notatki z researchu
- Referencje i insights
Archive
- Dumping ground dla rzeczy które wyrzucamy ale nie chcemy usunąć
- Można referencować z powrotem, jednak nie jest to bezpośrednio istotne
Designer podkreśla – każdy ma swój styl, to co działało dla niego. Czasem nawet nie używa wszystkich stron. Inny designer dodaje swój twist – strony z emoji test tube dla specific features, podobne do wireframe scratch pad type page, ale do myślenia o innych rozwiązaniach dla bardzo specyficznej featury.
Jak kierownik designu używa Figmy do śledzenia pracy
Jeden z rozmówców będący head of design pokazuje jak używa Figmy z innej perspektywy. Tęskni oczywiście za dniami gdy codziennie pracował nad szczegółami projektowymi, jednak Figma jest nadal przydatna do zrozumienia co robi zespół, dostarczania opinii projektowej oraz monitorowania pracy.
Sprawdza szczególnie rzeczy jak design infra projects – design system, employee experience work, nawet wpisy blogowe. Co designerzy mogą zrobić żeby ułatwić życie kierownikowi? Zespół niedawno przeszedł na wyższą wersję Figma organization, więc są nadal w fazie przejściowej porządkowania struktury, jednak starają się dobrze robić title cards.
Title cards zawierają tytuł, zabawne emoji, informację kto nad tym pracuje oraz state. Jednym ze sposobów jak organizują plik żeby był jak najbardziej self-servable to… główna strona jako miejsce gdzie ludzie mogą wskakiwać bez względu na to kim są, następnie mieć przestrzeń żeby zrozumieć co się dzieje i zobaczyć najnowsze rzeczy.
Zależy oczywiście od designera – wszyscy mają swój własny poziom cleanliness, jednak zespół głęboko zachęca do jakiejś struktury w pages. Main page to miejsce gdzie jest najczyściej i najbardziej zrozumiale.
Checklisty dla praktyków
Co powinien zawierać Readme?
- Tytuł projektu
- Do kogo się zwrócić (team members)
- Link do Slack channel projektu
- Linki do PRD i dokumentacji
- Miniatura statusu (shipped/WIP)
- Uproszczony wykres Gantta lub timeline (opcjonalnie)
Setup nowego projektu w Figmie
- Zduplikuj template „Duplicate Me” lub stwórz strukturę Main/Wireframes/Research/Archive
- Dodaj Readme z tytułem, team members i linkami do Slack/PRD
- Ustaw miniaturę statusu lub title card component
- Stwórz personal page dla siebie (jeśli pracujesz w zespole)
- Oznacz datą pierwsze exploration sessions
- Przygotuj sekcję „Ready for dev” na górze (nawet jeśli pusta)
- Dodaj emoji separatory (🚧 dla WIP, 🏁 dla done)
Przed przekazaniem do devs
- Wszystkie finalne specs przeniesione na górę hierarchii
- End-to-end flow widoczny jako pierwszy
- Dokumentacja w stylu „to robimy, to było wcześniej, to planujemy”
- Static screens + prototype w jednym miejscu
- Work in progress schowany poniżej separatora
- Temporary archive przeniesione do osobnego pliku (jeśli plik za duży)
- Readme zaktualizowane z finalnymi linkami
Co z tego wyciągnąć
Nie ma jednego właściwego sposobu organizacji plików Figma. Designer z Firefox używa jednego wielkiego pliku, z kolei designer z Webflow rozdziela wszystko na osobne projekty. Designer z Figmy tworzy szczegółowe wykresy Gantta. Jeden przyznaje się że nie nazywa layerów, podczas gdy inny ma wszystko ultra-zorganizowane.
Jednak kilka rzeczy powtarza się konsekwentnie:
- Najważniejsze na górze – Ready for dev, end specs, finalne deliverables muszą być pierwsze
- Clear separation – Przestrzeń dla cross-functional partners oddzielona od przestrzeni dla designerów bez reguł
- Source of truth nie istnieje – Dlatego linkujesz wszystko ze wszystkim (Slack, Figma, PRD)
- Messy jest OK na dole – Możesz nie nazywać layerów, jeśli masz system na wyższym poziomie
- Readme oszczędza czas – Trzy minuty setupu za godziny szukania
- Wizualne cues działają – Miniatury statusu, emoji, kolorowe sekcje przetwarza się szybciej
- Template to fundament – Jednak każdy ma swój styl i dostosowuje do swojego flow
Zacznij od template. Dostosuj do swojego flow. Daj sobie permission to be messy w szczegółach. Pilnuj żeby to co ważne było widoczne dla innych. Reszta się ułoży.
Kluczowy insight
Organizacja przez separację, nie perfekcję
Standardowo myślimy: Dobra organizacja pliku Figma to wszystko nazwane, wszystko na swoim miejscu, zero chaosu. Jeśli nie nazywasz layerów i masz bałagan, to znaczy że jesteś niezorganizowany.
W praktyce okazuje się, że: Najlepsi designerzy nie organizują wszystkiego – organizują tylko to co widzą inni. Designer z Figmy mówi wprost: jestem super messy designerem, nie nazywam swoich layerów. Jednak wszystko co jest dla cross-functional partners jest perfekcyjnie zorganizowane. Chaos zostaje w messy basement gdzie tylko on wie co się dzieje.
Dlaczego to jest istotne: Próba utrzymania perfekcji wszędzie paraliżuje i spowalnia. Clear separation między przestrzenią publiczną (góra – ready for dev) a przestrzenią prywatną (dół – personal pages, exploration) daje swobodę poruszania się szybko tam gdzie trzeba, bez zamulania tego co widzą inni.
Test na jutro: Następnym razem gdy zaczniesz nowy projekt, zamiast organizować każdy layer i każdy frame, stwórz tylko wyraźny podział: sekcja „Ready for others” na górze (nawet pusta) i „My workspace” na dole. Pozwól sobie być messy w swojej przestrzeni i sprawdź czy nie pracujesz szybciej.
Metadane
Główne słowo kluczowe: organizacja plików figma
Słowa kluczowe: figma file organization, figma best practices, design workflow figma, figma template, firefox design team, webflow design process, figma sections tutorial, design system organization, figma handoff process, personal pages figma
Zajawka (150 znaków): Jak designerzy z Figma, Firefox i Webflow organizują pliki? Sprawdzone metody od ekspertów do wdrożenia dziś.
Description (150 znaków): Praktyczny przewodnik organizacji plików Figma. Readme, sekcje, archiwum, personal pages – wszystko czego potrzebujesz.
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: Sneak Peek – The Figma File Organization Masterclass