Funkcja AI działa. Nikt z niej nie korzysta

Wykres użycia opowiada całą historię jedną linią. Funkcja wystartowała, ludzie próbowali jej przez tydzień, potem krzywa się spłaszczyła. Zespół inżynierski sprawdza wyniki i są w większości dobre. Ktoś proponuje lepszy model, dłuższy prompt albo szkolenie.

To rozsądne zakupy i rzadko zmieniają kształt krzywej. Kiedy funkcja AI zwykle ma rację, a ludzie i tak jej nie używają, przyczyna rzadko leży w modelu. Leży w tym, ile korzystanie z niej kosztuje człowieka przed ekranem.

Trzy sytuacje, których wykres nie odróżnia

Rozczarowująca funkcja AI jest zwykle w jednym z trzech miejsc i każde wymaga innej naprawy.

Ignorowana. Wynik jest dobry, ale użytkownik nie umie tego stwierdzić bez wykonania pracy od nowa — więc wykonuje ją od nowa i przestaje pytać. Jakość systemu jest prawdziwa i niewidoczna.

Nadmiernie zaufana. Ludzie akceptują wszystko, użycie wygląda zdrowo, a błędy przechodzą prosto do następnego procesu, gdzie płaci za nie ktoś inny. To ta groźna sytuacja, bo w raporcie wygląda jak sukces.

Słusznie odrzucona. Wynik nie jest wystarczająco dobry do tego zadania i użytkownicy trafnie to ocenili. Tu projektowanie nie pomoże, a rozmowa należy do tego, kto wybrał przypadek użycia.

Pierwsze pytanie dla osoby dysponującej budżetem brzmi: którą z tych sytuacji macie. Kilka godzin obserwowania ludzi przy pracy z funkcją zwykle na nie odpowiada. Same liczby użycia — nigdy.

Infografika

Czego nie pokazują liczby użycia

Zwykle ma racjęCzęsto się myli

IgnorowanaDobry wynik bez szybkiego sposobu sprawdzenia, więc ludzie robią pracę sami.

SkalibrowanaLudzie sprawdzają tam, gdzie system zgłasza wątpliwość, resztę przeglądają.

Słusznie odrzuconaUżytkownicy mają rację. Poprawiać trzeba przypadek użycia, nie ekran.

Nadmiernie zaufanaBłędy przechodzą do kolejnego procesu. Wygląda jak sukces.

Niskie zaufanieWysokie zaufanie

Dlaczego lepszy model rzadko to naprawia

Dokładniejszy model trochę poprawia sytuację funkcji ignorowanej i trochę pogarsza sytuację nadmiernego zaufania. Ci, którzy nie ufają, nadal nie mają jak szybko sprawdzić wyniku. Ci, którzy ufają wszystkiemu, ufają teraz jeszcze bardziej.

Zachowanie zmienia interakcja: czy odpowiedź przychodzi razem z tym, na czym się opiera, czy niepewne fragmenty są oznaczone, czy błędne pole da się poprawić bez robienia wszystkiego od nowa i czy system potrafi powiedzieć, że nie wie. To są decyzje projektowe. W większości nieużywanych funkcji nikt ich nie podjął świadomie — zapadły domyślnie, w rękach tego, kto zbudował pierwszy ekran.

O co zapytać, zanim wydacie cokolwiek

Jak ludzie robili to wcześniej i ile to trwało? Jeśli nikt nie zmierzył starego sposobu, nie ma punktu odniesienia, a funkcję porównuje się z wrażeniem.

Ile trwa sprawdzenie odpowiedzi? Nie wygenerowanie — potwierdzenie albo poprawka. Jeśli sprawdzanie trwa tyle co sama praca, użytkownicy zachowują się racjonalnie.

Co się dzieje, gdy system się myli? Jeśli uczciwa odpowiedź brzmi „nikt tego od razu nie zauważa”, prawdopodobnie jesteście w ćwiartce nadmiernego zaufania, niezależnie od tego, jak wygląda użycie.

Czy użytkownik widzi, na czym opiera się odpowiedź? Jeśli nie, każde sprawdzenie oznacza przejście do innego systemu. To częsty powód, dla którego dobra funkcja jest ignorowana, i zwykle najtańszy do usunięcia.

Kto był w pokoju, kiedy projektowano ekran? Jeśli tylko ludzie budujący model, interfejs zaprojektowano wokół wyniku, a nie wokół człowieka, który ma na jego podstawie działać.

Ile kosztuje Was ustalenie tego

Mniej niż zmiana modelu. Obejrzenie obecnego zadania, ustalenie kształtu interakcji i przetestowanie poprawionego prototypu z ludźmi, którzy wykonują tę pracę, to dla jednego przepływu zwykle kilka tygodni. Wymaga to kilku godzin od garstki prawdziwych użytkowników i właściciela produktu, który może podejmować decyzje. Tydzień obserwacji i jeden prototyp kosztują ułamek kolejnej rundy prac nad modelem, a odpowiadają na pytanie, którego ta runda nawet nie zadaje.

Wynikiem nie jest ładniejszy ekran. Jest nim jasna odpowiedź, z którą z trzech sytuacji macie do czynienia, a jeśli z jedną z dwóch pierwszych — przetestowana zmiana interakcji z czasem sprawdzania zmierzonym przed i po.

Kiedy mówimy „nie”

Jeśli AI pracuje całkowicie w tle i nikt nie podejmuje działań na podstawie jego wyników, płaska krzywa użycia nie jest problemem projektowym. Jeśli potrzebne jest odświeżenie wizualne, warto je kupić od studia projektowego. A jeśli samo zadanie nigdy nie zostało zdefiniowane, projektowanie to obnaży — ale powoli.

W pozostałych przypadkach projektowanie aplikacji AI-native zaczyna się tam, gdzie ten tekst: od obserwowania ludzi, którzy z funkcji nie korzystają, i ustalenia dlaczego.