Wireframe — co rozstrzyga się na szkicu, a czego w kodzie już nie da się cofnąć

Wireframe jest najczęściej pomijanym etapem projektu strony i najtańszym momentem, w którym da się jeszcze coś zmienić. Pomija się go, bo nie widać na nim postępu — jest czarno-biały, brzydki i wygląda jak coś, co ktoś narysował w pięć minut.

To złudzenie kosztuje dokładnie tyle, ile kosztuje przeniesienie bloku na działającej stronie zamiast na szkicu. Różnica jest mniej więcej trzydziestokrotna i za chwilę pokażemy, skąd się bierze.

Wireframe, makieta, prototyp — trzy słowa, trzy różne rzeczy

Zamawiający używają ich wymiennie, a każde z nich rozstrzyga co innego, powstaje na innym etapie i kosztuje inaczej. Pomieszanie ich jest najczęstszym powodem, dla którego rozmowa o projekcie skręca w złą stronę.

Wireframe — szkielet. Niska rozdzielczość, czarno-biały układ bloków. Żadnych zdjęć, żadnych kolorów, żadnego kroju pisma poza domyślnym. Rozstrzyga co jest na stronie, w jakiej kolejności i co jest ważniejsze od czego. To jedyna rzecz, którą na tym etapie oceniacie — i celowo nie da się na nim ocenić niczego innego.

Makieta — warstwa wizualna. Wysoka rozdzielczość, pełny projekt graficzny: kolory marki, typografia, zdjęcia, ikony, stany przycisków. Rozstrzyga jak to wygląda. Powstaje na zaakceptowanym wireframie, nie zamiast niego.

Prototyp — działanie. Klikalny model, zwykle w narzędziu projektowym, w którym przyciski prowadzą do kolejnych ekranów. Rozstrzyga czy ścieżka ma sens, zanim ktokolwiek napisze linię kodu. Przy prostej stronie firmowej bywa zbędny; przy formularzu wielokrokowym, konfiguratorze albo panelu klienta oszczędza najwięcej.

Praktyczna konsekwencja tego podziału: jeśli dostajecie „wireframe" z kolorami i zdjęciami, dostajecie makietę — i rozmowa zejdzie na odcień przycisku, zanim ktokolwiek sprawdzi, czy formularz stoi we właściwym miejscu.

Co rozstrzyga się na szkicu, a czego potem już nie

Na wireframie zapadają cztery decyzje i wszystkie cztery są w kodzie kosztowne do cofnięcia.

Co widać bez przewijania. Ekran otwarcia mieści jedną rzecz najważniejszą, a nie cztery równorzędne. Wybór, która to rzecz, jest decyzją biznesową, nie graficzną — i na szkicu widać ją natychmiast, bo nie ma kolorów, które by ją zamaskowały.

Kolejność sekcji. Czy opinie klientów idą przed opisem oferty, czy po nim. Czy cennik jest nad formularzem. To są przesunięcia bloków, które na szkicu robi się w kilka minut.

Ścieżka do działania. Ile kroków dzieli wejście na stronę od wysłania zapytania i ile z nich jest naprawdę potrzebnych. Każdy zbędny krok jest łatwiejszy do usunięcia teraz niż wtedy, gdy ma już własny komponent, własny adres i własne testy.

Co się w ogóle nie zmieści. Najbardziej niewygodna i najbardziej wartościowa funkcja wireframe'u: pokazuje, że nie da się zmieścić wszystkiego, i zmusza do wyboru, zanim ten wybór zrobi za Was przypadek.

Czego na wireframie nie rozstrzygacie: kolorów, zdjęć, kroju pisma, dokładnych tekstów. Jeśli rozmowa na tym etapie schodzi na te tematy, etap jest marnowany.

Ile kosztuje ta sama zmiana na każdym etapie

Przesunięcie formularza wyżej to na wireframie kilkanaście minut pracy w narzędziu projektowym. Ta sama zmiana na działającej stronie to inna operacja i warto rozumieć, dlaczego — bo różnica nie bierze się z niczyjej złej woli ani z rozdmuchanej wyceny.

Zmiana układowa w kodzie pociąga za sobą łańcuch:

• przebudowę komponentu, który ten blok renderuje, razem z jego wariantami na telefon i na komputer,
• zmianę struktury treści w systemie zarządzania, jeśli blok ma własne pola, które trzeba dodać, przenieść albo usunąć,
• poprawienie zapytań pobierających dane, bo komponent prosi o co innego niż wcześniej,
• refaktoryzację stylów, żeby nowy układ nie rozsypał sąsiadujących sekcji,
• testy regresyjne, czyli sprawdzenie, że przy okazji nie zepsuło się coś, co działało.

Każdy z tych kroków z osobna jest drobny. Razem zamieniają kilkanaście minut w kilkanaście do trzydziestu godzin pracy wraz z testami.

Stosunek jest więc mniej więcej 1:30 i to jest cała ekonomia tego etapu. Wireframe nie jest wart tyle, ile kosztuje jego narysowanie — jest wart tyle, ile kosztowałoby odkrycie tego samego problemu trzy miesiące później.

Jak sprawdzić wireframe, zanim go zaakceptujecie

Najczęstszy sposób oceny szkicu polega na tym, że patrzy na niego osoba, która zamawia stronę, i mówi „wygląda dobrze". To jest najsłabszy możliwy test, bo ta osoba zna ofertę na pamięć i wie, gdzie czego szukać.

Istnieje tańsza i dużo skuteczniejsza metoda i ma udokumentowaną podstawę. Jakob Nielsen opublikował ją 18 marca 2000 roku i od tej pory jest jedną z najlepiej potwierdzonych reguł w tej dziedzinie: badanie z pięcioma użytkownikami wykrywa około 85% problemów z użytecznością.

Liczba nie jest wzięta z sufitu — wynika ze wzoru, w którym pojedynczy użytkownik znajduje średnio około 31% problemów, a kolejni w dużej mierze powtarzają te same odkrycia. Po piątej osobie krzywa się wypłaszcza: szósty do piętnastego użytkownika kosztują tyle samo co pierwszych pięciu, a dokładają kilkanaście punktów procentowych.

Jest w tej samej publikacji drugi wniosek, rzadziej cytowany i praktyczniejszy: ten sam budżet lepiej wydać na trzy badania po pięć osób niż na jedno z piętnastoma. Po pierwszym badaniu poprawiacie to, co wyszło, i drugie badanie testuje już poprawioną wersję, zamiast po raz kolejny potwierdzać znane problemy.

Jak to zrobić na wireframie, bez narzędzi i bez budżetu:

Napiszcie trzy zadania, nie pytania. Nie „co sądzisz o tym układzie", tylko „znajdź cennik i przejdź do wysłania zapytania". Pytanie o opinię daje opinię; zadanie daje zachowanie.

Posadźcie przy tym pięć osób spoza projektu. Nie muszą być klientami — na tym etapie wystarczą osoby, które nie znają tej strony. Ktoś z księgowości, ktoś z rodziny, sąsiad z biura obok.

Patrzcie, nie tłumaczcie. W momencie, w którym wyjaśniacie, gdzie kliknąć, test się kończy. Wahanie trwające dziesięć sekund jest wynikiem, nawet jeśli osoba w końcu trafi.

Zapiszcie miejsca, nie wrażenia. „Trzy z pięciu osób szukały cennika w menu, którego tam nie ma" to wynik, z którym projektant coś zrobi. „Podobało im się" — nie.

To jest linia obrony przed wydaniem pieniędzy na dewelopera: błąd znaleziony w tym miejscu kosztuje przesunięcie bloku, a nie przebudowę komponentu.

Jak czytać wireframe, którego nie narysowaliście

Dostajecie plik z szarymi prostokątami i macie go zaakceptować. Poniżej pięć pytań, które w tym momencie robią różnicę — wszystkie są do zadania bez żadnej wiedzy technicznej.

„Co ma zrobić ktoś, kto tu trafi?" Jeśli odpowiedź brzmi „zapoznać się z ofertą", wróćcie do briefu. Odpowiedź powinna być czynnością: wysłać formularz, zadzwonić, zarezerwować termin. Potem sprawdźcie, czy ta czynność jest na szkicu najbardziej widoczna.

„Dlaczego ten blok stoi właśnie tutaj?" Każda sekcja powinna mieć powód inny niż „bo tak się zwykle robi". Projektant, który potrafi uzasadnić kolejność, przemyślał ją; projektant, który odpowiada „to standardowy układ", odtworzył szablon.

„Czego tu nie ma, a było w briefie?" Wireframe zawsze coś gubi, bo nie wszystko się mieści — to jego funkcja. Ważne, żeby to była świadoma decyzja, a nie przeoczenie. Przejdźcie brief punkt po punkcie i odhaczcie.

„Co się stanie, gdy tekst będzie dwa razy dłuższy?" Na szkicu teksty są zastępcze i zwykle wygodnie krótkie. Wasze będą dłuższe. Blok zaprojektowany pod trzy słowa nagłówka rozsypie się przy ośmiu, a dowiecie się o tym po wdrożeniu.

„Które elementy będę mógł zmieniać sam?" To pytanie na szkicu wygląda na przedwczesne, a jest ostatnim momentem, w którym odpowiedź jest tania. Blok, który ma być edytowalny, musi być tak zaprojektowany — dorobienie tego później to ta sama przebudowa, o której mówi sekcja o koszcie.

Jedna rzecz, której nie warto robić na tym etapie: zbierać opinii od pięciu osób z zespołu naraz. Wireframe wywołuje komentarze o wyglądzie, bo wygląda surowo, a każda kolejna osoba dokłada swoje preferencje. Lepiej wyznaczyć jedną osobę decyzyjną i przeprowadzić test zadaniowy z sekcji wyżej — to daje zachowanie zamiast preferencji.

Telefon nie jest wersją mniejszą

Najczęstszy błąd w wireframach firmowych: układ rysuje się na szeroki ekran, a wersja na telefon powstaje z niego przez zwężenie. To nie działa, bo na wąskim ekranie bloki ustawiają się jeden pod drugim i kolejność staje się hierarchią — to, co na komputerze stało z boku, na telefonie trafia na koniec.

Konsekwencja jest konkretna. Jeśli na szerokim ekranie formularz kontaktowy stoi w kolumnie po prawej, a opis usługi po lewej, to na telefonie ktoś musi przewinąć cały opis, zanim zobaczy formularz. Na szkicu widać to w pięć sekund; w gotowym kodzie jest to przebudowa komponentu.

Trzy rzeczy, które warto rozstrzygnąć na wireframie osobno dla wąskiego ekranu:

Co zostaje na górze. Na komputerze mieści się nagłówek, zdjęcie i wezwanie do działania. Na telefonie mieści się jedno z nich. Wybierzcie które, zamiast pozwolić, żeby wybrała za Was kolejność w kodzie.

Co znika, a co się zwija. Menu, tabela porównawcza, długa lista referencji — każde z nich musi mieć zaprojektowane zachowanie na wąskim ekranie. „Zobaczymy, jak wyjdzie" znaczy, że wyjdzie przypadkiem.

Gdzie ląduje kontakt. W firmach usługowych numer telefonu jest najczęściej używanym elementem strony, a na telefonie musi być klikalny i widoczny bez przewijania. To jedna decyzja na szkicu i jedna z najdroższych do cofnięcia później, bo dotyka nagłówka obecnego na każdej podstronie.

Jak to wyszło u nas — i czego wireframe nie uratował

Mamy jedno wdrożenie, w którym sprawdzaliśmy to świadomie, i podajemy je z zastrzeżeniem, które jest częścią wyniku: to serwis demonstracyjny, nie realizacja kliencka, więc mówi o metodzie, a nie o sprzedaży.

Zaczęliśmy nie od szkicu, tylko od architektury informacji spisanej jako kontrakt: każdy węzeł serwisu dostał cel, odbiorcę, listę sekcji, pola w systemie zarządzania treścią i zasady odświeżania. Efekt był taki, na jaki liczyliśmy — wireframe'y narysowały się z tego dokumentu bez rundy przepisywania zakresu, czyli bez tej charakterystycznej pętli, w której szkic pokazuje, że zakres ustalono źle, i wraca się do rozmowy sprzed dwóch tygodni.

I teraz część, której nie pominiemy, bo jest ciekawsza: trzy decyzje projektowe nie przetrwały zderzenia z kodem. Rzeczy, które na szkicu wyglądały na rozstrzygnięte, okazały się w implementacji niewykonalne albo bezsensowne, i trzeba je było zmienić po drodze. Zapisaliśmy tę rozbieżność jako materiał, zamiast ją zamieść — bo to jest realna granica tej metody.

Wniosek z tego jest dwuczęściowy i oba człony są ważne. Wireframe skraca drogę do decyzji i zdejmuje najdroższe pomyłki układowe. Ale nie zastąpi kontaktu z implementacją: część rzeczy poznaje się dopiero wtedy, gdy powstaje kod, i budżet na projekt powinien to zakładać, zamiast udawać, że po akceptacji szkicu nic się już nie zmieni.

Sama teza metodyczna — że dobra architektura informacji zamienia się w szkice bez rundy poprawek — jest u nas tezą do potwierdzenia przy kolejnym wdrożeniu, nie regułą. Jedno wdrożenie to jedno wdrożenie. Cały opis tego projektu jest w portfolio, razem z listą rzeczy, które poszły inaczej, niż zakładaliśmy.

Low-fi czy hi-fi — i kiedy to nie ma znaczenia

Wireframe'y dzieli się na niskiej i wysokiej wierności, a wybór jest prostszy, niż sugerują poradniki.

Niska wierność to szare prostokąty i podpisy. Powstaje w godziny, nadaje się do rozmowy o układzie i do testu z pięcioma osobami. W większości projektów firmowych to wszystko, czego potrzeba.

Wysoka wierność to szkic z prawdziwymi proporcjami, wstawionymi tekstami i realnymi odstępami — nadal bez kolorów i bez zdjęć. Ma sens tam, gdzie rozstrzyga gęstość informacji: w tabelach porównawczych, w panelach z danymi, w konfiguratorach.

I najczęstszy błąd zamawiającego, przez który cały etap traci sens: rozmowa o kolorach i krojach pisma przy szkicu niskiej wierności. Dopóki układ i priorytety treści nie są zaakceptowane, nakładanie warstwy wizualnej jest pracą, którą trzeba będzie wykonać drugi raz. Szkic jest brzydki celowo — to jego funkcja, nie jego wada.

Praktyczna zasada: jeśli na spotkaniu o wireframie pada zdanie o odcieniu, wróćcie do pytania, czy ten blok w ogóle stoi we właściwym miejscu.

Kiedy wireframe jest zbędny

Warto to powiedzieć, bo cały ten tekst broni jednego etapu, a są sytuacje, w których ten etap niczego nie wnosi.

Gdy strona powstaje na gotowym szablonie i nie zamierzacie go przebudowywać. Szablon jest wireframem — układ został już rozstrzygnięty przez kogoś innego, a Wasza decyzja sprowadza się do wyboru szablonu i wypełnienia go treścią. Rysowanie szkicu, żeby potem szukać szablonu, który go przypomina, to praca odwrotna do zamierzonej.

Gdy podstron jest trzy i każda ma jeden ekran. Wizytówka z opisem, kontaktem i cennikiem nie ma architektury, którą trzeba by projektować. Rozmowa o tym, co stoi wyżej, mieści się w jednym akapicie maila.

Gdy przebudowujecie jedną sekcję istniejącej strony. Kontekst jest już ustalony, a szkic pojedynczego bloku bywa wolniejszy niż pokazanie go od razu w wyglądzie docelowym.

I sytuacja graniczna, w której odpowiedź brzmi „mimo wszystko tak": gdy ktoś w firmie ma silne zdanie o tym, jak strona ma wyglądać. Wtedy szkic jest tańszym miejscem na tę rozmowę niż gotowy projekt graficzny — i to jedyny znany nam sposób, żeby nie skończyła się na etapie, na którym każda zmiana kosztuje trzydzieści razy więcej.

Czego ten tekst nie rozstrzyga

Jak wygląda cały proces projektu. Wireframe jest jednym z sześciu etapów i pokazujemy je w kolejności, w jakiej następują.

Co ustalić przed szkicem. Cele, odbiorca i zakres zapadają w briefie, a wireframe tylko je rysuje — osobny tekst.

Jak zaprojektować stronę, żeby konwertowała. Układ to jedna warstwa; druga to treść i to, co w niej stoi. Dział projektowania schodzi tam głębiej.

Ile kosztuje projekt. Stawki, z których wynika rachunek 1:30, są nasze i dotyczą jednej pozycji. Pełna wycena projektu to dział kosztowy.

Skąd te liczby

• 85% problemów z użytecznością przy pięciu użytkownikach oraz zalecenie trzech badań po pięć osób — Jakob Nielsen, Why You Only Need to Test with 5 Users, Nielsen Norman Group, 18 marca 2000. Krzywa w figurze policzona ze wzoru podanego w tej publikacji, przy wartości 31% problemów wykrywanych przez pojedynczego użytkownika.
• Stosunek 1:30 między poprawką na szkicu a poprawką w kodzie — nasze własne stawki i nasz własny rachunek pracy, opisany krok po kroku w sekcji o koszcie. To nie jest benchmark rynkowy i nie podajemy go jako takiego.
• Wdrożenie, na którym sprawdzaliśmy metodę — serwis demonstracyjny opisany w naszym portfolio, nie realizacja kliencka, i tak jest w tekście opisany. Trzy rozbieżności między projektem a implementacją pochodzą z jego własnego raportu.
• Czego tu nie ma: poprzednia wersja tego tekstu podawała siedem studiów przypadku z wynikami procentowymi oraz zwrot z inwestycji rzędu 2100%. Żadne z nich nie miało nazwy klienta, danych przed i po ani zgody na publikację, więc zostały usunięte w całości zamiast być poprawione.