Proces tworzenia strony WWW – struktura, makiety i wdrożenie
Dobry serwis WWW nie powstaje od projektu strony głównej. Najpierw trzeba ustalić, dla kogo tworzymy serwis, jakie zadania mają w nim wykonywać użytkownicy i jakie cele biznesowe ma realizować. Dopiero później można przejść do architektury informacji, makiet UX, projektu graficznego i wdrożenia.
W pierwszej części poradnika pokazaliśmy, jak określić odbiorców, cele, KPI, treści i funkcjonalności serwisu:
Teraz przechodzimy dalej – od uporządkowania informacji do działającego serwisu.
Krok 4. Zaprojektuj strukturę serwisu
Gdy wiemy już, jakie treści i funkcjonalności mają znaleźć się w serwisie, trzeba ułożyć je w logiczną całość. Powstaje architektura informacji, czyli sposób organizacji treści, funkcji, kategorii i zależności pomiędzy poszczególnymi częściami serwisu.
Dobra struktura powinna wynikać przede wszystkim z potrzeb użytkowników. Nie musi odzwierciedlać struktury organizacyjnej firmy. To, że wewnątrz organizacji funkcjonują określone działy, piony czy nazwy produktów, nie oznacza jeszcze, że w ten sam sposób myśli osoba odwiedzająca stronę.
Przykład struktury serwisu pokazującej hierarchię jego głównych sekcji i podstron.
Nie ma jednej prawidłowej liczby poziomów struktury ani zasady, że każda informacja musi znajdować się w określonej liczbie kliknięć od strony głównej. Ważniejsze jest to, czy użytkownik rozumie, gdzie się znajduje, potrafi przewidzieć, gdzie szukać potrzebnej treści i może sprawnie wykonać swoje zadanie.
W rozbudowanych serwisach sama struktura szybko robi się duża. Dlatego podczas projektowania warto grupować elementy według ich znaczenia dla użytkownika i celów biznesowych.
Przykład porządkowania dużej architektury informacji na różne grupy treści. Ostateczny sposób podziału nawigacji powinien wynikać z konkretnego serwisu i potrzeb jego użytkowników.
Nawigacja powinna wynikać ze struktury
Architektura informacji i menu to nie to samo. Struktura opisuje całą zawartość serwisu, natomiast nawigacja jest jednym ze sposobów poruszania się po niej.
W dużym serwisie część informacji może znaleźć się w głównym menu, część w menu pomocniczym lub stopce, a jeszcze inne mogą być dostępne z poziomu konkretnych sekcji, wyszukiwarki czy linków kontekstowych.
Najważniejsze elementy nawigacji powinny odpowiadać temu, czego użytkownicy najczęściej szukają i co z punktu widzenia firmy jest najważniejsze. Nie warto natomiast próbować umieszczać całej zawartości strony w jednym menu.
Na tym etapie dobrze jest również opisać ważniejsze funkcjonalności. Nie trzeba jeszcze projektować każdego szczegółu, ale agencja powinna wiedzieć, czego oczekujemy od wyszukiwarki, konfiguratora, formularza, strefy klienta czy procesu zakupowego.
Takie informacje mają znaczenie nie tylko projektowe. Pozwalają również znacznie dokładniej określić zakres prac i wycenić projekt.
Co w tym momencie powinno znaleźć się w briefie?
Po wykonaniu poprzednich kroków mamy już większość informacji potrzebnych agencji do rozpoczęcia pracy.
Brief powinien opisywać:
- najważniejsze grupy użytkowników;
- ich potrzeby i zadania;
- cele biznesowe serwisu;
- sposób mierzenia efektów;
- wymagane treści;
- najważniejsze funkcjonalności;
- wstępną strukturę informacji;
- wymagania techniczne i integracje;
- dostępne dane i materiały;
- wymagania związane z dostępnością, SEO i analityką;
- harmonogram i budżet projektu.
Nie oznacza to, że klient musi sam zaprojektować cały serwis. Brief powinien dobrze opisywać problem i wymagania, natomiast konkretny sposób ich rozwiązania jest już częścią pracy zespołu UX/UI i technologicznego.
Krok 5. Wybierz najważniejsze widoki i ścieżki użytkownika
Kiedyś projektowanie serwisu bardzo często rozpoczynało się od strony głównej. Dzisiaj lepiej zacząć od pytania: które ekrany i procesy mają największe znaczenie dla użytkownika i biznesu?
W sklepie internetowym jednym z kluczowych widoków będzie karta produktu i koszyk. W serwisie usługowym może to być oferta i formularz kontaktowy. W serwisie korporacyjnym ważne będą zupełnie inne ścieżki dla klienta, inwestora, kandydata do pracy czy dziennikarza.
Użytkownicy nie zawsze rozpoczynają wizytę od strony głównej. Mogą trafić bezpośrednio na produkt, artykuł, ofertę, wynik wyszukiwania czy konkretną podstronę z Google, social mediów albo kampanii reklamowej.
Dlatego projektować trzeba nie tylko poszczególne ekrany, ale również ścieżki pomiędzy nimi.
Przydatne pytania na tym etapie to:
- z jakiego miejsca użytkownik może wejść do serwisu;
- co chce zrobić;
- jakich informacji potrzebuje przed podjęciem decyzji;
- jakie kolejne kroki powinny być dla niego oczywiste;
- gdzie może pojawić się problem lub rezygnacja;
- jaki efekt biznesowy powinien kończyć daną ścieżkę.
Dopiero na tej podstawie warto ustalać, które widoki muszą zostać zaprojektowane w pierwszej kolejności.
Strona główna nadal jest ważna
To nie znaczy, że strona główna straciła znaczenie. Wciąż często pełni funkcję najważniejszego punktu orientacyjnego serwisu i pomaga użytkownikowi zrozumieć, gdzie trafił, co oferuje firma i dokąd może przejść dalej.
Nie powinna jednak być spisem wszystkiego, co firma chce powiedzieć o sobie. Jej zawartość powinna wynikać z priorytetów użytkownika i celów biznesowych, a nie z potrzeby zmieszczenia komunikatu każdego działu organizacji.
Ta sama zasada dotyczy najważniejszych podstron. Każda z nich powinna mieć jasno określoną funkcję i pomagać użytkownikowi zrobić kolejny krok.
Krok 6. Zbuduj makiety UX
Makieta, czyli wireframe, pokazuje strukturę konkretnego widoku: rozmieszczenie treści, funkcjonalności, elementów nawigacji i najważniejszych działań użytkownika.
Makieta nie jest jeszcze projektem graficznym. Na tym etapie nie rozstrzygamy ostatecznie kolorów, zdjęć, typografii czy szczegółowego wyglądu interfejsu. Chodzi przede wszystkim o sprawdzenie, czy serwis działa logicznie.
Dobrze wykonane makiety pozwalają stosunkowo szybko wychwycić problemy, które na późniejszym etapie byłyby znacznie droższe do poprawienia.
Nie zawsze trzeba od razu korzystać z zaawansowanych narzędzi. Szczególnie podczas warsztatów bardzo dobrze działają kartki, karteczki samoprzylepne i proste szkice.
Praca nad układem serwisu podczas warsztatów UX. Proste makiety pozwalają szybko sprawdzać różne warianty bez przywiązywania się do rozwiązania.
Dopiero później makiety trafiają do narzędzi projektowych, gdzie można dokładniej pokazać układ ekranów, zależności między nimi oraz działanie interakcji.
Projektuj od początku dla różnych ekranów
Podział na osobny „serwis desktopowy” i później dopasowaną do niego wersję mobilną nie powinien być punktem wyjścia procesu. Serwis musi od początku działać w różnych szerokościach ekranu i różnych sposobach korzystania z urządzenia.
To nie oznacza, że każdy ekran jest mechaniczną kopią desktopu w mniejszej skali. Priorytety treści, sposób nawigacji czy zachowanie określonych funkcji mogą zmieniać się wraz z dostępną przestrzenią.
Ważniejsze od projektowania zestawu sztywnych ekranów jest więc stworzenie spójnego systemu, który zachowuje użyteczność niezależnie od urządzenia.
Testuj zanim zaczniesz development
Jedną z największych zalet makiet i prototypów jest możliwość sprawdzenia rozwiązania, zanim powstanie gotowy serwis.
Nie trzeba czekać z badaniami do końca dużego projektu. Już prosty prototyp może pokazać, czy użytkownicy rozumieją strukturę, potrafią znaleźć potrzebną informację i przejść przez najważniejszy proces.
Testowania nie należy również traktować wyłącznie jako narzędzia dla największych projektów. Zakres badań można dostosować do skali serwisu i ryzyka biznesowego.
Najważniejsze jest wykrycie problemów zanim zostaną zakodowane.
Od UX do UI
Gdy struktura i główne ścieżki działania serwisu są już uporządkowane, można przejść do projektu UI.
To wtedy powstaje wizualny język produktu: typografia, kolorystyka, komponenty, przyciski, formularze, ikonografia, sposób prezentowania zdjęć oraz pozostałe elementy interfejsu.
W dużych projektach pojedyncze widoki coraz częściej są częścią szerszego design systemu. Dzięki temu kolejne części serwisu korzystają z tych samych zasad i komponentów, a rozwijanie produktu jest łatwiejsze zarówno dla projektantów, jak i developerów.
Makieta określa strukturę i funkcje strony. Projekt UI nadaje im finalną formę wizualną.
Dostępność nie jest etapem na końcu projektu
Projektując interfejs, trzeba od początku uwzględniać dostępność cyfrową. Dotyczy to między innymi kontrastu, typografii, nawigacji klawiaturą, struktury nagłówków, formularzy, komunikatów o błędach oraz sposobu prezentowania treści.
Próba „dodania dostępności” do gotowego projektu przed samym uruchomieniem serwisu zwykle oznacza więcej poprawek. Znacznie skuteczniej uwzględniać te wymagania już podczas projektowania UX/UI i tworzenia komponentów.
To samo dotyczy treści. Dostępność serwisu zależy nie tylko od kodu i projektu graficznego, ale również od sposobu przygotowania tekstów, linków, alternatywnych opisów grafik czy materiałów multimedialnych.
Więcej o WCAG i projektowaniu dostępnych produktów cyfrowych:
Development – projekt zaczyna działać
Po zaakceptowaniu projektu rozpoczyna się development. Zamiast dawnego „cięcia layoutu” powstaje działający interfejs oraz zaplecze technologiczne serwisu.
W zależności od projektu prace mogą obejmować między innymi:
- frontend;
- backend;
- CMS;
- integracje z systemami firmy;
- wyszukiwarkę;
- formularze;
- system logowania;
- e-commerce;
- mechanizmy personalizacji;
- analitykę;
- zarządzanie zgodami;
- rozwiązania związane z bezpieczeństwem.
Dlatego już na etapie briefu i projektowania warto wiedzieć, z jakimi innymi systemami nowy serwis musi współpracować.
Jeżeli serwis ma być zarządzany przez CMS, wybór konkretnego rozwiązania również powinien wynikać z potrzeb projektu, sposobu pracy redaktorów, integracji oraz planów rozwoju. Więcej o wyborze CMS:
Treści i SEO również są częścią projektu
Błędem jest projektowanie całego serwisu na tekstach zastępczych, a dopiero na końcu zastanawianie się, co właściwie znajdzie się na poszczególnych stronach.
Treści wpływają na strukturę strony, długość modułów, sposób prezentowania oferty i ścieżkę użytkownika. Powinny więc powstawać równolegle do projektu.
Podobnie jest z SEO. Architektura informacji, adresy URL, nagłówki, linkowanie wewnętrzne i organizacja treści są częścią konstrukcji serwisu. Im wcześniej zostaną uwzględnione, tym mniej rzeczy trzeba poprawiać po wdrożeniu.
Analitykę trzeba zaplanować przed publikacją
Jeżeli wcześniej określiliśmy cele i KPI, przed uruchomieniem strony trzeba upewnić się, że będziemy potrafili je zmierzyć.
Nie chodzi wyłącznie o instalację narzędzia analitycznego. Trzeba określić, jakie zdarzenia powinny być mierzone, które działania są konwersją oraz jakie informacje będą potrzebne później do oceny i optymalizacji serwisu.
Dzięki temu po wdrożeniu nie zostajemy z odpowiedzią „strona działa”, tylko możemy sprawdzić, jak działa i czy realizuje cele, dla których została zbudowana.
Testy przed uruchomieniem strony WWW
Gotowy serwis trzeba dokładnie sprawdzić. Testowanie obejmuje znacznie więcej niż sprawdzenie, czy wszystkie linki się otwierają.
W zależności od projektu testujemy między innymi:
- działanie kluczowych procesów;
- formularze;
- integracje;
- różne urządzenia i szerokości ekranu;
- najważniejsze przeglądarki;
- dostępność;
- wydajność;
- poprawność treści;
- analitykę;
- SEO techniczne;
- obsługę błędów.
Im bardziej rozbudowany serwis, tym ważniejsze jest również ustalenie, kto odpowiada za odbiór poszczególnych elementów i jakie kryteria muszą zostać spełnione przed publikacją.
Praktyczną checklistę dla marketera przed uruchomieniem strony znajdziesz tutaj:
Publikacja strony nie kończy projektu
Uruchomienie serwisu jest ważnym momentem, ale nie powinno być końcem pracy.
Dopiero kontakt z rzeczywistymi użytkownikami daje pełny obraz tego, jak działają zaprojektowane rozwiązania. Warto analizować zachowanie użytkowników, realizację celów, wyniki SEO, błędy i informacje od klientów.
Na tej podstawie można rozwijać serwis, poprawiać istniejące elementy oraz dodawać nowe funkcjonalności wtedy, gdy rzeczywiście są potrzebne.
Jak wygląda proces tworzenia strony WWW?
W uproszczeniu można go przedstawić w następującej kolejności:
- określenie odbiorców i ich potrzeb;
- określenie celów biznesowych i KPI;
- ustalenie treści i funkcjonalności;
- architektura informacji;
- zaprojektowanie najważniejszych ścieżek użytkownika;
- makiety i prototypy UX;
- testowanie rozwiązań;
- projekt UI i system komponentów;
- przygotowanie treści;
- development i integracje;
- wdrożenie analityki;
- testy jakościowe, techniczne i dostępności;
- uruchomienie;
- analiza i dalsza optymalizacja.
W praktyce część tych prac odbywa się równolegle. Projektowanie serwisu WWW nie jest liniowym procesem, w którym jeden dział kończy pracę i przekazuje ją kolejnemu. Najlepsze efekty daje współpraca strategii, UX/UI, contentu, technologii, SEO i analityki od początku projektu.
Więcej o projektowaniu serwisów WWW, UX/UI i produktów cyfrowych przez GoldenGrid:
