Większość produktów AI przegrywa na interfejsie, nie na modelu

Większość produktów AI przegrywa na interfejsie

Większość zespołów nadal mówi o produktach AI tak, jakby najważniejszym pytaniem była jakość modelu.

Użytkownik nie doświadcza jakości modelu bezpośrednio. Doświadcza raczej:

• czy system wydaje się bezpieczny w użyciu,
• czy widać, na czym odpowiedź się opiera,
• czy da się odzyskać kontrolę, kiedy coś pójdzie źle,
• oraz czy czas, pieniądze albo prywatne dane są zagrożone.

Dlatego tak wiele produktów AI wygląda mocno na demie, a słabo w realnym użyciu. Model może być już wystarczająco dobry. Interfejs dalej uczy użytkownika złego mental modelu.

Nie traktuję AI UX jako warstwy polerki po tym, jak model "już działa". Traktuję go jako warstwę kontroli, która decyduje, czy niepewność modelu staje się używalna czy groźna.

Problem zaufania jest już dobrze znany

To nie jest nowy ani niszowy problem projektowy.

Microsoft w HAX Toolkit od lat powtarza te same podstawy: jasno powiedz, co system potrafi, jasno powiedz, jak dobrze to robi, wspieraj efektywną korektę i wyjaśniaj, dlaczego system zachował się tak, a nie inaczej.

Google PAIR Guidebook opisuje to samo przez kalibrację zaufania, feedback, kontrolę i graceful failure. NIST w Generative AI Profile mówi o tym bardziej operacyjnie: przejrzystość, human oversight i kontrola ryzyka.

Wniosek jest prosty. Branży nie brakuje zasad. Brakuje zespołów, które wbudowują je w produkt przed wdrożeniem.

Trzy miejsca, w których zaufanie do AI psuje się w realnych produktach

Ten failure mode łatwiej zobaczyć na konkretnych flow niż na abstrakcyjnych poradach projektowych.

1. Droga generacja bez finansowej jasności

W Waku jedno z ważnych pytań UX nie brzmiało "czy potrafimy wygenerować obraz?" Brzmiało raczej "czy użytkownik rozumie koszt i granicę uprawnień, zanim generacja się zacznie?"

Jeśli wywołanie generacji zużywa kredyty albo może uruchomić overage, najgorszy UX to gładko wyglądający przycisk, po którym przychodzi niespodzianka. Użytkownik klika, czeka i dopiero wtedy dowiaduje się, że nie ma balansu albo potrzebuje dodatkowego potwierdzenia.

To nie jest tylko słaby UX. To sprawia, że produkt wydaje się niebezpieczny.

Mocniejszy kształt wygląda tak:

• stan kredytów jest widoczny przed akcją,
• entitlement checks dzieją się zanim droga ścieżka ruszy,
• overage jest potwierdzany zanim użytkownik się zaangażuje,
• postęp generacji jest widoczny, gdy już startuje,
• i istnieje bezpieczna ścieżka stop albo retry, gdy run się wysypie.

Właśnie to mam na myśli, gdy mówię, że AI UX to kontrola produktu, a nie dekoracja.

2. Niejasna intencja bez kroku zawężającego

Waku pokazało też inną ważną lekcję.

Użytkownicy nie zawsze przychodzą z dobrym promptem. Czasem nie mają tekstu, mają słabą intencję albo tylko luźny kierunek. Jeśli produkt wysyła to prosto do modelu, interfejs zrzuca product judgment na koszt tokenów.

To zwykle kończy się jedną z dwóch złych rzeczy:

• generycznym wynikiem, który wygląda ładnie, ale mija się z potrzebą,
• albo drogą pętlą retry, w której użytkownik musi zgadywać, jak lepiej promptować.

Lepszy UX nie polega na uczeniu użytkownika prompt engineeringu. Polega na zawężeniu zadania za niego.

To może znaczyć:

• przykładowe punkty startowe,
• strukturyzowane wybory przed freeform inputem,
• jedno krótkie pytanie doprecyzowujące,
• albo jawne constraints typu styl, zakres i source mode.

Produkt powinien przejąć więcej obciążenia poznawczego niż użytkownik.

3. Wrażliwe odpowiedzi, które wyglądają pewniej niż są

Fotelik wymusił najczytelniejszą wersję problemu zaufania.

To AI-assisted political matching product zbudowany wokół structured extraction, scoringu, retrievalu i explainable results. W takiej domenie płynny answer box nie wystarcza.

Jeśli UI pokazuje elegancką odpowiedź bez provenance, użytkownik nie widzi różnicy między:

• grounded output,
• częściowym evidence,
• sprzecznym evidence,
• i modelowym zgadywaniem.

Dlatego pchałem ten produkt w stronę:

• claimów opartych o źródła,
• bardziej strukturalnej formy odpowiedzi,
• węższych twierdzeń zamiast szerokiego wording,
• explainability blisko wyniku,
• oraz jawnej ścieżki low-confidence, kiedy evidence było słabe.

W wrażliwej domenie najczystsza odpowiedź często nie jest najdłuższa. Jest tą, która uczciwie komunikuje własne limity.

Before i after: ten sam feature AI może uczyć dwóch różnych rzeczy

Flow	Słaby AI UX	Mocny AI UX
Płatna generacja (Waku)	Użytkownik klika Generate, czeka, a potem wpada w niespodziankę z kredytami albo permissionem	Stan kredytów jest widoczny od razu, overage potwierdzany wcześniej, progres streamowany, a stop / retry są jasne
Niejasna intencja (Waku)	Produkt akceptuje pustą albo słabą intencję i oddaje użytkownikowi ciężar poprawiania promptu	Produkt zawęża zadanie przez przykłady, constraints albo jedno krótkie doprecyzowanie przed wydaniem tokenów
Wrażliwe odpowiedzi (Fotelik)	Jeden elegancki answer box sprawia, że grounded i chwiejne claimy wyglądają tak samo	Źródła, struktura, explainability i stany low-confidence pomagają użytkownikowi dobrze skalibrować zaufanie

Ta różnica before/after to właśnie prawdziwa robota. Nie kolejny prompt tweak.

Cztery pytania, na które dobry AI UX musi odpowiedzieć

Kiedy przeglądam feature AI, chcę, żeby interfejs szybko odpowiadał na cztery pytania.

Na czym to się opiera?

Jeśli odpowiedź używa dokumentów, tooli albo wcześniejszego kontekstu usera, trzeba to powiedzieć. Jeśli zbiór źródeł jest wąski, to też powinno być jawne.

Użytkownik nie powinien zgadywać, czy system użył:

• jego własnych plików,
• informacji publicznych,
• wcześniejszego kontekstu rozmowy,
• czy może niczego naprawdę wiarygodnego.

Jak bardzo powinienem temu ufać?

Nie lubię sztucznie precyzyjnych badge'y. Ale zależy mi na dobrze skalibrowanym zaufaniu.

To zwykle znaczy:

• jaśniejsze granice,
• widoczne źródła,
• jawny copy dla low confidence,
• i inny sposób prezentacji dla odpowiedzi grounded versus słabych.

Co mogę zrobić, jeśli to jest złe?

Tu nadal wykłada się dużo zespołów.

Jeśli jedyną ścieżką odzyskania jest "zacznij od nowa", to feature nie jest gotowy. Użytkownik potrzebuje możliwości:

• poprawić constraints,
• wybrać inne źródła,
• poprosić o doprecyzowanie,
• zatrzymać run,
• bezpiecznie powtórzyć próbę,
• albo przejść na ścieżkę z człowiekiem.

Microsoft HAX nazywa to support efficient correction. To jest dokładnie właściwe określenie.

Jaki jest koszt tej akcji?

Nie chodzi tylko o pieniądze. Chodzi też o:

• czas oczekiwania,
• ekspozycję prywatnych danych,
• i o to, czy akcja jest odwracalna.

Jeśli user zaraz wyda kredyty, wyśle wrażliwy content albo uruchomi drogi workflow, interfejs powinien to uczynić czytelnym zanim akcja wystartuje.

Najmniejszy state model AI, któremu ufam przed wdrożeniem

Jednym z najczęstszych błędów implementacyjnych jest traktowanie AI UI jako pojedynczego response boxa.

W praktyce to jest state machine.

Dla większości flow product AI chcę co najmniej takiej klarowności stanów:

type AiState =
  | "idle"
  | "clarifying"
  | "confirming"
  | "running"
  | "streaming"
  | "low_confidence"
  | "blocked"
  | "error"
  | "done";

type AiViewModel = {
  state: AiState;
  message?: string;
  sources?: Array<{ label: string; href: string }>;
  actions?: string[];
};

Dlaczego właśnie te stany?

• clarifying obsługuje niejasną intencję zanim spalimy output,
• confirming obsługuje koszt albo granicę permissionu zanim user się zaangażuje,
• streaming zmniejsza martwą latencję,
• low_confidence oddziela słabe evidence od normalnego zakończenia,
• blocked przykrywa ograniczenia typu entitlement albo policy,
• error sprawia, że recovery jest uczciwe zamiast mgliste.

To jest też miejsce, gdzie liczy się accessibility. Streaming text, dynamiczne aktualizacje i zmieniające się akcje dalej muszą działać z klawiaturą, focus management i czytelnymi announcementami. AI nie ma taryfy ulgowej względem bazowego poziomu WCAG.

Co mierzę, zanim powiem, że użytkownicy ufają temu feature'owi

Jeśli zaufanie ma znaczenie, chcę mieć choć trochę dowodu, że interfejs robi swoją robotę.

Interesują mnie takie metryki jak:

• low-confidence rate,
• clarification rate,
• cancel rate przy dłuższych runach,
• correction rate po pierwszej odpowiedzi,
• source-open rate,
• fallback rate,
• oraz koszt na jedno skuteczne wykonanie zadania.

To nie są idealne metryki zaufania. Ale i tak są dużo lepsze niż "ludzie klikali feature."

Jeśli correction rate jest wysoki, a source-open rate bliski zeru, UI może ukrywać ważny kontekst. Jeśli cancel rate skacze przy generacji, stan oczekiwania może być źle zaprojektowany. Jeśli output low-confidence wygląda identycznie jak normalny, feature będzie uczył over-trust.

To dlatego lubię pracę nad AI UX. Siedzi dokładnie tam, gdzie spotykają się product judgment, systems thinking i zaufanie użytkownika.

Wniosek

Większość produktów AI nie potrzebuje bardziej teatralnego interfejsu. Potrzebuje bardziej uczciwego.

Zadaniem AI UX nie jest sprawić, żeby model wydawał się magiczny. Jego zadaniem jest sprawić, żeby system był czytelny, sterowalny i na tyle bezpieczny, żeby użytkownik chciał go użyć drugi raz.

Jeśli chcesz lepszej adopcji, przestań pytać tylko o to, czy model zrobił się mądrzejszy. Zapytaj, czy interfejs mówi prawdę o niepewności, recovery, koszcie i evidence.

To właśnie tam najczęściej dalej siedzi prawdziwa luka produktowa.