Figma to narzędzie do projektowania interfejsów i prototypowania, działające w przeglądarce, z pracą wielu osób na jednym pliku w czasie rzeczywistym. Standard rynkowy w zespołach produktowych; do warsztatów i diagramów ma siostrzaną tablicę FigJam.
Analityk biznesowy w Figmie głównie czyta i komentuje: przegląda projekty UX pod kątem zgodności z wymaganiami, podpina ekrany do historyjek, wyłapuje rozjazdy między makietą a regułami biznesowymi. Coraz częściej też sam składa proste makiety lo-fi - szkic ekranu potrafi zastąpić stronę opisu tekstowego i trzy spotkania.
W MediFlow komentarz analityka w Figmie uratował sporo nerwów: projektant na ekranie wyboru terminu ukrył lekarzy bez wolnych slotów w najbliższym tygodniu - wyglądało czyściej. Tyle że wymaganie mówiło: pokazuj wszystkich lekarzy z najbliższą dostępną datą, bo pacjent często woli poczekać trzy tygodnie do „swojego" lekarza, niż iść jutro do obcego. Rozjazd wyłapany na makiecie kosztował jeden komentarz; wyłapany po wdrożeniu kosztowałby sprint.
Częsta pomyłka: traktowanie makiety jako specyfikacji. Makieta pokazuje szczęśliwą ścieżkę i ładny stan - nie pokazuje walidacji pól, komunikatów błędów, stanów pustych ani reguł biznesowych pod spodem. „Zrobimy jak na Figmie" bez dokumentu wymagań kończy się tym, że deweloper sam decyduje, co się stanie po błędzie płatności. Druga pomyłka: przekonanie, że analityk musi umieć projektować. Nie musi - musi umieć czytać projekt i wiązać go z wymaganiami.
Czym jest Figma i do czego służy analitykowi
Najkrócej: to miejsce, w którym powstają ekrany aplikacji, zanim ktokolwiek napisze linijkę kodu. Ty najczęściej dostajesz do niej link, a nie licencję.
Co zobaczysz, gdy ten link otworzysz. Po lewej lista stron pliku, na stronie ramki, czyli pojedyncze widoki aplikacji. Po prawej panel z właściwościami zaznaczonego elementu: rozmiary, kolory, czcionki. Przewijasz, przybliżasz, klikasz w element i widzisz, z czego jest zbudowany. Jeśli masz prawo tylko do oglądania i komentowania, niczego nie zepsujesz.
Dla porządku, bo to pierwsze pytanie osoby, która widzi Figmę pierwszy raz: to nie jest narzędzie do prezentacji ani do grafik marketingowych. PowerPoint składa slajdy, Canva składa grafiki, Miro daje tablicę do wspólnego myślenia. Figma projektuje interfejs, czyli to, co użytkownik będzie klikał.
Czy analityk musi mieć płatną Figmę
To pytanie wraca przy każdym nowym projekcie i zwykle pada w złej formie: „potrzebuję dostępu do Figmy, kto to kupuje". W większości przypadków odpowiedź brzmi: nikt nie musi kupować niczego dla ciebie.
Figma ma plany płatne dla zespołów i osobny plan darmowy (Starter), ale sam podgląd i komentowanie stoją poza tym podziałem. Na stronie cennika wydawcy stoi wprost, że zaproszone osoby mogą „view, comment, inspect, or export from your Figma files - for free", a przy planach płatnych: „you can let others view and comment on your files without purchasing extra seats" (odczyt strony cennika Figmy z 19 sierpnia 2026). Płatne miejsca dotyczą osób, które w pliku pracują, czyli projektantów i deweloperów, nie twojego podglądu.
Praktyczny wniosek: nie proś o „dostęp do Figmy". Poproś o link z prawem komentowania. To jest inna prośba, tańsza, i zwykle dostaniesz ją tego samego dnia zamiast czekać na decyzję o budżecie narzędziowym.
Dwa zastrzeżenia, żeby ta rada nie wysadziła cię u klienta. Po pierwsze, nazwy planów, typy miejsc i limity planu darmowego zmieniają się co kilka kwartałów, więc przed rozmową o pieniądzach zajrzyj na aktualny cennik, a nie do tego akapitu. Po drugie, w większych organizacjach o dostępie nie decyduje cennik, tylko polityka bezpieczeństwa: administrator może wyłączyć udostępnianie na zewnątrz, wymusić logowanie przez firmowe konto albo zablokować eksport. „To nic nie kosztuje, wystarczy link" jest prawdą po stronie narzędzia i bywa nieprawdą po stronie działu IT klienta.
Komponent, instancja, biblioteka: słowa, które usłyszysz w pierwszym tygodniu
Hasło słownika ma uczyć słownictwa, więc trzy pojęcia z panelu po prawej stronie, które padają na każdym spotkaniu projektowym:
- komponent - element zaprojektowany raz i używany w wielu miejscach: przycisk, pole formularza, karta produktu. Ma swój oryginał, zwany komponentem głównym,
- instancja - użycie tego komponentu na konkretnym ekranie. Dlatego gdy projektant mówi „poprawka jest na komponencie", mówi ci coś o zakresie: zmiana dotknie ekranów, na których ten element występuje, poza tym, co na konkretnym ekranie zostało nadpisane ręcznie,
- biblioteka - wspólny zestaw komponentów udostępniony innym plikom, żeby cały produkt wyglądał tak samo.
Po co ci to. Zdanie „zmieniamy tylko komponent pola daty" brzmi jak drobiazg, a w rzeczywistości jest zapowiedzią zmiany wszędzie tam, gdzie to pole występuje, a każdy taki ekran może mieć własne reguły walidacji i własne kryteria akceptacji. Analityk, który rozumie to słowo, wie, kiedy zapytać „na których ekranach", zanim zespół zacznie estymować.
Komentarz w Figmie: gdzie kończy się jego ważność
Komentarz przypięty do konkretnego elementu to najmocniejsze narzędzie analityka w tym pliku. Trzy nawyki, które robią różnicę:
- Przypnij do elementu, nie do ekranu. „Coś tu nie gra z tym formularzem" wymaga od projektanta zgadywania. Komentarz przyklejony do pola „data urodzenia" nie wymaga niczego.
- Jedno pytanie na komentarz. Trzy wątki w jednym dymku kończą się odpowiedzią na jeden z nich i ciszą przy dwóch pozostałych.
- Powołaj numer. „Zgodnie z HIST-142 użytkownik bez roli kierownika nie widzi tego przycisku" zamyka sprawę. „Chyba nie każdy powinien to widzieć" otwiera dyskusję.
I rzecz, która wygląda na drobiazg, a bywa kosztowna: komentarz oznaczony jako rozwiązany znika z domyślnego widoku. Jeśli ustalenie żyje wyłącznie w takim dymku, to za trzy miesiące, przy pytaniu „dlaczego to działa właśnie tak", nikt go nie znajdzie. Figma jest miejscem rozmowy, nie rejestrem decyzji. Ustalenie z komentarza przepisujesz tam, gdzie zespół szuka prawdy: do historyjki, do kryteriów akceptacji albo do dokumentu wymagań.
Tryb prototypu: co udowadnia klikanie
W trybie prototypu ekrany są połączone przejściami i można je klikać jak działającą aplikację. To wygląda przekonująco i właśnie dlatego trzeba wiedzieć, co ten pokaz naprawdę potwierdza.
| Prototyp klikany dowodzi | Prototyp klikany nie dowodzi |
|---|---|
| Że ścieżka jest zrozumiała dla kogoś, kto widzi ekran pierwszy raz | Że dane, których ten ekran potrzebuje, w ogóle są dostępne |
| W którym miejscu użytkownik się zatrzymuje i pyta „i co teraz" | Że użytkownik z tą rolą ma prawo tu wejść |
| Ile kroków dzieli człowieka od celu | Co system zrobi, gdy płatność się nie powiedzie |
| Że nazewnictwo przycisków jest czytelne | Że lista załaduje się przy dziesięciu tysiącach pozycji |
Pierwsza kolumna to argument, żeby prototypować wcześnie. Druga to powód, dla którego prototyp nigdy nie zamyka tematu wymagań. Sama metoda prototypowania, poziomy wierności i moment sięgnięcia po szkic zamiast po makietę to osobny temat, rozpisany w tekście o prototypowaniu, wireframach i mockupach.
Tryb deweloperski: co przychodzi z pliku, a co od ciebie
Przy przekazaniu projektu do zespołu pada zdanie „wszystko jest w Figmie". Nie jest i to nie jest zarzut wobec projektanta. Plik projektowy z definicji opisuje warstwę widoczną, a deweloper ogląda go w trybie deweloperskim (Dev Mode) - tak nazywa się widok, w którym odczytuje się wymiary, odstępy i zasoby do pobrania. Nazwę dobrze znać, bo padnie na spotkaniu.
| Deweloper bierze z pliku | Musi dostać od analityka |
|---|---|
| Układ, odstępy, kolory, typografia | Kto ma prawo zobaczyć ten ekran i to pole |
| Ikony i zasoby graficzne do wyeksportowania | Zasady walidacji: co jest wymagane, jaki format, jaki zakres |
| Teksty widoczne na ekranie | Treść komunikatów o błędach i co po nich następuje |
| Nazwy komponentów i ich stany | Skąd biorą się dane i jak świeże mają być |
| Przejścia między ekranami | Co widzi użytkownik, gdy lista jest pusta albo ma tysiąc pozycji |
| Wymagania niefunkcjonalne i ślad audytowy operacji |
Prawa kolumna to twoja robota i nikt jej za ciebie nie zrobi. Jeśli zostanie pusta, decyzje z niej i tak zapadną, tylko podejmie je deweloper w trakcie pisania kodu, w piątek po południu, bez kontaktu z biznesem. Miejscem na tę kolumnę jest specyfikacja wymagań albo opis historyjki, nie komentarz na makiecie.
Historia wersji, czyli która makieta obowiązuje
Plik w Figmie jest żywy. Link, który wysłałeś biznesowi w poniedziałek, w czwartek pokazuje już inny ekran, bez żadnego ostrzeżenia. Dla dokumentu wymagań to jest problem, bo historyjkę pisałeś na stanie sprzed dwóch tygodni.
Narzędzie ma na to odpowiedź i mało kto z niej korzysta: historię wersji. Plik zapisuje kolejne stany, a wybrany moment można nazwać (na przykład „uzgodnione na przeglądzie 12.08") i wrócić do niego później. Z jednym zastrzeżeniem, które ciebie dotyczy bezpośrednio: nazwać wersję i do niej wrócić może edytor, więc z prawem do komentowania nie zrobisz ani jednego, ani drugiego. Możesz o to poprosić.
Stąd dwie zasady na co dzień:
- Poproś projektanta, żeby nazwał stan uzgodniony na przeglądzie, i powołaj tę nazwę w historyjce razem z jednym zdaniem, co zostało ustalone i kiedy. Sam link do pliku zawsze pokazuje stan na dziś, więc jako dowód uzgodnienia jest bezwartościowy. Do dokumentu dołóż zrzut ekranu, nie dlatego, że jest lepszy od historii wersji, tylko dlatego, że nie wymaga niczyjej uprzejmości.
- Zmiana makiety po estymacji to zmiana zakresu, nie „drobna poprawka w Figmie". Nazwanie tego po imieniu w momencie, w którym się dzieje, jest tańsze niż tłumaczenie się z terminu miesiąc później. Mechanika zjawiska: scope creep.
Figma, FigJam, tablica, notacja: co gdzie rysować
Najczęstszy błąd narzędziowy w tej okolicy to nie wybór złego programu, tylko postawienie trwałego artefaktu w miejscu, które jest z natury tymczasowe.
| Co rysujesz | Gdzie to należy |
|---|---|
| Ekrany aplikacji i przejścia między nimi | Plik projektowy w Figmie |
| Warsztat, karteczki, głosowanie, rozgrzewka | FigJam albo Miro |
| Proces biznesowy w notacji | Narzędzie do BPMN |
| Model systemu, przypadki użycia, klasy | Narzędzie do UML |
| Mapa podróży klienta | Powstaje na tablicy, ale wynik ląduje w dokumencie |
Zasada do zapisania: rysunek, który ma być czytany za rok przez kogoś spoza zespołu, nie mieszka na tablicy warsztatowej. Tablica jest do myślenia razem. Dokument jest do znajdowania odpowiedzi po fakcie.
Można w Figmie narysować coś, co wygląda jak diagram procesu. Wyjdzie z tego rysunek, a nie model: bez walidacji notacji, bez możliwości zrobienia z nim czegokolwiek dalej, za to z pełną swobodą narysowania bramki, która w BPMN nie istnieje.
Czy Figma jest wymagana w ogłoszeniach dla analityków
Zamiast opierać się na wrażeniu, policzyliśmy we własnych danych. Odczyt tabeli ofert zasilającej moduł /praca i Barometr rynku, stan na 19 sierpnia 2026: 324 aktywne ogłoszenia w kategoriach analitycznych (308 w kategorii analityk, czyli biznesowy, systemowy i pokrewne, oraz 16 w kategorii analityk danych; źródła: justjoin.it, rocketjobs.pl, NoFluffJobs, Adzuna).
| Narzędzie lub notacja | Liczba ogłoszeń z wzmianką |
|---|---|
| BPMN | 43 |
| UML | 41 |
| Jira | 36 |
| SQL | 30 |
| Confluence | 27 |
| Excel | 10 |
| Figma | 2 |
| Miro | 1 |
| Axure | 1 |
Metoda i jej granica: przeszukujemy tytuł ogłoszenia, listę umiejętności i zajawkę. Pełnych treści ogłoszeń nie przechowujemy, bo linkujemy do źródła zamiast je kopiować. Każda z tych liczb jest więc dolnym oszacowaniem i nie należy jej czytać jako „tyle procent rynku wymaga X". Nie ma tu też podziału na typ roli, więc z dwóch ogłoszeń z Figmą nie da się orzec, w jakich zespołach się pojawia.
Wniosek, na który te dane pozwalają, jest węższy i wciąż użyteczny: Figma rzadko bywa dla pracodawcy na tyle ważna, żeby trafić do tytułu, listy umiejętności albo zajawki. BPMN i UML pojawiają się tam ponad dwadzieścia razy częściej, Jira i Confluence kilkanaście razy częściej.
Czyli: nie jest to umiejętność, na której zbudujesz kandydaturę. Jest to umiejętność wygodna. Bez niej nie obejrzysz tego, o czym zespół rozmawia na spotkaniu, a nauczysz się jej w godzinę.
Minimum, które opanujesz w godzinę
Sześć rzeczy. Nie ma tu rysowania i to jest celowe.
- Otworzyć link i przełączać się między stronami po lewej.
- Przypiąć komentarz do konkretnego elementu i oznaczyć w nim osobę.
- Uruchomić tryb prototypu i przejść ścieżkę tak, jak zrobi to użytkownik.
- Skopiować teksty widoczne na ekranie, zamiast przepisywać je ręcznie do dokumentu.
- Wyeksportować ramkę do obrazu, żeby wkleić do specyfikacji stan uzgodniony na dziś.
- Sprawdzić nazwę komponentu, żeby mówić o nim tym samym słowem co projektant i deweloper.
Czego nie musisz umieć: projektować ekranu od zera, układać komponentów, budować systemu projektowego. To jest zawód projektanta i nikt nie oczekuje, że go przejmiesz. Twoja przewaga w tym pliku polega na tym, że jako jedyna osoba przy stole trzymasz w głowie reguły biznesowe, których na ekranie nie widać.
Najczęstsze pytania o Figmę
Czy muszę mieć płatne konto, żeby oglądać makiety? Nie. Oglądanie, komentowanie i eksport nie wymagają dokupywania miejsca w zespole. Poproś o link z prawem komentowania.
Czy trzeba coś instalować? Nie. Figma działa w przeglądarce. Aplikacja na komputer istnieje i bywa wygodniejsza przy dłuższej pracy, ale do obejrzenia i skomentowania projektu nie jest potrzebna.
Czy analityk powinien sam rysować makiety? Nie na poziomie projektanta i nie w Figmie. Ale prosty szkic lo-fi, choćby na kartce, powinieneś umieć narysować, bo to technika wydobywania wymagań, a nie grafika. Rozwinięcie z kryterium „kiedy szkic zamiast opisu": tekst o prototypowaniu.
Czy zobaczę w Figmie, jak formularz zachowa się po błędzie? Prawie nigdy i to jest sedno całej tej strony. Projekt pokazuje stan, który ktoś narysował. Jeśli nikt nie narysował ekranu z komunikatem o odrzuconej płatności, to znaczy tylko tyle, że nikt o nim nie pomyślał. Opisanie tego jest twoją robotą, nie brakiem w pliku.
Czy da się w Figmie prowadzić warsztat wymagań? Tak, na tablicy FigJam. Sama facylitacja jest osobną umiejętnością: warsztat wymagań.
Gdzie iść dalej
- Metoda, a nie narzędzie: prototypowanie, wireframy i mockupy.
- Pojęcia, które wracają przy każdej makiecie: wireframe, mockup, prototyp.
- Co robić z tym, co wyszło na makiecie: specyfikacja wymagań i testowanie wymagań.
- Makieta jest jedną z technik wydobywania wymagań, obok wywiadu i obserwacji. Pozostałe: 10 technik elicytacji, a jeśli chcesz sprawdzić, czy umiesz dobrać technikę do sytuacji, jest na to test bez zakładania konta: Elicytacja wymagań w praktyce.
- Darmowe konto na platformie daje pierwszą lekcję każdego kursu i trzy podejścia do testów miesięcznie: rejestracja.