Od czego naprawdę zaczyna się dobry projekt?
W poprzednich częściach doszliśmy do ważnego wniosku - nie projektujemy strony tylko dlatego, że firma potrzebuje „nowej strony”.
Projektujemy narzędzie, które ma rozwiązać konkretny problem.
Czasami problemem jest słaba sprzedaż. Czasami zbyt mała liczba zapytań. Czasami klienci nie potrafią znaleźć informacji. Innym razem handlowcy codziennie odpowiadają na te same pytania, bo strona nie przekazuje podstawowych informacji. Bywa też tak, że firma po prostu urosła i dotychczasowy serwis przestał odpowiadać jej rzeczywistej skali.
Dlatego pierwszym etapem nie powinien być Photoshop, Figma ani wybór frameworka.
Pierwszym etapem powinna być rozmowa.
Najpierw poznajemy biznes
Dobry projektant UX nie musi zostać ekspertem w każdej branży, dla której projektuje. Musi natomiast wystarczająco dobrze zrozumieć biznes klienta, żeby wiedzieć, jakie problemy próbuje rozwiązać.
Dlatego pytamy o rzeczy, które na początku mogą wydawać się niezwiązane z projektowaniem;
- Skąd przychodzą klienci?
- Dlaczego wybierają właśnie tę firmę?
- Dlaczego odchodzą?
- Co najczęściej pytają przed zakupem?
- Jak wygląda proces sprzedaży?
- Kto odpowiada za obsługę zapytań?
- Co dzieje się z leadem po wysłaniu formularza?
- Które produkty są najważniejsze?
- Które usługi mają największy potencjał?
- Czy firma chce zwiększyć liczbę zapytań, wartość zamówień, liczbę klientów czy może przede wszystkim poprawić swój wizerunek?
Dopiero odpowiedzi na takie pytania pozwalają ustalić, co właściwie powinniśmy projektować.
Discovery - zanim powstanie pierwsza makieta
W projektach cyfrowych często używa się określenia Discovery.
To etap poznawania problemu, użytkowników, celów biznesowych, ograniczeń i możliwości technologicznych przed rozpoczęciem właściwego projektowania i developmentu.
Nie jest to „strata czasu przed rozpoczęciem pracy”. W dobrze prowadzonym projekcie Discovery ma ograniczyć ryzyko zbudowania czegoś, co będzie wyglądało dobrze, ale nie rozwiąże rzeczywistego problemu.
Możemy odkryć na przykład, że klient nie potrzebuje wcale nowej strony.
Może potrzebować lepszej architektury informacji.
Albo uproszczenia procesu zakupowego.
Albo integracji strony z CRM-em.
Albo automatyzacji obsługi zapytań.
Albo zupełnie innego sposobu prezentowania oferty.
I właśnie dlatego warto czasami zatrzymać się przed rozpoczęciem produkcji.
UX nie zaczyna się od wyglądu
UX, czyli User Experience, oznacza doświadczenie użytkownika podczas korzystania z produktu lub usługi.
W przypadku strony internetowej obejmuje znacznie więcej niż wygląd interfejsu.
To rówież:
- sposób poruszania się po stronie,
- łatwość znalezienia informacji,
- zrozumiałość komunikatów,
- proces zakupowy,
- formularze,
- hierarchia treści,
- szybkość wykonywania zadań,
- reakcja systemu na działania użytkownika,
- dostępność,
- poczucie bezpieczeństwa i zaufania.
Dlatego UX zaczyna się jeszcze zanim ktoś narysuje pierwszy ekran.
Najpierw trzeba zrozumieć, co użytkownik próbuje osiągnąć.
User Flow - czyli którędy użytkownik ma dojść do celu?
Jednym z podstawowych narzędzi projektowania UX jest User Flow. To opis ścieżki, którą użytkownik przechodzi, aby wykonać określone zadanie.
Przykładowo w sklepie może wyglądać to tak: reklama → strona produktu → wybór wariantu → koszyk → dostawa → płatność → potwierdzenie zamówienia.
W firmie usługowej: Google → strona usługi → realizacje → referencje → formularz → kontakt z handlowcem.
W przypadku producenta: wyszukiwarka → produkt → parametry techniczne → dokumentacja → zapytanie ofertowe.
Każda z tych ścieżek wymaga innych decyzji projektowych.
Jeżeli najważniejszym celem użytkownika jest zakup, nie możemy zmuszać go do czytania kilkunastu ekranów tekstu. Jeżeli natomiast produkt jest drogi, skomplikowany i wymaga konsultacji, zbyt szybkie kierowanie do formularza może być równie złym rozwiązaniem.
UX polega między innymi na znalezieniu właściwego poziomu prowadzenia użytkownika.
Wireframe - zanim zaczniemy „upiększać”
Kolejnym etapem może być wireframe, czyli uproszczony schemat ekranu pokazujący układ treści i funkcji.
Wireframe nie musi być piękny. I bardzo dobrze. Na tym etapie nie chodzi o to, czy kolor przycisku będzie odpowiednio dobrany.
Chodzi o odpowiedź na pytania:
- Co użytkownik zobaczy jako pierwsze?
- Co będzie najważniejsze?
- Co powinno znaleźć się wyżej?
- Gdzie umieścimy informacje dodatkowe?
- Jak użytkownik przejdzie do kolejnego kroku?
- Co stanie się po kliknięciu?
To trochę jak projektowanie mieszkania.
Najpierw ustalamy, gdzie będą ściany, drzwi i pomieszczenia. Dopiero później zastanawiamy się nad kolorem ścian.
Design system - żeby projekt nie był zlepkiem przypadkowych elementów
W większych projektach pojawia się kolejny ważny element - Design System.
To uporządkowany zestaw zasad, komponentów i wzorców, które definiują sposób budowania interfejsu.
Może obejmować między innymi:
- kolory,
- typografię,
- przyciski,
- formularze,
- karty,
- tabele,
- komunikaty,
- ikony,
- odstępy,
- zasady responsywności,
- zachowania komponentów.
Po co? - żeby interfejs był spójny.
Jeśli na jednej podstronie przycisk zachowuje się w jeden sposób, a na innej zupełnie inaczej, użytkownik musi za każdym razem uczyć się interfejsu od nowa.
Design System pomaga również zespołowi developerskiemu. Zamiast za każdym razem budować komponent od zera, może korzystać z wcześniej ustalonych elementów.
To przekłada się na większą spójność, łatwiejszy rozwój i często również niższy koszt utrzymania projektu.
A gdzie w tym wszystkim technologia?
Technologia powinna pojawić się odpowiednio wcześnie, ale nie powinna dyktować całego projektu. To ważne rozróżnienie.
Projektant może wymyślić świetną funkcję, która z biznesowego punktu widzenia ma sens. Developer może jednak zauważyć, że jej implementacja będzie bardzo kosztowna albo stworzy problemy z wydajnością.
Z drugiej strony developer może zaproponować rozwiązanie technologiczne, które jest bardzo wygodne do wdrożenia, ale z punktu widzenia użytkownika nie rozwiązuje problemu wystarczająco dobrze.
Dlatego najlepsze projekty powstają tam, gdzie UX, design, development i biznes rozmawiają ze sobą od początku.
Nie na zasadzie: „Najpierw projektanci, potem programiści”.
Tylko: „Wspólnie zastanawiamy się, jak najlepiej rozwiązać problem”.
Technologia nie powinna być wybierana dlatego, że jest modna
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, aplikacja natywna, PWA... Można długo wymieniać technologie.
Tylko że klient nie kupuje technologii. Kupuje rozwiązanie.
Dlatego pytanie: „Jakiego frameworka użyjemy?”
często jest znacznie mniej istotne niż: „Jakie problemy ma rozwiązać system?” Dopiero później można dobrać odpowiednią architekturę.
Innej technologii potrzebuje prosta strona firmowa, innej sklep obsługujący tysiące zamówień, a jeszcze innej platforma B2B z rozbudowanymi integracjami i indywidualnymi uprawnieniami użytkowników.
Technologia powinna wynikać z wymagań, a nie wymagania z technologii.
Backend, frontend i miejsce, którego użytkownik nie widzi
Warto też pamiętać, że strona internetowa to nie tylko to, co widzimy w przeglądarce.
Frontend odpowiada za część aplikacji, z którą użytkownik bezpośrednio wchodzi w interakcję.
Backend odpowiada za logikę działającą po stronie serwera - przetwarzanie danych, komunikację z bazą, obsługę procesów czy integracje.
A pomiędzy nimi często znajduje się całkiem sporo dodatkowych elementów;
- CRM.
- ERP.
- System płatności.
- Platforma mailingowa.
- System magazynowy.
- API.
- Analityka.
- Automatyzacje.
- System obsługi klienta.
Jeżeli projektujemy nową stronę bez uwzględnienia tego ekosystemu, możemy stworzyć piękny frontend, który będzie funkcjonował jako samotna wyspa.
A przecież celem powinno być coś zupełnie innego.
Dobra strona może robić znacznie więcej niż „zbierać formularze”
Nowoczesna strona internetowa może być elementem większego procesu biznesowego;
- Użytkownik wysyła zapytanie.
- System rozpoznaje jego temat.
- Lead trafia do CRM.
- Handlowiec dostaje powiadomienie.
- Klient otrzymuje automatyczne potwierdzenie.
- Dane są przypisywane do odpowiedniej kategorii.
- System może sprawdzić dostępność produktu.
- Może przygotować informacje dla handlowca.
- Może rozpocząć określony workflow.
W przypadku sklepu zamówienie może automatycznie przejść przez kolejne etapy realizacji. W przypadku B2B klient może mieć dostęp do indywidualnych cen, dokumentów i historii zamówień.
Wtedy strona przestaje być tylko „wizytówką”. Staje się częścią infrastruktury biznesowej.
Co z AI?
AI również może być elementem takiego systemu. Ale ponownie - nie powinna być dodawana tylko dlatego, że „wszyscy teraz mają AI”.
Jeżeli chatbot nie rozwiązuje żadnego realnego problemu, będzie tylko kolejnym okienkiem na stronie.
Jeżeli natomiast użytkownik może dzięki AI szybciej znaleźć właściwy produkt, skonfigurować usługę, otrzymać odpowiedź na pytanie albo przejść przez proces wyboru, wtedy technologia zaczyna mieć uzasadnienie.
To samo dotyczy personalizacji.
Możemy pokazywać użytkownikowi inne treści w zależności od jego zachowania, źródła wejścia czy etapu procesu zakupowego. Możemy analizować dane i lepiej przewidywać potrzeby klientów.
Ale zawsze powinniśmy zaczynać od pytania: „Jaki problem rozwiązujemy?”
Dopiero później: „Czy AI jest najlepszym sposobem, żeby go rozwiązać?”
Testujemy nie tylko to, czy działa
Jednym z najczęstszych błędów jest testowanie strony dopiero na końcu. Wtedy odkrywamy, że formularz jest za długi, proces zakupowy nieintuicyjny, a użytkownik nie znajduje najważniejszej informacji.
Im później odkryjemy taki problem, tym droższa będzie jego naprawa.
Dlatego warto testować projekt etapami. Możemy sprawdzać prototyp. Możemy obserwować zachowanie użytkowników. Możemy przeprowadzać testy użyteczności. Możemy analizować dane z Google Analytics lub innych narzędzi analitycznych. Możemy korzystać z nagrań sesji czy map cieplnych, o ile są wdrożone zgodnie z wymaganiami dotyczącymi prywatności. Możemy również po prostu porozmawiać z handlowcami.
To ostatnie jest często niedoceniane.
Handlowiec codziennie słyszy pytania klientów; Wie, czego nie rozumieją. Wie, czego się obawiają. Wie, jakie informacje muszą zostać przekazane przed zakupem.
To ogromna wiedza projektowa.
MVP nie oznacza byle czego
W projektach cyfrowych często pojawia się pojęcie MVP - Minimum Viable Product.
Chodzi o pierwszą wersję produktu zawierającą minimalny zestaw funkcji potrzebnych do zweryfikowania założeń i dostarczenia wartości użytkownikom.
MVP nie powinno oznaczać: „Zróbmy byle co i później się zobaczy”.
Dobre MVP powinno odpowiadać na pytanie: „Jaka jest najmniejsza wersja rozwiązania, która pozwoli nam sprawdzić, czy obraliśmy właściwy kierunek?”
To bardzo ważne również przy stronach internetowych i aplikacjach.
Zamiast budować od razu trzydzieści funkcji, czasami lepiej uruchomić pięć najważniejszych i sprawdzić, jak użytkownicy z nich korzystają. Później rozwijamy system na podstawie rzeczywistych danych, a nie wyłącznie założeń z pierwszego spotkania.
Strona nie kończy się w dniu publikacji
To kolejna rzecz, o której często zapominamy.
Moment publikacji strony jest właściwie początkiem jej prawdziwego życia. Dopiero wtedy pojawiają się realni użytkownicy. Dopiero wtedy widzimy, które treści działają. Dopiero wtedy wiemy, które elementy są ignorowane. Dopiero wtedy możemy sprawdzić, czy wzrosła liczba zapytań, sprzedaż, czas spędzony na stronie albo inne wskaźniki, które wcześniej ustaliliśmy.
Dlatego projekt powinien być rozwijany;
- Analiza.
- Wnioski.
- Zmiana.
- Test.
- Ponowna analiza.
To bardziej przypomina cykl niż jednorazowe wydarzenie.
Co właściwie powinno być mierzone?
To zależy od celu projektu.
Dla sklepu internetowego mogą to być:
- współczynnik konwersji,
- średnia wartość zamówienia,
- porzucenia koszyka,
- przychód,
- wartość klienta w czasie.
Dla firmy usługowej:
- liczba wartościowych leadów,
- współczynnik konwersji formularza,
- liczba umówionych konsultacji,
- koszt pozyskania leada,
- jakość zapytań.
Dla serwisu informacyjnego:
- znalezienie określonych informacji,
- zaangażowanie użytkowników,
- liczba powrotów,
- pobrania materiałów.
Nie wszystko trzeba mierzyć. Trzeba natomiast wiedzieć, co jest ważne.
Bo jeśli firma chce zwiększyć liczbę wartościowych zapytań, samo zwiększenie ruchu na stronie niekoniecznie oznacza sukces. Możemy mieć dziesięć razy więcej odwiedzin i ani jednego dodatkowego klienta.
Największy błąd? Projektowanie bez odpowiedzi na pytanie „po co?”
Można stworzyć świetny wizualnie serwis.
Można zastosować nowoczesny stack technologiczny.
Można przygotować perfekcyjne animacje.
Można zadbać o każdy piksel.
A mimo to projekt może nie przynieść biznesowi oczekiwanych rezultatów. - Dlaczego?
Bo zabrakło odpowiedzi na najważniejsze pytanie: Po co to wszystko robimy?
Jeżeli odpowiedź brzmi: „Bo stara strona jest brzydka”,
to jest to trochę za mało.
Jeżeli natomiast brzmi: „Chcemy zwiększyć liczbę zapytań od klientów B2B, skrócić proces dotarcia do właściwej usługi i odciążyć dział sprzedaży z odpowiadania na powtarzalne pytania”,
nagle mamy konkretny problem do rozwiązania.
I możemy zaprojektować rozwiązanie.
W Web24 nie chcemy tylko oddawać stron
To różnica między wykonaniem zlecenia a współpracą technologiczną.
Jeżeli klient przychodzi z konkretnym pomysłem, nie oznacza to, że naszym zadaniem jest bezrefleksyjnie go zrealizować.
Naszym zadaniem jest również powiedzieć: „To ma sens”.
Albo: „Da się to zrobić lepiej”.
Albo: „Technicznie możemy to zbudować, ale nie widzimy biznesowego uzasadnienia”.
Albo: „Zanim to zrobimy, sprawdzimy, czy użytkownicy rzeczywiście tego potrzebują”.
Czasami najlepszą decyzją projektową jest dodanie funkcji. Czasami jej usunięcie. Czasami całkowita zmiana założeń.
I właśnie na tym polega doświadczenie zespołu - nie na tym, że potrafimy zbudować wszystko, ale na tym, że potrafimy rozpoznać, co naprawdę warto zbudować.
Nie ma dwóch takich samych projektów
To wracamy do punktu wyjścia.
Możemy mieć dwóch klientów z tej samej branży. Możemy mieć dwóch producentów. Dwa sklepy. Dwie kancelarie. Dwa software house'y.
Ich strony mogą wyglądać podobnie. Ale nie powinny być takie same tylko dlatego, że działają w tej samej kategorii.
Bo różni ich ludzie. Strategia. Proces sprzedaży. Oferta. Budżet. Technologia. Klienci. Cele.
I właśnie dlatego każdy projekt wymaga własnych decyzji.
Nie zawsze spektakularnych. Nie zawsze przełomowych. - Ale świadomych.
Strona internetowa jako narzędzie, a nie dekoracja
Dobrze zaprojektowana strona powinna być dla firmy czymś więcej niż cyfrową wizytówką.
Powinna pomagać użytkownikowi podjąć decyzję. Powinna ułatwiać sprzedaż. Powinna odpowiadać na pytania. Powinna budować zaufanie. Powinna wspierać pracowników. Powinna integrować się z pozostałymi systemami tam, gdzie ma to sens.
I przede wszystkim powinna realizować konkretny cel biznesowy.
Dlatego nie ma jednej odpowiedzi na pytanie: „Jak powinna wyglądać dobra strona internetowa?”
Lepsze pytanie brzmi: „Jak powinna działać strona tej konkretnej firmy, żeby pomagać jej osiągać cele?”
I właśnie od tego pytania powinien zaczynać się każdy dobry projekt.
Na koniec - najważniejsza zasada
Nie projektujemy strony po to, żeby klient mógł powiedzieć: „Ale ładna”.
Projektujemy ją po to, żeby po kilku miesiącach klient mógł powiedzieć: „To naprawdę pomaga nam prowadzić biznes”.
Bo różnica między ładną stroną a dobrym produktem cyfrowym często nie jest widoczna na pierwszym ekranie.
Widać ją dopiero w wynikach.
Podsumowanie całej serii
W tej serii przyglądaliśmy się temu, dlaczego nie projektujemy dwóch takich samych stron internetowych.
Zaczęliśmy od prostego założenia: ta sama branża nie oznacza tego samego biznesu.
Następnie pokazaliśmy, jak strategia firmy, sposób sprzedaży, grupa docelowa i potrzeby użytkowników wpływają na UX, architekturę informacji i funkcjonalności.
W ostatniej części przeszliśmy przez proces projektowy - od Discovery i poznania biznesu, przez User Flow, wireframe'y i Design System, aż po technologię, integracje, testowanie, analitykę i dalszy rozwój.
Bo indywidualny projekt nie oznacza po prostu „innego wyglądu”.
Oznacza inne decyzje wynikające z innego problemu.
I właśnie dlatego każda firma powinna dostać rozwiązanie zaprojektowane dla niej, a nie dla „średniej firmy z branży”.
