Wydajne tworzenie strony internetowej opartej o autorski projekt graficzny

W jaki sposób powinniśmy tworzyć projekt, aby zrobić to możliwie najsprawniej i najlepiej? 

Proces tworzenia strony internetowej wygląda zupełnie inaczej w przypadku freelancera, a inaczej w średniej i dużej firmie. Przeanalizujmy dwa najbardziej powszechne przypadki: 

• W przypadku współpracy z freelencerem, jedna osoba jest odpowiedzialna za realizację całego projektu - jest zarówno projektantem, jak i developerem. 

• W małych i średnich zespołach (do 10 osób), projekt opracowuje zwykle 1 projektant UI/UX oraz 1 developer, czasami wspierani dodatkowo project manager. 

• W większych firmach podział pracy wygląda nieco inaczej. Projekt realizuje cały 8-osobowy zespół pracujący w danej metodyce pracy (np. scrum). 

 

Korzyści poszczególnych rozwiązań

W sytuacji, w której w jednym momencie nad projektem pracuje 1-3 osób nie mamy problemów z komunikacją oraz nie musimy wprowadzać wysokiej standaryzacji oraz uprocesowienia. To z kolei pozwala nam na zastosowanie pewnych uproszczeń i usprawnień, które oszczędzają czas. 

 

Duży zespół projektowy może pracować wydajnie, gdy dla każdego zlecenia możliwe jest zastosowanie powtarzalnego procesu. Na każdym z etapów pracy za projekt odpowiada inna osoba, dlatego projekt powinien być przekazywany w kompletnej i przetestowanej formie pomiędzy poszczególnymi etapami. Dodatkowo, klient ma opiekuna, który przeprowadzi go przez cały proces. W tym przypadku kluczowa jest także standaryzacja, bowiem pozwala zapanować nad rozbudowanym projektem i nie dopuszcza do spadku jakości. Zachowana jest dzięki temu kontrola nad poszczególnymi etapami realizacji i znacznie ułatwione jest zarządzanie dużym zespołem. 

 

Struktura pracy, podział ról obowiązki w dużym zespole

Zacznijmy od przeanalizowania modelu pracy nad serwisem webowym. Co firma robi krok po kroku, aby stworzyć stronę? Poniżej przedstawiam listę dla przykładowego projektu strony internetowej marki odzieżowej prezentującej ofertę firmy. Strona jest dość rozbudowana, ma około 50 podstron. W nawiasach obok każdego z punktu przedstawione jest stanowisko osoby odpowiedzialnej za wdrożenie projektu w metodyce Scrum. Mamy oczywiście Scrum Mastera oraz Product Ownera, którzy biorą udział praktycznie w każdym z etapów projektu. 

 

Role w projekcie:

UX - Projektant doświadczeń użytkownika

UI - Projektant interfejsu

PO - Właściciel produktu

CW - Twórca treści witryny

DEV - Programista

TEST - Tester

PM - Menadżer projektu

 

Przykładowa struktura projektu:

1. [UX,PO] Warsztat z klientem w celu zdefiniowania wymagań projektowych, doprecyzowanie tego, co zostało zebrane na etapie briefu.

2. [CW,UX,PO,PM] Warsztat wewnętrzny, budowanie person i definiowanie założeń projektowych dla zespołu. 

3. [UX,CW,PO,PM] Budowa makiet do dostarczonego contentu lub budowa makiet oraz przygotowanie zawartości witryny (zależnie od sytuacji).

4. [UI,UX,PO,PM] Przygotowanie projektów graficznych strony głównej do zatwierdzonych makiet i treści (zwykle kilka wersji) i akceptacja UI witryny.

5. [UI,PO,PM] Przygotowanie projektów podstron na bazie zatwierdzonego UI.

6. [UI,DEV,PM] Odbiór projektów przez programistów, sprawdzenie, czy są możliwe do zaprogramowania.  

7. [UI,PM] Odbiór i zatwierdzenie projektów przez klienta (zwykle kilka iteracji poprawek oraz kolejny odbiór przez developerów).

8. [DEV,PO,PM] Development, kodowanie projektu na wybranej platformie CMS.

9. [CW,PO,PM] Implementacja wcześniej utworzonych treści.

10. [TEST,PO,PM] Testy przez zespół testerów. 

11. [PO,PM] Odbiór strony przez klienta.

12. [DEV,PO,PM] Ostateczne poprawki od klienta.

13. [DEV,PM] Uruchomienie strony online.

 

Jak widzimy, na każdym z etapów zaangażowana jest jakaś część zespołu, zwykle jest to kilka osób. W takiej sytuacji bardzo ważna jest standaryzacja oraz odpowiednia atomizacja czynności, która pozwala na rozdzielenie zadań w zespole. 
 

Struktura pracy, podział ról obowiązki w małym lub średnim zespole

Być może zadajesz sobie teraz pytanie, czy aby na pewno taki proces jest dla Ciebie odpowiedni? Dlatego zaprezentujemy dokładnie taką samą realizację, jednak w modelu, gdzie kilka czynności prowadzonych jest przez jedną osobę, a poszczególne etapy zostały scalone w celu eliminacji zbędnych elementów. W małym lub średnim zespole jeden projekt zwykle realizuje do 4 osób, a czasem wystarczą tylko 3.

 

Role w projekcie:

UI/UX - skrócone do UX - Projektowanie doświadczeń użytkownika i interfejsu

PO/PM/TESTER/CW - skrócone do PM - Właściciel projektu, menadżer projektu, twórca treści i tester

DEV - Programista

 

Taka sytuacja ma miejsce dlatego, że mniejsze zespoły zatrudniają zwykle osoby o szerszych kompetencjach. To z kolei pozwala lepiej zarządzać pracą zespołu, który nie zawsze ma tyle zleceń, aby utrzymać twórcę treści czy też testera na pełen etat. Oczywiście czasami role właściciela produktu czy zarządzającego projektem są oddzielone, ale generalizując projekt jest realizowany o przynajmniej połowę mniejszy zespół. 

 

Jak widać, ten sam proces może wyglądać znacznie prościej - i tutaj przechodzimy do sedna sprawy. Omówimy element, który skraca realizację procesu, a mianowicie  “Design System” oraz przekazanie części zadań związanych z budową witryny bezpośrednio do stanowiska oznaczonego jako PM z małym wsparciem UX. Dlaczego warto skorzystać z takiego rozwiązania, i czym jest Design System?

 

Design system i eliminacja makiet

Jeszcze kilka lat temu, gdy całe projekty graficzne realizowane były w Adobe Photoshop, czas jaki potrzebował grafik na zbudowanie projektu był kilkukrotnie dłuższy niż obecnie. Dzisiaj korzystając z narzędzi typu Figma czy Sketch projektant ma znacznie większe możliwości i jest w stanie prototypować zdecydowanie szybciej. Narzędzia te pozwalają na tworzenie inteligentnych obiektów, które raz zdefiniowane, mogą być wykorzystywane wielokrotnie. Zbiór takich obiektów oraz zasad ich wykorzystania to jest właśnie nasz design system. 

 

Za czasów Adobe Photoshop wydajniej było tworzyć najpierw proste makiety, potem nanosić na nich poprawki i dopiero na koniec kolorować całość - co eliminowało konieczność wykonywania pracochłonnych poprawek na gotowym projekcie. Obecnie sytuacja jest odmienna. Tworzenie makiet nie jest etapem koniecznym, można go pominąć i pracować od razu na gotowym UI, co pozwala szybciej zwizualizować finalną wersję projektu i lepiej zrozumieć układ elementów. 

 

Makietowanie ma uzasadnienie przede wszystkim w dużych zespołach, w których mamy wyraźny podział na role i nieco inny flow pracy, o czym napisałem powyżej. Na etapie projektowania brak makietowania pozwala zaoszczędzić znaczną część czasu potrzebnego na realizację projektu graficznego. 

 

Design system to kolejna znacząca oszczędność. Pozwala na znacznie szybsze nanoszenie poprawek na gotowym projekcie. Warunkiem jest jednak wykorzystanie narzędzia, które pozwoli na generowanie obiektów inteligentnych (które raz zmienione aktualizują się w całym projekcie automatycznie). Tak zbudowany projekt może zostać bardzo szybko zmieniony w zakresie UI oraz UX poszczególnych komponentów projektu.

 

Całość nie miałaby sensu bez odzwierciedlenia w kodzie - dlatego komponenty muszą istnieć również w naszym frameworku, w którym kodowana jest strona. Przykładowo, wykorzystując Wordpress możemy samodzielnie dopisać lub wykorzystać już istniejące rozwiązanie, które pozwoli na budowę aplikacji z modułów, które jednocześnie są wykorzystywane w projekcie. Tak samo jak w przypadku projektu graficznego, kod można szybko zmodyfikować. Co więcej, w przypadku zmian i poprawek graficznych już po zatwierdzeniu projektu możliwe jest szybkie wdrożenie zmian. 

 

Te czynniki jednoznacznie przemawiają za eliminacją makiet w przypadku mniejszych zespołów projektowych oraz rozważenie ich redukcji do koniecznego minimum w przypadku większych zespołów. Wielkość projektu nie ma tutaj znaczenia, wszystko rozbija się o podział ról w zespole i jego specjalizacje.