Najdroższy moment, żeby się przekonać, że klienci nie rozumieją procesu zamówienia, to tydzień po starcie sklepu. Najtańszy to dzień, w którym ktoś spoza firmy pierwszy raz przechodzi przez prototyp i zatrzymuje się na drugim ekranie.
Prototyp powstaje z makiet albo z gotowych ekranów, połączonych tak, żeby dało się po nich poruszać. Użytkownik naciska „Dodaj do koszyka” i trafia do koszyka. Wypełnia formularz i widzi potwierdzenie. Wszystko zachowuje się jak gotowy produkt, tylko nic się naprawdę nie zapisuje i nikt nie płaci.
Do czego się przydaje
- Testy z użytkownikami. Kilka osób z grupy docelowej dostaje zadania i przechodzi przez prototyp. Widać, gdzie się gubią, zanim ktokolwiek napisze linijkę kodu. Jak taki test poprowadzić, opisuje hasło testy użyteczności.
- Decyzje w firmie. Zarząd, sprzedaż i dział IT widzą to samo. Łatwiej rozmawiać o przycisku na drugim ekranie, gdy ten ekran istnieje.
- Instrukcja dla programistów. Prototyp pokazuje zachowanie: co się dzieje po zatwierdzeniu zamówienia, jak wygląda błąd, co widzi ktoś bez konta. Przy wdrożeniu jest mniej zgadywania.
Prototyp nie musi być ładny. Do sprawdzenia, czy ścieżka zakupu ma sens, wystarczy szary prototyp z makiet. Gdy test ma pokazać, czy klient rozumie ofertę i ufa marce, potrzebny jest prototyp z gotowym wyglądem. W branży mówi się na te dwie wersje lo-fi i hi-fi.
Prototyp a MVP
Prototyp udaje produkt. MVP jest produktem: najmniejszą wersją, która naprawdę działa i trafia do prawdziwych klientów. Prototyp sprawdza, czy ludzie zrozumieją, jak czegoś używać. MVP sprawdza, czy w ogóle będą tego używać i czy za to zapłacą. Dobrze, gdy do MVP trafia już ścieżka sprawdzona wcześniej na prototypie.