Projektowanie strony internetowej — co się tu rozstrzyga, zanim powstanie kod

Projektowanie strony bywa traktowane jak warstwa, która przychodzi na końcu i dotyczy wyglądu. To najdroższe nieporozumienie w całym procesie, bo na tym etapie zapadają decyzje, których w kodzie nie da się już tanio cofnąć — a wyglądają na decyzje o kolorach.

Ten dział nie jest przewodnikiem po estetyce. Jest rozdzielnią: dwa teksty, po jednym na pytanie, z którym firmy tu trafiają.

Co ten dział rozstrzyga

Trzy rzeczy, i żadna z nich nie jest kwestią gustu.

Co widać i w jakiej kolejności. Który element jest pierwszy, co da się pominąć, gdzie kończy się pierwszy ekran. To są decyzje biznesowe podjęte środkami graficznymi, a nie odwrotnie.

Czego nie będzie. Najbardziej niewygodna część projektowania i najrzadziej nazywana wprost: nie wszystko się mieści, więc ktoś musi wybrać. Jeśli nie wybierze projektant razem z Wami, wybierze przypadek.

Co będzie można zmienić samodzielnie. Blok zaprojektowany jako edytowalny i blok zaprojektowany „na sztywno" wyglądają identycznie na obrazku, a różnią się kosztem przez następne lata.

Najłatwiej zobaczyć to na przykładzie, który powtarza się u nas regularnie. Firma prosi o „przesunięcie formularza wyżej, bo klienci go nie widzą". Na szkicu jest to jedno przeciągnięcie prostokąta. Na działającej stronie ta sama prośba oznacza przebudowę komponentu, zmianę pól w systemie zarządzania treścią, poprawkę zapytań o dane, refaktoryzację stylów i testy sprawdzające, czy nie rozsypało się nic obok. Prośba brzmi identycznie w obu przypadkach — różni się tylko rachunek.

Warto od razu postawić granicę wobec sąsiednich działów, bo w ofertach te trzy rzeczy zwykle są zlepione. Kiedy poszczególne etapy następują i co kiedy trzeba dostarczyć — to dział procesowy. Na czym to wszystko stanie, czyli system i platforma — to dział technologiczny. Tutaj jest wyłącznie to, jak strona ma być zbudowana od strony układu i zachowania.

Dwa pytania, dwa teksty

Wystarczy rozpoznać własną sytuację.

Ktoś pokazał Wam projekt i nie wiecie, co na nim oceniać. Dostajecie plik, macie go zaakceptować, a jedyne narzędzie, jakie przychodzi do głowy, to „podoba mi się albo nie". Tekst daje coś lepszego: sześć zasad z normy międzynarodowej przełożonych na ryzyko i koszt, dziesięć heurystyk użyteczności zamienionych w listę kontrolną dla zamawiającego, oraz prześledzony do końca łańcuch cytowań krążącej liczby „9400% zwrotu z inwestycji w UX" — z odpowiedzią, skąd naprawdę pochodzi: UX i UI — czym to jest i jak to ocenić.

Strona źle wygląda albo źle działa na telefonie. Zanim zamówicie przebudowę, warto sprawdzić, ile naprawdę macie ruchu mobilnego — bo najczęściej powtarzana liczba w tej dziedzinie jest dla Polski odwrócona. Tekst podaje pomiar dla sześciu rynków, pokazuje, dlaczego „trzy punkty przełamania pokrywają 95% urządzeń" nie jest prawdą, i daje trzy testy do zrobienia samodzielnie: strona mobilna — ile naprawdę jest ruchu z telefonów.

A jeśli oba pytania są Wasze? Zacznijcie od drugiego. Powód jest praktyczny: testy z telefonem zajmują kwadrans i dają twarde wyniki, a ocena projektu wymaga spokojnej godziny i lepiej ją robić, wiedząc już, co na obecnej stronie nie działa. Dodatkowo dane o ruchu mobilnym potrafią zmienić priorytet całego projektu — jeśli okaże się, że większość Waszych odbiorców siedzi przy komputerze, a wykonawca proponuje projekt „mobile first", macie temat do rozmowy, zanim cokolwiek podpiszecie.

A jeśli nie macie jeszcze żadnej strony? Wtedy ten dział jest za wcześnie. Zacznijcie od briefu — bez odpowiedzi na pytania o cel i odbiorcę każdy projekt graficzny będzie zgadywaniem, choćby był ładny.

Trzy rzeczy, które rozstrzygają się wcześniej, niż się wydaje

To jedyny merytoryczny fragment, jaki ta strona zatrzymuje — bo dotyczy obu tekstów naraz i porządkuje rozmowę z wykonawcą.

Na szkicu zapada układ: kolejność sekcji, liczba kroków do działania, co jest najważniejsze. Poprawka kosztuje tu kwadrans. Ta sama poprawka w gotowym kodzie kosztuje u nas mniej więcej trzydziestokrotnie więcej i rachunek rozpisujemy przy wireframe'ach.

Na projekcie graficznym zapada warstwa wizualna i — co ważniejsze — system: czy powstaje spójny zestaw komponentów, czy pięć niezależnych obrazków. Pierwszy da się rozwijać bez projektanta, drugi wymaga go przy każdej nowej podstronie.

W kodzie zapada już tylko to, czego nie rozstrzygnięto wcześniej. I to jest najgorsze możliwe miejsce na taką decyzję, bo podejmuje ją wtedy programista, na podstawie tego, co wydaje mu się sensowne.

Praktyczny wniosek: im więcej pytań zadacie przy szarych prostokątach, tym mniej zapłacicie za odpowiedzi.

Czego w tym dziale nie ma

Cztery tematy brzmią projektowo, a rozstrzygają się gdzie indziej.

Kolejność prac i terminy. Co się dzieje po czym, ile trwa i co ten czas pożera — dział procesowy.

Konwersja. Ten temat stąd wyszedł, i warto powiedzieć dlaczego: design na konwersję wpływa, ale tak samo tekst, szybkość, oferta i jakość ruchu. Trzymanie go w dziale projektowym twierdziło, że należy do jednego składnika. Jest w dziale marketingowym, razem z naszym własnym lejkiem i z tym, dlaczego cudze studia przypadku się nie przenoszą.

Dostępność i WCAG. Osobna dziedzina z własnymi wymaganiami prawnymi i własnym tekstem, a nie podrozdział projektowania.

Ile to kosztuje. Za co się płaci w projekcie, opisujemy wewnątrz obu tekstów. Pełny rachunek wdrożenia jest w dziale kosztowym.

Zacznijcie od trzech testów, nie od czytania

Jeśli macie już stronę, kwadrans z telefonem w ręku powie Wam więcej niż oba teksty przeczytane po kolei. Wszystkie trzy testy są opisane w tekście o wersji mobilnej i wszystkie trzy sprawdziliśmy najpierw na sobie.

Strefa kciuka — czy najważniejszy przycisk da się nacisnąć jedną ręką, bez przekładania telefonu.

Tabele i szerokie treści — czy przewija się sama tabela, czy cała strona ucieka w bok.

Powiększanie — czy da się przybliżyć stronę dwoma palcami, czy ktoś to zablokował „żeby układ się nie rozjeżdżał".

Każdy wynik negatywny to konkret do rozmowy z wykonawcą zamiast wrażenia, że „coś jest nie tak".