Poprawka w makiecie kosztuje kilkanaście minut. Ta sama poprawka w gotowej aplikacji kosztuje dni. To cała argumentacja za prototypem.
Co pokazuje prototyp
Układ ekranów, kolejność kroków, nazwy pól i przycisków. Nie wygląd docelowy i nie działanie — tylko przepływ pracy.
Warto to powiedzieć wprost na początku spotkania. Makieta pokazana bez tego zastrzeżenia ściąga rozmowę na kolory i czcionki, czyli na jedyne rzeczy, które nie są w tym momencie ważne.
Sprawdzenie z użytkownikami
Zadanie do wykonania na makiecie, bez podpowiedzi. Miejsca zawahania wskazują, gdzie aplikacja będzie myląca, zanim powstanie.
Wystarczy kilka osób, które naprawdę wykonują daną pracę — nie kierownik opowiadający, jak wygląda proces. Prowadzący ma milczeć i notować. Każde pytanie „a gdzie mam teraz kliknąć" to miejsce do poprawienia, opisane szerzej w tekście o interfejsie dla osoby nietechnicznej.
Prawdziwe dane
Makieta z realnymi nazwami produktów i kwotami ujawnia problemy, których nie widać na treści zastępczej — zbyt długie nazwy, wartości ujemne, puste pola.
Dobrze jest wziąć kilkanaście rekordów wprost z systemu, łącznie z tymi najbrzydszymi. To one pokazują, ile miejsca naprawdę trzeba na ekranie i które kolumny nie zmieszczą się na telefonie.
Forma makiety
Wystarczy zestaw ekranów z klikalnymi przejściami. Rysunek na kartce też bywa dobrym początkiem, ale trudniej go rozesłać i trudniej sprawdzić na nim zadanie od początku do końca. Ważniejsze od narzędzia jest to, żeby poprawkę dało się wprowadzić w trakcie rozmowy — makieta, której zmiana zajmuje dzień, przestaje pełnić swoją funkcję.
Przypadki brzegowe
Brak wyników, długa lista, błąd zapisu, uprawnienie odmówione. Ekrany dla tych sytuacji projektuje się razem z resztą, a nie po zgłoszeniu przez użytkowników.
Do tej listy warto dopisać stany przejściowe: oczekiwanie na wynik, operację przerwaną w połowie, dane niepełne. Są częste w pracy i prawie zawsze pomijane w projekcie.
Prototyp jako umowa
Zatwierdzona makieta jest najbardziej jednoznacznym opisem zakresu. Opis słowny każda strona czyta inaczej.
Dlatego prototyp powinien powstać przed wyceną albo równolegle z nią. Wycena robiona na podstawie rozmowy opiera się na założeniach, których żadna strona nie zapisała, i rozjeżdża się przy pierwszym odbiorze. To jeden z powodów, dla których decyzja o budowie własnego narzędzia bywa podejmowana zbyt wcześnie — makieta często pokazuje, że potrzeba jest mniejsza, niż się wydawało.
Czym prototyp nie jest
Nie jest wersją zerową aplikacji. Makiety nie da się „dokończyć" w działające narzędzie — nie ma pod nią bazy, reguł ani kontroli poprawności. Próba rozwijania jej dalej kończy się narzędziem, które ładnie wygląda i nie zapisuje danych.
Czego nie robić
Nie rozwijać prototypu w nieskończoność. Ma odpowiedzieć na pytania o przepływ pracy i ustąpić miejsca budowie.
Sygnałem do zakończenia jest moment, w którym kolejne spotkanie nie przynosi już nowych uwag o kolejności kroków. Wtedy makieta trafia do zakresu, a projekt przechodzi do kolejnych etapów wdrożenia.
