W ofercie projektowej najpierw czytajcie plan prototypu

Oferty projektowe dla produktów AI mają zwykle znajomy kształt: warsztaty discovery, persony, ścieżki użytkownika, dopracowane ekrany, system projektowy, test użyteczności. Każda z tych pozycji jest uprawniona, a oferta może zawierać je wszystkie i jednocześnie pomijać jedyny problem, który odróżnia produkt AI od innych.

Klasyczne oprogramowanie projektuje się przy założeniu, że system ma rację, a użytkownik może się mylić. Komponent AI jest szybki, zwykle trafny i czasem błędny, a interfejs musi uczynić sprawdzenie tanim, wątpliwość oczywistą, a pomyłkę bezpieczną. Oferta albo pokazuje, że autor to wie, albo nie — i zwykle widać to po kilku stronach.

Zacznijcie od planu prototypu

Najwięcej mówi sekcja o tym, jak prototyp zostanie zbudowany i przetestowany.

Czy prototyp zawiera błędne odpowiedzi? Prototyp pokazujący tylko dobre wyniki nie testuje niczego istotnego. Musicie się dowiedzieć, czy ludzie zauważają, kiedy system się myli, ile im to zajmuje i co robią dalej. To wymaga realistycznych błędów celowo umieszczonych w prototypie.

Z kim jest testowany? Z ludźmi, którzy wykonują tę pracę — nie z interesariuszami i nie z panelem, który nigdy tego zadania nie robił. Kierownicy oceniają, czy produkt robi wrażenie; ludzie przy pracy oceniają, czy jest szybszy.

Co jest mierzone? Czas sprawdzania, wyłapane błędy, przeoczone błędy i porównanie z obecnym sposobem pracy. Jeśli plan mierzy zadowolenie — czy się podobało — mierzy nie to, co trzeba, a pokazy AI ludziom niemal zawsze się podobają. Dobra oferta mówi też, co stanie się z wynikami: kto je przeczyta i jaka decyzja od nich zależy.

Potem kolejność pracy

Czy obecne zadanie jest najpierw obejrzane i zmierzone? Bez punktu odniesienia produkt nie ma czego pobić, a każdy prototyp wygląda na poprawę.

Czy model interakcji jest rozstrzygnięty przed rysowaniem ekranów? Gdzie system proponuje, gdzie decyduje człowiek, jak wyraża się niezgodę. Jeśli oferta przechodzi z warsztatów prosto do makiet, ekrany podejmą tę decyzję przypadkiem.

Czy system projektowy jest na końcu, jeśli w ogóle? System projektowy zbudowany przed przetestowaniem interakcji jest ozdobą na niesprawdzonym pomyśle. Ma swoje miejsce — po tym, jak wiadomo, że produkt działa.

Infografika

Dwie oferty na ten sam produkt

Znajomy kształt

• –Warsztaty, persony, ścieżki użytkownika
• –Dopracowane ekrany od początku
• –Prototyp tylko z dobrymi odpowiedziami
• –Test zadowolenia
• –System projektowy na starcie

Projekt pod niepewność

• →Obecne zadanie obejrzane i zmierzone
• →Model interakcji przed ekranami
• →Prototyp z realistycznymi błędami
• →Test czasu sprawdzania i przeoczeń
• →System projektowy później, jeśli trzeba

Mniejsze sygnały, na które warto zwrócić uwagę

Jak pokazywana jest pewność. Oferta planująca wyświetlanie procentu pewności jeszcze nie odkryła, że użytkownicy czytają procenty jako precyzję, której prawie nigdy nie mają. Struktura — na czym opiera się odpowiedź, co było niejednoznaczne, na co system odmówił odpowiedzi — zwykle działa lepiej.

Gdzie trafiają źródła. Pokazanie w jednym kliknięciu, na czym oparta jest odpowiedź, to jeden z najtańszych sposobów na przyspieszenie sprawdzania. Jeśli oferta nie wspomina o źródłach, nikt ich nie zaprojektuje.

Co dzieje się z poprawkami. Gdy człowiek poprawia wynik, czy ta poprawka gdzieś trafia, czy przepada? Oferta milcząca w tej sprawie da produkt, który codziennie prosi o tę samą poprawkę.

Uczciwość co do dopasowania. Dobry dostawca powie, jeśli potrzebujecie raczej odświeżenia wizualnego od studia projektowego albo jeśli zadanie u podstaw nie jest jeszcze na tyle zdefiniowane, żeby je projektować.

O co zapytać na spotkaniu

Poproście o porażki z wcześniejszego testu prototypu — nie o podsumowanie, tylko o wnioski, w których ludzie przeoczyli błąd albo się poddali. Dostawca, który robił tę pracę, będzie je miał i nie będzie się ich wstydził. Ten, który ma tylko historie sukcesu, prawdopodobnie testował tylko sukces.

Zapytajcie, ile trwa jeden przepływ. Konkretna odpowiedź — kilka tygodni na model interakcji i przetestowany prototyp — sugeruje doświadczenie. Odpowiedź otwarta sugeruje, że praca nie została ułożona wokół decyzji, którą musicie podjąć.

Zapytajcie wreszcie, kto z ich strony będzie siedział na sesjach testowych. Jeśli tylko młodszy badacz, a autorzy projektu poznają wyniki z raportu, poprawki będą dokładnie tak dobre jak ten raport.

Jak pracujemy

Projektowanie aplikacji AI-native ułożyliśmy wokół tych pytań i odpowiadamy na nie tak, jak sami chcielibyśmy je usłyszeć. Model interakcji i przetestowany prototyp dla jednego przepływu to zwykle trzy do pięciu tygodni. Często pracujemy razem z istniejącym zespołem projektowym: on zna Wasz produkt i użytkowników, my dokładamy język projektowy dla niepewności.