W każdym projekcie produktowym przychodzi moment, w którym pomysł musi stać się rzeczywistością. Do tej pory istnieje w dokumentach, rozmowach i nieco odmiennym obrazie mentalnym każdej osoby — obrazach, które, jak się okazuje, nigdy się nie pokrywają.
Design i prototyping to moment, w którym te obrazy zostają ze sobą uzgodnione. Nie poprzez precyzyjniejsze omawianie pomysłu, ale poprzez zbudowanie czegoś, na co ludzie mogą popatrzeć, przeklikać i czego nie potrafią użyć. Te porażki są tu istotą sprawy. Dużo taniej odkryć je w prototype niż w produkcji.
Czym jest UX/UI design i prototyping?
UX/UI design to praca polegająca na przekształceniu wymagań produktowych w interfejs, którego ludzie mogą użyć: struktura, user flow, ekrany, stany oraz system wizualny, który je spaja. Prototyping polega na uczynieniu tego designu na tyle interaktywnym, by można go było przetestować, zanim cokolwiek zostanie zbudowane.
Te dwa elementy są ze sobą nierozerwalnie związane, bo decyzje projektowe to hipotezy. Struktura nawigacji to zakład o to, jak myślą użytkownicy. Układ formularza to zakład o to, co ludzie są gotowi podać. Prototype to sposób na sprawdzenie tego zakładu, zanim się za niego zapłaci.
Rezultat jest dwojaki: zwalidowany interfejs oraz specyfikacja na tyle kompletna, że development nie musi zgadywać.
Fidelity: dopasowanie artefaktu do pytania
Najważniejszą decyzją w prototypingu jest to, jak bardzo dopracowany ma być artefakt — a najczęstszym błędem jest dopracowanie go zbyt wcześnie.
Low fidelity — szkice i szarowe wireframe'y. Struktura, hierarchia i flow, bez designu wizualnego. Szybkie do stworzenia i szybkie do odrzucenia, co jest dokładnie tym, czego potrzeba, gdy podstawowy kształt wciąż jest pod znakiem zapytania.
Mid fidelity — dopracowane wireframe'y z prawdziwą treścią, poprawnym odstępami i działającą interakcją. Wystarczająco szczegółowe, by testować wykonanie zadania, ale nie na tyle, by ludzie komentowali kolory.
High fidelity — pełny design wizualny, prawdziwa treść, kompletna interakcja. To, na podstawie czego buduje development, i to, czego używa się do realistycznego usability testing i zatwierdzenia przez stakeholderów.
Oto coś, czego większość zespołów uczy się na własnej, kosztownej skórze: dopracowany prototype daje feedback na temat dopracowania. Pokaż komuś ekran, który wygląda na gotowy, a skomentuje kolor przycisku. Pokaż mu szarowy wireframe, a powie Ci, że flow nie ma sensu.
Jeśli otwarte pytanie ma charakter strukturalny, low fidelity daje lepszą odpowiedź, szybciej i za ułamek kosztów. High fidelity jest dla momentu, gdy struktura jest ustalona, a pozostałe pytania dotyczą wykonania.
Przechodzenie przez poziomy fidelity po kolei chroni też budżet. Zmiana wireframe'u kosztuje godzinę. Zmiana komponentu design system w high fidelity kosztuje dzień. Zmiana po zbudowaniu kosztuje sprint.
Po co w ogóle prototypować
Bo czytanie specyfikacji i używanie produktu to dwie różne czynności. Stakeholderzy zatwierdzają dokumenty opisujące flow, które w praktyce uznaliby za mylące. Klikalny prototype czyni flow na tyle realnym, że to zamieszanie wychodzi na jaw, zanim stanie się kosztowne.
Bo sprawia, że niezgoda staje się produktywna. Dwie osoby mogą zgadzać się co do „usprawnionego onboardingu” przez miesiące, wyobrażając sobie zupełnie inne rzeczy. Prototype wymusza ujawnienie tej różnicy, dzięki czemu można ją rozwiązać w jedno popołudnie.
Bo to ostatni tani moment na zmianę zdania. Koszt zmiany decyzji rośnie gwałtownie od wireframe'u, przez design i kod, aż po produkcję. Prototyping koncentruje zmiany w najtańszej fazie.
Bo można go przetestować na prawdziwych użytkownikach. Pięciu do ośmiu uczestników klikających przez prototype ujawni większość poważnych problemów z usability. Zrobienie tego przed developmentem to godzina o najwyższej dźwigni w całym projekcie.
Proces
Wejścia
Praca projektowa zaczyna się od czegoś: wniosków z discovery, audytu, analityki, istniejącego user research lub przynajmniej jasnego określenia, kim jest użytkownik i co musi osiągnąć. Design bez wejść to dekoracja — będzie wyglądać przemyślanie, a będzie oparty na niczym.
Information architecture
Struktura przed powierzchnią. Jak zorganizowane są treść i funkcjonalność, co należy do siebie, jakie są etykiety, jak głęboka jest hierarchia. Błędy w information architecture są najkosztowniejsze, bo wszystko inne jest na nich budowane, a naprawienie ich później jest niemal niemożliwe bez przebudowy.
User flows
Ścieżki przez produkt, w tym te, których nikt nie lubi mapować — błędy, puste stany, przerwania, uprawnienia, wygasłe sesje. Produkty, które działają tylko na happy path, wydają się zepsute po kilku minutach realnego użycia, a happy path to łatwe 20% pracy.
Wireframe'y
Układ, hierarchia i priorytet treści, ustalone bez wpływu designu wizualnego. To tu dzieje się większość faktycznego myślenia.
Prototype interaktywny
Wireframe'y połączone w coś klikalnego. Wystarczająco dużo interakcji, by przeprowadzić prawdziwe zadanie od początku do końca — co jest minimum potrzebnym, by testowanie dało użyteczne wyniki.
Design wizualny
Typografia, kolor, odstępy, obrazy i design komponentów, zastosowane tak, by wspierały usability, a nie z nim konkurowały. Kolor, który konsekwentnie niesie znaczenie. Krój pisma, który ustala hierarchię. Elementy interaktywne, które wyglądają na interaktywne. Kontrast spełniający wymogi accessibility, a nie tylko wyglądający akceptowalnie na monitorze designera.
Specyfikacja i handoff
Każdy stan udokumentowany: domyślny, hover, focus, aktywny, wyłączony, ładowanie, błąd, pusty. Zachowanie przy każdym breakpoincie. Co się dzieje, gdy tekst jest dłuższy niż w makiecie, gdy obraz się nie wczyta, gdy lista jest pusta, gdy połączenie padnie. To część, którą najczęściej się skraca, i tam właśnie cichutko traci się jakość designu.
Co sprawia, że prototype jest naprawdę użyteczny
Obejmuje kompletne zadanie. Prototype pokazujący trzy niepowiązane ekrany niczego nie testuje. Użytkownicy muszą spróbować zrealizować prawdziwy cel od początku do końca.
Zawiera unhappy paths. Co się dzieje przy błędnym wpisie, nieudanej płatności, pustym wyniku. To tu produkty tracą ludzi, a są one rutynowo pomijane w prototypach, bo mniej satysfakcjonuje ich budowanie.
Używa prawdziwej treści. Lorem ipsum ukrywa problemy. Prawdziwe nazwy produktów, prawdziwe komunikaty błędów i rzeczywiste długości tekstu w najgorszym scenariuszu ujawniają błędy w layoucie, które tekst zastępczy całkowicie maskuje.
Dopasowuje fidelity do celu. Prototype do zatwierdzenia przez stakeholderów i prototype do testowania struktury to różne artefakty. Zbudowanie jednego i użycie go do obu celów marnuje wysiłek w jedną stronę i daje złe dane w drugą.
Design systems i komponenty
Przy czymkolwiek większym niż garstka ekranów, projektowanie w komponentach zamiast w stronach szybko się zwraca.
Podejście oparte na komponentach oznacza, że przyciski, pola formularzy, karty i nawigacja są definiowane raz, ze wszystkimi swoimi stanami, a potem wielokrotnie wykorzystywane. Korzyści się kumulują: spójność bez pilnowania, szybsze projektowanie nowych ekranów, szybszy development, bo inżynierowie budują komponent raz, i dramatycznie tańsze zmiany — aktualizacja komponentu aktualizuje każdą jego instancję.
Koszt to inwestycja z góry, i nie zawsze jest uzasadniona. Pięcioekranowy MVP nie potrzebuje design system. Wielorolowa platforma, która ma rosnąć przez lata, zdecydowanie tak, a zbudowanie go z opóźnieniem jest znacznie droższe niż rozpoczęcie od razu z nim.
Uczciwa wskazówka: dopasuj ambicję systemu do faktycznej trajektorii produktu, a nie do tego, jak dokładnie czuje się jego budowanie.
Handoff: gdzie ucieka jakość designu
Design, którego development nie potrafi dokładnie zaimplementować, nie jest dobrym designem. Handoff to deliverable, a nie coś do dodania na koniec.
Czego naprawdę potrzebuje development:
- Każdy stan sprecyzowany, nie tylko domyślny
- Zdefiniowane zachowanie responsywne przy prawdziwych breakpointach, a nie sugerowane makietą desktopową
- Odstępy i rozmiary jako wartości, żeby pomiary nie były szacowane ze screenshota
- Definicje komponentów z wariantami i zasadami użycia
- Udokumentowane zachowanie w przypadkach brzegowych, zamiast pozostawiania decyzji pod presją deadline'u
- Wymogi accessibility określone: kolejność focus, etykiety, kontrast, zachowanie klawiatury
- Ktoś dostępny do odpowiadania na pytania, bo niejednoznaczność zawsze wychodzi na jaw podczas implementacji
Ten ostatni punkt liczy się bardziej niż dokumentacja. Pytania dotyczące designu pojawiają się w każdym buildzie. Jeśli nikt nie jest dostępny, developerzy podejmują rozsądne domysły, a nagromadzone domysły to sposób, w jaki design ostatecznie wygląda subtelnie źle w sposób, którego nikt nie potrafi wskazać osobno.
Częste błędy
Projektowanie bez research. Każda decyzja projektowa to założenie o użytkownikach. Bez wejść wszystkie są nieprzetestowane, a interfejs jest spójnym wyrazem zgadywania.
Skok do high fidelity. Pomijanie struktury na rzecz warstwy wizualnej oznacza, że fundamentalne problemy zostaną odkryte, gdy ich naprawa stanie się już kosztowna.
Projektowanie tylko happy path. Rzeczywiste użycie obejmuje błędy, puste stany i wolne połączenia. Design, który je ignoruje, jest gotowy w około 20%.
Treść zastępcza. Lorem ipsum i idealnie dopasowany tekst przykładowy ukrywają błędy layoutu, które prawdziwa treść ujawnia natychmiast.
Estetyka ponad usability. Tekst o niskim kontraście, niejednoznaczne ikony bez etykiet i kontrolki, które nie wyglądają na interaktywne, to powtarzające się koszty decyzji projektowych podejmowanych na podstawie wyglądu.
Traktowanie accessibility jako późniejszego etapu. Wprowadzanie poprawek wstecznych jest kosztowne i daje gorsze rezultaty niż projektowanie z myślą o tym od początku. Kontrast, stany focus i struktura semantyczna to decyzje projektowe, nie zadania naprawcze.
Niekompletny handoff. Najczęstszy sposób, w jaki dobry design staje się przeciętnym produktem.
Jak podchodzimy do design i prototyping
Fidelity podąża za pytaniem. Nie tworzymy dopracowanych ekranów, gdy struktura wciąż budzi wątpliwości — marnuje to budżet i, co gorsze, daje niewłaściwy feedback. Struktura zostaje ustalona w szarościach, gdzie zmiany są tanie, a recenzenci komentują to, co naprawdę ważne.
Prototype'y są budowane, by je testować, nie podziwiać. Oznacza to kompletne zadania, prawdziwą treść i uwzględnione stany błędów. Prototype, który pokazuje tylko idealną ścieżkę, niczego nie przetestował, w co już wcześniej nie wierzyłeś.
Decyzje projektowe są wyjaśniane. Każdy istotny wybór ma powód — zasadę usability, wniosek z research, udokumentowany wzorzec. To oznacza, że propozycje można kwestionować merytorycznie, a nie na podstawie gustu, co jest znacznie lepszą podstawą do rozmowy o designie.
Handoff traktowany jest jako deliverable. Udokumentowane stany, breakpointy, przypadki brzegowe i wymogi accessibility, a także dostępność podczas budowy, by rozwiązywać to, czego dokumentacja nie przewidziała.
Podejście opiera się na certyfikacji Nielsen Norman Group — instytucji, która ukształtowała nowoczesną praktykę UX — w zakresie information architecture, journey mapping, usability testing, przywództwa UX i analityki, a także na trzynastu latach pracy w agencjach, startupach i zespołach korporacyjnych z branż insurtech, fintech, zdrowia, edukacji, enterprise i transportu.
Każde zlecenie prowadzone jest osobiście. Żadnej warstwy account między Tobą a osobą wykonującą pracę.
Najczęściej zadawane pytania
Jaka jest różnica między wireframe'em a prototype?
Wireframe to statyczny układ pokazujący strukturę i hierarchię. Prototype jest interaktywny — możesz go przeklikać i spróbować wykonać zadanie. Wireframe'y odpowiadają na pytanie „co gdzie jest”; prototype'y odpowiadają na pytanie „czy to działa, gdy ktoś faktycznie tego używa”.
Czy potrzebujemy prototype, skoro i tak budujemy?
Niemal zawsze tak. Prototyping zwykle dodaje kilka dni do harmonogramu, a usuwa tygodnie poprawek, bo ujawnia problemy, gdy są jeszcze tanie. Wyjątkiem są bardzo małe, dobrze zrozumiane zmiany w ustalonych wzorcach.
Ile trwa design i prototyping?
Dla produktu na skalę MVP, mniej więcej cztery do ośmiu tygodni od wejść do designu gotowego do developmentu, w zależności od liczby ekranów, liczby ról użytkowników i tego, jak szybko zapadają decyzje. Szybkość podejmowania decyzji częściej jest ograniczeniem niż złożoność.
Czy możecie pracować na naszym istniejącym design system?
Tak — i zwykle jest to preferowane. Praca w ramach ustalonego systemu daje szybsze, bardziej spójne rezultaty i pozwala uniknąć rozjazdu wynikającego z projektowania wokół niego.
Czy robicie usability testing na prototype?
Może to być wliczone i warto. Pięciu do ośmiu uczestników próbujących wykonać prawdziwe zadania wychwytuje większość poważnych problemów, a wychwycenie ich przed developmentem to miejsce, gdzie tkwi wartość. Jeśli wolisz przeprowadzić to wewnętrznie, zbudujemy prototype tak, by było to proste.
Co otrzymują developerzy?
Kompletną specyfikację: wszystkie stany, zachowanie responsywne przy zdefiniowanych breakpointach, wartości odstępów i rozmiarów, definicje komponentów z wariantami, zachowanie w przypadkach brzegowych oraz wymogi accessibility — a także dostępność, by odpowiadać na pytania, które zawsze pojawiają się w trakcie buildu.
Czy projektujecie z myślą o accessibility?
Jest to wbudowane w proces, a nie dodawane na końcu. Współczynniki kontrastu, stany focus, nawigacja klawiaturą i struktura semantyczna to decyzje projektowe. Wprowadzanie ich wstecznie kosztuje więcej i daje gorsze rezultaty niż projektowanie z nimi od początku.
Od czego zacząć
Jeśli Twój zespół dyskutuje o funkcji i podejrzewasz, że każdy wyobraża sobie coś nieco innego, to jest właśnie ten sygnał. Prototype rozwiązuje to w kilka dni i jest to najtańsza niezgoda, jaką kiedykolwiek będziesz mieć.