Projektowanie pod oprogramowanie, które zwykle ma rację

Klasyczne projektowanie interfejsów zakłada, że system jest poprawny, a użytkownik może się mylić. Projektowanie AI-native odwraca to: system jest szybki i zwykle trafny, a interfejs musi uczynić sprawdzenie tanim, wątpliwość oczywistą, a pomyłkę bezpieczną. Większość produktów AI upada właśnie tutaj, a nie na modelu.

  • Interfejsy projektowane pod sprawdzanie, nie tylko pod wynik. Miarą jest czas, w jakim człowiek potwierdza albo poprawia — bo ta liczba rozstrzyga, czy produkt w ogóle oszczędza czas.
  • Skalibrowane zaufanie. Użytkownicy wiedzący, kiedy sprawdzać, a kiedy nie, bo interfejs mówi im to uczciwie, zamiast podawać wszystko z tą samą pewnością.
  • Bezpieczna pomyłka. Błędność widoczna, tania i odwracalna zamiast cichej i drogiej.
  • Przetestowany prototyp. Klikalny, przed prawdziwymi użytkownikami, zanim ktokolwiek napisze kod produkcyjny.
Porozmawiajmy o tym

Co przekazujemy

  • Model interakcji

    Gdzie system proponuje, gdzie decyduje człowiek i jak wyraża się niezgodę. Centralna decyzja projektowa, podejmowana świadomie, a nie domyślnie.

  • Projektowanie niepewności

    Jak pokazać pewność bez bezsensownego procentu, co system mówi, gdy nie wie, i czego nigdy nie wolno mu zgadywać.

  • Układy pod sprawdzanie

    Ekrany zaprojektowane tak, żeby poprawny wynik dało się potwierdzić w sekundy, a błędny był oczywisty. Optymalizacja przypadku typowego czyni produkt opłacalnym.

  • Źródła i wyjaśnienie

    Na czym oparta jest odpowiedź, dostępne w jednym kliknięciu. Użytkownicy ufają systemom pokazującym źródła i porzucają te, które ich nie pokazują.

  • Ścieżki korekty

    Jak człowiek poprawia błędne wyjście i jak ta poprawka uczy system, zamiast być wyrzucona.

  • Prototyp i wyniki testów

    Działający prototyp przetestowany z ludźmi wykonującymi tę pracę, z porażkami spisanymi, a nie wygładzonymi w podsumowaniu.

Jak to przebiega

  1. 01

    Obejrzeć obecne zadanie

    Jak praca jest wykonywana dziś, z pomiarem czasu. Punkt odniesienia, który produkt musi pobić — rzadko taki, jak wszyscy zakładali.

  2. 02

    Zamodelować interakcję

    Rozstrzygnąć kształt propozycja-potwierdzenie przed rysowaniem ekranów. Układ z tego wynika, a nie odwrotnie.

  3. 03

    Prototyp

    Klikalny, z realistycznie błędnymi odpowiedziami w środku. Prototyp pokazujący tylko dobre wyjścia nie testuje niczego istotnego.

  4. 04

    Test i poprawki

    Z ludźmi, którzy naprawdę będą tego używać, z pomiarem czasu sprawdzania i wychwytywania błędów, a nie z pytaniem, czy się podobało.

Dobre dopasowanie, gdy

  • Budujecie produkt albo narzędzie wewnętrzne, w którym model produkuje coś, na czym człowiek działa.
  • Istniejąca funkcja AI działa technicznie i nikt z niej nie korzysta.
  • Użytkownicy albo nadmiernie ufają wynikom, albo całkowicie je ignorują.
  • Chcecie mieć projekt rozstrzygnięty przed zaangażowaniem budżetu inżynierskiego.

To nie ta usługa, gdy

  • AI działa w pełni w tle, bez punktu styku z człowiekiem. Wtedy to problem inżynierski i monitoringowy, a nie projektowy.
  • Chcecie odświeżenia wizualnego. To warto kupić i to nie jest to.
  • Zadanie u podstaw nie jest jeszcze zdefiniowane. Projektowanie to obnaży, ale to powolny sposób, żeby się dowiedzieć.

Najczęstsze pytania

To projektowanie UX czy produktu?
Jedno i drugie, skupione na jednym: na interakcji między człowiekiem a komponentem, który zwykle ma rację. Projektowanie wizualne wchodzi tam, gdzie temu służy — i powiemy, kiedy potrzebujecie studia projektowego, a nie nas.
Czy dostarczacie system projektowy?
Jeśli tego trzeba, tak. Częściej wartościowym wynikiem jest model interakcji i przetestowany prototyp, bo to one rozstrzygają, czy produkt działa — a system projektowy zbudowany wcześniej jest ozdobą na niesprawdzonym pomyśle.
Jak pokazać pewność bez procentu?
Zwykle strukturą, a nie liczbą: na czym opiera się odpowiedź, co było niejednoznaczne i czego system postanowił nie odpowiadać. Procenty użytkownicy czytają jako precyzję i prawie nigdy nie znaczą tego, na co wyglądają.
Czy możecie pracować z naszym zespołem projektowym?
Tak i często to najlepszy układ. Oni znają Wasz produkt i użytkowników; my dokładamy język projektowy dla niepewności — to naprawdę nowa praca, do której doświadczenie w klasycznym oprogramowaniu nikogo nie przygotowuje.
Ile to trwa?
Model interakcji i przetestowany prototyp dla jednego przepływu to zwykle trzy do pięciu tygodni. Dłużej zwykle znaczy, że zadanie u podstaw nie było zdefiniowane — a to wniosek, który warto mieć wcześnie.