Masz gotowy projekt strony internetowej w Figmie i chcesz zamienić go w działającą stronę WordPress?
Na pierwszy rzut oka proces wydaje się prosty: projekt Figma → programowanie → WordPress → publikacja.
W praktyce jednak pomiędzy gotowym projektem graficznym a działającą stroną internetową znajduje się kilka istotnych etapów.
Figma pokazuje przede wszystkim, jak strona ma wyglądać i jak powinien zachowywać się interfejs. Nie określa jednak automatycznie:
Dlatego też profesjonalne wdrożenie projektu Figma do WordPress nie polega wyłącznie na odwzorowaniu grafiki. To proces przekładania projektu interfejsu na działający, responsywny i możliwy do dalszego rozwoju system.
W tym poradniku wyjaśniamy:
Określenia takie jak:
opisują w praktyce proces, w którym przygotowany wcześniej projekt UX/UI zostaje wdrożony jako działająca strona oparta o WordPress.
Jeżeli szukasz zespołu, który może przejąć taki etap realizacji, zobacz naszą usługę Figma do WordPress – kodowanie i wdrożenie projektu graficznego.
Nie jest to jednak zwykła konwersja jednego formatu pliku na drugi. Figma jest narzędziem projektowym. Z kolei WordPress jest systemem służącym do zarządzania treścią.
Pomiędzy nimi trzeba zbudować warstwę techniczną, która odpowiada między innymi za:
Dopiero po wykonaniu tych prac projekt graficzny staje się rzeczywiście działającą stroną internetową.
Istnieją narzędzia, które potrafią generować na podstawie projektu:
Takie rozwiązania mogą przyspieszyć przygotowanie prototypu lub części warstwy frontendowej. Sama Figma również oferuje narzędzia wspierające przekazanie projektu do programowania. Dev Mode pozwala m.in. analizować właściwości warstw i komponentów, pobierać materiały, sprawdzać odstępy oraz korzystać z generowanych fragmentów kodu. Takie funkcje mogą istotnie przyspieszyć pracę programisty, ale nadal nie definiują całej architektury strony WordPress, sposobu zarządzania treścią ani logiki biznesowej.
Nie oznacza to jednak automatycznie powstania kompletnej strony WordPress.
W projekcie produkcyjnym trzeba nadal zdecydować między innymi:
Dlatego też automatyczne wygenerowanie kodu i wdrożenie produkcyjnej strony WordPress to dwie różne rzeczy. W prostym projekcie automatyzacja może przyspieszyć część pracy. Z kolei w bardziej rozbudowanym serwisie kluczowa pozostaje jednak architektura rozwiązania.
Nie zawsze. Można wyróżnić trzy typowe sytuacje.
Figma zawiera:
W takiej sytuacji można stosunkowo szybko przejść do analizy technicznej i programowania.
Brakuje np.:
Wtedy brakujące elementy można uzupełnić przed rozpoczęciem właściwego programowania.
Klient może posiadać:
W takim przypadku warto najpierw dopracować UX/UI, a dopiero później traktować projekt jako specyfikację do programowania.
Więcej o różnicy pomiędzy samym projektem graficznym a pełnym procesem UX/UI opisujemy w artykule Projekt strony internetowej – ile kosztuje design i UX?
Przed przekazaniem projektu programistom warto zaplanować uporządkowane przekazanie projektu do programowania (design handoff).
Nie chodzi wyłącznie o wysłanie samego linku: „Tutaj jest Figma”.
Wykonawca powinien być w stanie jednoznacznie ustalić:
Dobrze przygotowany handoff znacząco ogranicza liczbę pytań pojawiających się już podczas programowania.
Nie trzeba projektować osobno każdej podstrony, jeżeli wiele z nich korzysta z tego samego szablonu.
Trzeba jednak pokazać wszystkie unikalne typy widoków.
Przykładowo:
Jeżeli pięćdziesiąt stron usługowych korzysta z jednego układu, nie trzeba projektować pięćdziesięciu osobnych ekranów. Ważne jest określenie szablonu i możliwych wariantów treści.
Dobrze przygotowany projekt powinien jasno wskazywać elementy wielokrotnego użytku, np.:
Ma to duże znaczenie podczas programowania. Jeżeli w Figmie istnieje jeden spójny komponent, powinien również zostać zaimplementowany w sposób umożliwiający jego konsekwentne wykorzystanie w całym serwisie.
Projekt powinien jednoznacznie definiować:
Problemy pojawiają się, gdy np. dwa wizualnie identyczne nagłówki wykorzystują przypadkowo różne wartości. Takie rozbieżności warto uporządkować jeszcze przed programowaniem.
Warto zdefiniować spójną paletę:
Pozwala to później odwzorować je jako logiczny system w kodzie, zamiast tworzyć dziesiątki przypadkowych wartości.
W projekcie powinny być możliwie spójne:
Jeżeli jedna sekcja korzysta z 72 px odstępu, druga z 75 px, a trzecia z 80 px bez świadomego uzasadnienia, przed developmentem warto zdecydować, czy jest to zamierzone. W przeciwnym razie niespójność z projektu zostanie po prostu przeniesiona do kodu.
Programista powinien mieć dostęp do właściwych:
Warto również jasno określić, które pliki są finalne.
Statyczny widok przycisku to za mało.
W zależności od projektu potrzebne mogą być stany:
Szczególnie ważny jest focus, ponieważ ma znaczenie dla obsługi strony przy użyciu klawiatury i dostępności.
Projekt powinien pokazywać nie tylko: poprawnie wypełniony formularz.
Warto określić również:
Dzięki temu implementacja nie wymaga projektowania tych stanów już podczas programowania.
Jeżeli projekt jest już przygotowany, możemy przeanalizować jego kompletność, zakres funkcjonalny i sposób wdrożenia do WordPress lub WooCommerce.
Nie ma jednej obowiązkowej liczby szerokości ekranu, którą każdy projekt musi posiadać. Strona internetowa nie działa wyłącznie na trzech rozdzielczościach: desktop → tablet → telefon.
Pomiędzy nimi istnieje wiele innych szerokości. Dlatego ważniejsze od przygotowania kilkunastu identycznych ekranów jest określenie zasad responsywnego zachowania.
Projekt powinien odpowiadać między innymi na pytania:
Dla większości projektów warto przygotować przynajmniej reprezentatywne widoki desktop i mobile oraz wskazać zachowanie bardziej złożonych komponentów. Jeżeli tablet wymaga zupełnie innej kompozycji, również powinien zostać zaprojektowany.
Nie oznacza to, że projektu nie da się wdrożyć. Oznacza natomiast, że ktoś musi podjąć decyzje dotyczące mobile.
Może zrobić to:
Pozostawienie wszystkich decyzji dotyczących mobile wyłącznie programiście zwykle zwiększa ryzyko rozbieżności względem intencji projektanta i oczekiwanego UX. Programista może technicznie ustawić elementy pod sobą, ale nie musi to odpowiadać intencji projektanta ani optymalnemu UX. Dlatego w projektach o większym znaczeniu biznesowym brakujące widoki mobilne warto doprojektować, zamiast pozostawiać najważniejsze decyzje przypadkowi.
Celem wdrożenia powinno być precyzyjne odwzorowanie intencji projektu, ale określenie „pixel perfect” łatwo źle zrozumieć. Figma pokazuje konkretny ekran o konkretnej szerokości.
Strona internetowa działa natomiast na:
Treść również nie zawsze ma identyczną długość. Dlatego profesjonalne odwzorowanie nie powinno oznaczać: każda szerokość i wysokość jest na stałe zapisana w pikselach.
Powinno oznaczać:
Dobre RWD zachowuje charakter projektu, a nie tylko jego zrzut w jednej rozdzielczości.
To jeden z najczęstszych problemów podczas wyceny na podstawie projektu. Figma może pokazywać np. formularz kontaktowy.
Ale z samego widoku nie wiadomo:
Podobnie jest z:
Dlatego przy bardziej rozbudowanych projektach Figma powinna zostać uzupełniona o wymagania funkcjonalne. Projekt odpowiada głównie na pytanie: jak rozwiązanie ma wyglądać i zachowywać się z perspektywy użytkownika?
Wymagania funkcjonalne odpowiadają: co dokładnie ma się wydarzyć po wykonaniu konkretnego działania? Dopiero połączenie obu daje dobrą podstawę do rzetelnej wyceny i programowania.
To jeden z etapów, których klient najczęściej nie widzi. Projektant pracuje komponentami wizualnymi. Programista musi zdecydować, jak odwzorować je w strukturze systemu.
Przykładowo w Figmie możemy mieć:
Podczas wdrożenia trzeba zdecydować:
To właśnie dlatego dobrze zaprojektowany WordPress nie jest jedynie „obrazkiem przeniesionym do CMS”.
Nie każdy element powinien być edytowalny w taki sam sposób. Zbyt mała liczba możliwości edycji powoduje, że klient przy każdej zmianie musi kontaktować się z programistą. Zbyt duża swoboda może natomiast prowadzić do przypadkowego zepsucia layoutu lub utraty spójności.
Dlatego przed rozpoczęciem programowania warto odpowiedzieć:
Celem nie powinno być: „wszystko można zmienić”. Lepszym celem jest: „administrator może wygodnie zmienić wszystko, co rzeczywiście powinien zmieniać”.
Projekt z Figmy można wdrożyć do WordPressa na różne sposoby. Jednym z nich jest wykorzystanie kreatora stron czyli tzw. page buildera. Innym – stworzenie dedykowanego motywu. Nie istnieje rozwiązanie właściwe dla każdego przypadku.
W projektach Webtom.pl wdrażamy indywidualne projekty w oparciu o dedykowane rozwiązania WordPress, zamiast dopasowywać Figmę do gotowego szablonu.
Figma może dostarczyć programiście wiele informacji potrzebnych do implementacji:
Dev Mode może dodatkowo udostępniać właściwości warstw oraz generowane fragmenty kodu, a rozwiązania takie jak Code Connect pozwalają łączyć komponenty projektu z komponentami istniejącymi w kodzie. Nie oznacza to jednak, że wygenerowany fragment kodu jest automatycznie kompletną strukturą produkcyjnej strony WordPress.
Dobry frontend powinien dodatkowo uwzględniać:
Figma jest więc bardzo dobrym źródłem specyfikacji projektu, ale nie zastępuje decyzji programistycznych.
Pierwszym etapem powinno być sprawdzenie całej Figmy.
Analizujemy:
To również moment na ustalenie, które ekrany są rzeczywiście osobnymi szablonami.
Następnie trzeba ustalić, co poszczególne elementy robią. Projekt może wyglądać na prosty, ale kryć złożoną funkcję.
Dobrym przykładem jest wyszukiwarka.
Na ekranie to:
Od strony funkcjonalnej trzeba ustalić:
Jeżeli projekt zawiera braki, powinny zostać uzupełnione przed rozpoczęciem implementacji danego obszaru.
Mogą to być:
Nie każdy brak musi zatrzymywać cały projekt. Ważne jednak, aby decyzje projektowe były podejmowane świadomie.
Przed kodowaniem warto zidentyfikować:
Jeżeli w projekcie są przypadkowe rozbieżności, jest to dobry moment na ich wyjaśnienie. Kod powinien implementować spójny system, a nie powielać przypadkowe różnice.
Następnie ustala się między innymi:
To etap, w którym projekt interfejsu zaczyna być tłumaczony na architekturę CMS.
Na podstawie projektu powstają:
W tej fazie szczególnie ważne jest zachowanie spójności pomiędzy Figmą a rzeczywistą stroną.
Statyczny frontend zostaje połączony z treściami i funkcjami WordPressa.
Administrator otrzymuje możliwość zarządzania tymi elementami, które zostały przewidziane w zakresie projektu.
Jeżeli projekt wymaga:
są one implementowane jako część rozwiązania.
Strona jest testowana również pomiędzy szerokościami pokazanymi w Figmie.
Właśnie tutaj wychodzi na jaw, czy projekt rzeczywiście opisuje zasady RWD, czy tylko trzy statyczne zrzuty.
Projekt graficzny nie określa:
Są to decyzje wdrożeniowe. Jeżeli wydajność strony ma znaczenie biznesowe i SEO, warto uwzględniać ją już podczas programowania, a nie dopiero po publikacji.
Więcej o tym obszarze znajdziesz w poradniku Jak przygotować stronę WordPress pod Core Web Vitals?
Gotowa strona nie powinna od razu trafiać na produkcję.
Na środowisku testowym można sprawdzić:
Szerzej opisujemy to w artykule Staging WordPress i środowisko testowe – jak bezpiecznie testować zmiany na stronie?
Po testach klient powinien otrzymać wersję umożliwiającą końcową weryfikację. Po akceptacji następuje wdrożenie produkcyjne i ponowne sprawdzenie najważniejszych funkcji już na docelowej domenie.
Najprostszy sposób to porównywanie: Figma ↔ działający widok przy tej samej szerokości ekranu.
Sprawdzać należy między innymi:
Nie wystarczy jednak sprawdzić tylko desktopu.
Warto również kontrolować:
Dzięki temu można sprawdzić, czy odwzorowano system projektu, a nie tylko jeden ekran.
To bardzo normalna sytuacja.
Przykładowo:
Nie ma sensu bezrefleksyjnie odwzorowywać każdej niespójności.
Najlepiej:
Takie podejście ogranicza późniejszy dług projektowy i techniczny.
Nie powinien podejmować istotnych decyzji UX/UI bez uzgodnienia.
Może oczywiście wykryć:
Najlepszym procesem jest jednak: programista identyfikuje problem → projektant/klient podejmuje decyzję → rozwiązanie zostaje wdrożone.
Jeżeli zespół wdrożeniowy posiada również kompetencje UX/UI, problem można rozwiązać wewnętrznie. To jeden z powodów, dla których połączenie projektantów i programistów w jednym procesie ułatwia wdrażanie niekompletnych projektów.
W sklepie liczba scenariuszy jest znacznie większa niż przy zwykłej stronie firmowej.
Projekt powinien objąć nie tylko:
ale również cały proces zakupowy.
Trzeba ustalić:
Istotne mogą być:
Projekt powinien uwzględniać:
Nie wystarczy pokazać idealnie wypełnionego formularza.
Trzeba uwzględnić:
W zależności od sklepu potrzebne mogą być:
Sama atrakcyjna karta produktu nie jest więc kompletnym projektem sklepu WooCommerce.
Jeżeli kluczowe ekrany są jeszcze zmieniane, development może wymagać wielokrotnego przebudowywania tych samych elementów.
Programista jest wtedy zmuszony projektować zachowanie interfejsu podczas kodowania.
Każda sekcja zaczyna być wdrażana jako osobny przypadek.
Prowadzi to do większej liczby wyjątków i trudniejszego utrzymania strony.
Niewielkie różnice powtarzane na dziesiątkach komponentów szybko powodują brak wizualnej spójności.
Brakuje:
Widok pokazuje element, ale nie wiadomo, co powinno się wydarzyć po kliknięciu.
Dopiero pod koniec projektu klient dowiaduje się, że element, który chciał edytować, został zakodowany na stałe.
Strona wygląda dobrze przy 1440 px, ale przestaje działać przy 1280 px lub 1024 px.
Każda drobna różnica wydaje się niewielka, ale ich suma powoduje, że finalna strona wizualnie znacząco odbiega od projektu.
Ciężkie grafiki, niepotrzebne skrypty i nieoptymalna implementacja mogą później wymagać kosztownego poprawiania.
Projekt zawiera hover, ale nie ma focus.
Kolor jest estetyczny, ale nie zapewnia odpowiedniej czytelności.
Takie problemy warto identyfikować jeszcze przed zakończeniem wdrożenia.
Jeżeli Figma zmienia się podczas programowania, musi być jasne:
W przeciwnym razie zespół może implementować nieaktualny wariant.
Przed przekazaniem projektu wykonawcy sprawdź:
Ta ostatnia kwestia często jest równie ważna jak sam projekt.
Nie sama liczba ekranów.
Na nakład pracy wpływają między innymi:
Przykładowo: 20 prostych podstron korzystających z dwóch szablonów może wymagać mniej pracy niż pięć ekranów zawierających rozbudowane konfiguratory i integracje.
Dlatego przy wycenie ważniejsza jest złożoność rozwiązania niż sama liczba ramek w Figmie.
Dla prostej strony – często wystarczy do bardzo dobrego określenia zakresu.
Dla projektu posiadającego:
potrzebne będą dodatkowe informacje. Najlepszym zestawem wejściowym jest wtedy: Figma + lista funkcjonalności + opis integracji + zakres migracji + oczekiwania dotyczące CMS. Dzięki temu oferta nie musi opierać się na domysłach.
Przy wyborze wykonawcy nie warto kierować się wyłącznie deklaracją „robimy pixel perfect”.
Warto zapytać również:
Jeżeli odpowiedź brzmi: „programista coś wymyśli”
to warto doprecyzować odpowiedzialność.
Poproś o wyjaśnienie, które elementy będą edytowalne.
To istotne szczególnie wtedy, gdy projekt jest niestandardowy.
Czy wykonawca testuje wyłącznie desktop i mobile, czy również zachowanie pomiędzy nimi?
Powinien istnieć etap QA wizualnego.
Dobry wykonawca powinien o nie zapytać przed rozpoczęciem programowania.
Warto wiedzieć, czy po publikacji będzie możliwe:
To szczególnie ważne w przypadku stron mających rozwijać się przez kolejne lata.
Jeżeli projekt jest kompletny, projektant i wykonawca mogą być dwiema całkowicie niezależnymi firmami.
To normalny model współpracy.
Korzyścią zespołu posiadającego jednocześnie kompetencje UX/UI i WordPress jest natomiast możliwość szybkiego rozwiązania problemów pojawiających się podczas handoffu:
Nie trzeba wtedy za każdym razem ponownie otwierać osobnego procesu z wcześniejszym projektantem. Nie oznacza to jednak, że design i development zawsze muszą być wykonane przez tę samą firmę. Najważniejsze jest jasne przekazanie projektu i odpowiedzialności.
Projekt w Figmie jest bardzo dobrym punktem startowym do wdrożenia WordPress, ale nie jest jeszcze gotową stroną internetową.
Profesjonalny proces wymaga przełożenia: projektu wizualnego → komponentów → RWD → architektury CMS → funkcjonalności → kodu → testów → działającej strony.
Im lepiej przygotowany projekt, tym mniej niejasności pojawia się podczas programowania.
Najważniejsze elementy to:
Nie oznacza to jednak, że przed pierwszą rozmową z wykonawcą Figma musi być idealna. Warto najpierw sprawdzić jej gotowość. Może się okazać, że brakuje jedynie kilku widoków. Innym razem lepszym rozwiązaniem będzie dopracowanie systemu projektowego lub nawet przebudowanie części UX przed rozpoczęciem programowania.
Najważniejsze, aby problemy projektowe rozwiązać świadomie przed ich przeniesieniem do kodu.
Podeślij nam projekt. Sprawdzimy jego kompletność, widoki, responsywność, funkcjonalności i elementy wymagające doprecyzowania przed rozpoczęciem wdrożenia. Jeżeli projekt wymaga uzupełnienia, możemy przejąć również brakujący zakres UX/UI.
Tak. Projekt przygotowany w Figmie może zostać odwzorowany jako responsywna strona WordPress. Wymaga to zaprogramowania interfejsu, przygotowania struktury CMS oraz wdrożenia funkcji niewidocznych bezpośrednio na projekcie.
Istnieją narzędzia generujące kod lub struktury na podstawie Figmy, ale nie zastępują one automatycznie kompletnego wdrożenia WordPress. Nadal trzeba zaplanować CMS, dane, funkcjonalności, integracje, responsywność i testy.
Najlepiej, jeśli kluczowe ekrany posiadają wersję mobilną. Nie trzeba projektować każdej możliwej szerokości, ale powinny być jasno określone zasady responsywnego zachowania interfejsu.
Tak. Na podstawie projektu można przygotować dedykowany motyw WordPress zamiast dopasowywać projekt do istniejącego motywu.
Figma zawiera informacje pomocne podczas developmentu, takie jak kolory, fonty, wymiary czy spacing, ale projekt nie jest kompletną produkcyjną stroną WordPress.
Przy prostej stronie często tak. Przy rozbudowanych funkcjach potrzebne są również informacje dotyczące formularzy, CMS, integracji, logiki biznesowej i migracji.
Można uzupełnić brakujące widoki przed programowaniem. Jeżeli podstrony wykorzystują istniejący już szablon, nie zawsze trzeba projektować każdą z nich osobno.
Najbezpieczniej zaprojektować sposób działania kluczowych widoków na telefonach przed wdrożeniem. Pozostawienie wszystkich decyzji programiście może prowadzić do rozbieżności względem intencji projektu.
Powinno oznaczać precyzyjne zachowanie typografii, proporcji, kolorów, komponentów i układu projektu. Nie należy rozumieć go jako sztywnego zakodowania każdej wartości dla jednej konkretnej szerokości ekranu.
Tak. Można ujednolicić typografię, odstępy, kontenery, komponenty, RWD i inne elementy systemu projektowego przed rozpoczęciem developmentu.
Tak. Jeśli projekt wymaga większych zmian, może zostać wykorzystany jako materiał wejściowy do przygotowania nowego UX/UI.
Tak. W takim przypadku oprócz standardowych widoków strony należy przygotować m.in. listing produktów, kartę produktu, koszyk, checkout, konto klienta oraz stany poszczególnych procesów zakupowych.
Czas zależy od liczby unikalnych widoków, stopnia skomplikowania komponentów, zakresu CMS, funkcjonalności, integracji oraz kompletności projektu. Sama liczba podstron nie pozwala wiarygodnie określić czasu realizacji.
Najczęściej problemy powodują niekompletne widoki, brak wersji mobilnych, niespójne komponenty, nieopisane funkcje oraz zmiany projektu wprowadzane już podczas programowania.
Nie musi stale uczestniczyć w developmentcie, ale możliwość wyjaśnienia niejednoznacznych elementów projektu bardzo ułatwia handoff i ogranicza ryzyko błędnych interpretacji.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Poznaj proces tworzenia dedykowanych stron internetowych, przygotuj się do stworzenia wysokiej jakości serwisu!
Dowiedz się, jak zaplanować stronę internetową od pomysłu do wdrożenia. Praktyczny przewodnik: UX, UI, development, SEO, testy i publikacja.
Czym są wymagania funkcjonalne strony internetowej i jak je opisać? Zobacz przykłady, checklistę, kryteria akceptacji i wpływ wymagań na wycenę.
Sprawdź, ile kosztuje usunięcie wirusa z WordPress, od czego zależy cena, co obejmuje czyszczenie malware i kiedy naprawa jest droższa niż przebudowa strony.
Share:
