Wasz zespół projektowy i pierwszy produkt AI

Większość organizacji, które budują pierwszy produkt AI, ma już projektantów. Znają użytkowników, produkt, markę i wewnętrzną politykę, i dowieźli oprogramowanie, z którego ludzie korzystają. Gdy pojawia się produkt AI, pytanie brzmi: oddać go im, zatrudnić kogoś nowego czy wziąć pomoc z zewnątrz. Najczęstsza odpowiedź, czyli zlecenie na zewnątrz „części AI”, zwykle działa najgorzej.

Co się przenosi, a co nie

Większość warsztatu dobrego projektanta działa bez zmian: badania z prawdziwymi użytkownikami, architektura informacji, czytelność wizualna, uwaga poświęcona momentowi, w którym człowiek musi coś rozstrzygnąć. Nie przenosi się założenie leżące pod klasycznym projektowaniem interfejsów — że system ma rację, a mylić się może użytkownik.

Komponent AI to odwraca. Jest szybki, zwykle trafny i czasem błędny, a interfejs musi uczynić sprawdzenie tanim, wątpliwość oczywistą, a pomyłkę bezpieczną. To wymaga kilku rzeczy, których wcześniej nikt nie potrzebował.

Pokazywanie niepewności bez liczby. Oznaczenie pól, co do których system nie był pewien, i powiedzenie, na co nie umiał odpowiedzieć — zamiast procentu, który użytkownicy przeczytają jako precyzję.

Dowód obok twierdzenia. Na czym opiera się odpowiedź, w jednym kliknięciu, bo to właśnie przyspiesza sprawdzanie.

Ścieżki korekty. Jak człowiek poprawia błędny wynik bez robienia wszystkiego od nowa i dokąd ta poprawka trafia.

Testowanie z błędnymi odpowiedziami. Prototypy z realistycznymi pomyłkami i sesje testowe mierzące czas sprawdzania i przeoczone błędy, a nie zadowolenie.

Żadna z tych rzeczy nie jest trudna, kiedy się ją raz zobaczy. Po prostu nie ma ich w portfolio kogoś, czyje oprogramowanie zawsze miało rację.

Infografika

Co przenosi się z klasycznego projektowania

Projektowanie wizualneArchitektura informacjiBadania z użytkownikamiUkłady pod sprawdzanieŚcieżki korektyPokazywanie niepewności

Przenosi sięNowe przy AI

Dlaczego zlecanie „części AI” zawodzi

Kusi układ, w którym zespół wewnętrzny projektuje produkt, a specjalista „ekrany AI”. Wynikiem są dwa języki projektowe w jednym produkcie i szew dokładnie tam, gdzie użytkownik najbardziej potrzebuje spójności: w momencie, w którym system przekazuje coś człowiekowi.

Taki układ zostawia też zespół wewnętrzny bez możliwości utrzymania tego, co zaprojektowano. Przychodzi następna funkcja, specjalisty już nie ma, a zespół projektuje ją po staremu, bo tylko ten język zna.

Układ, który działa

Pierwszy przepływ wspólnie. Wasi projektanci i specjalista projektują go razem — od obejrzenia obecnego zadania po test prototypu. Wasz zespół prowadzi w sprawach produktu, specjalista w sprawach niepewności.

Drugi prowadzi Wasz zespół. Specjalista przegląda, a nie projektuje. Tu język albo się przyjmuje, albo nie — i to najtańszy moment, żeby się o tym przekonać.

Spisujcie wzorce na bieżąco. Jak ten produkt pokazuje źródła, oznacza wątpliwość, obsługuje odmowę i przyjmuje poprawki: krótki, konkretny zestaw decyzji, a nie ogólny poradnik. Ten dokument pozwala zaprojektować trzeci przepływ bez nikogo z zewnątrz.

Ile to kosztuje Was w czasie i uwadze

Praca w parze działa tylko wtedy, gdy Wasi projektanci są do niej przydzieleni, a nie wciskają jej między inne zadania. Model interakcji i przetestowany prototyp dla jednego przepływu to zwykle trzy do pięciu tygodni. Do tego dochodzi dostęp do ludzi wykonujących tę pracę na sesje testowe i właściciel produktu, który podejmuje decyzje w ciągu dni, a nie na kolejnym komitecie.

Mniej oczywisty koszt to gotowość doświadczonego zespołu, żeby przez kilka tygodni być w jednej sprawie początkującym. Zespoły, którym to się udaje, wychodzą z nową kompetencją. Te, którym się nie udaje, zwykle traktują specjalistę jak dostawcę ekranów — czyli wracają do zlecania na zewnątrz inną drogą.

Jak wygląda dobry wynik

Wasz zespół umie własnymi słowami wyjaśnić, dlaczego dany ekran pokazuje źródła tam, gdzie je pokazuje, i oznacza wątpliwość tak, a nie inaczej. Drugi przepływ powstał w większości bez pomocy. Wzorce są spisane, krótkie i specyficzne dla Waszego produktu. A przy następnym przepływie pomoc z zewnątrz wyraźnie nie jest już potrzebna.

Jak pracujemy z zespołami projektowymi

Praca obok istniejącego zespołu projektowego to często najlepszy układ przy projektowaniu aplikacji AI-native. Wasz zespół zna produkt i użytkowników; my dokładamy język projektowy dla niepewności, bo to naprawdę nowa praca. A jeśli potrzebujecie raczej odświeżenia wizualnego, powiemy to wprost.