Fluent Design w aplikacji AI: czytelność i kontrola

Użytkownik widzi odpowiedź AI i duży przycisk „Zastosuj”. Czy wie, co zostanie zmienione, skąd pochodzi wynik i jak poprawić błąd? Fluent Design może pomóc uporządkować interfejs, ale o jego jakości decyduje możliwość świadomego wykonania zadania. W aplikacji AI projektuj razem wygląd, informację o stanie i kontrolę nad działaniem.

Czym jest Fluent 2

Fluent 2 to system projektowania Microsoft obejmujący zasady, zasoby i komponenty do budowy spójnych doświadczeń użytkownika. Daje zespołowi wspólny punkt wyjścia dla wyglądu i zachowania elementów aplikacji. Nie jest modelem AI ani usługą wykonującą zadania za użytkownika.

Historyczne opisy Fluent często skupiają się na świetle, głębi i materiałach. Przy projektowaniu dzisiejszej aplikacji biznesowej potrzebujesz szerszego spojrzenia: czytelnych treści, dostępności, konsekwentnych interakcji i stanów błędu. Sam efekt wizualny nie odpowie na pytanie, czy zapis został wykonany.

Nie musisz kopiować wyglądu konkretnej aplikacji Microsoft. Najpierw ustal zachowania i nazwy, które będą wspólne w twoim produkcie. Jeśli „Zapisz” na jednym ekranie zapisuje szkic, a na drugim wysyła wiadomość klientowi, podobne przyciski mogą zwiększyć liczbę pomyłek.

Oddziel propozycję od wykonanej operacji

Wytyczne Responsible AI dla Fluent podkreślają przejrzystość, realistyczne oczekiwania, ograniczanie nadmiernego zaufania oraz kontrolę użytkownika. Zalecają także umożliwienie weryfikacji źródeł i przekazywania informacji o błędach. To zasady projektowe; biblioteka komponentów nie wdroży ich automatycznie.

Zastosuj je do jednej konkretnej czynności. Załóżmy, że aplikacja przygotowuje opis zgłoszenia na podstawie notatek konsultanta. Użytkownik powinien odróżnić treść wygenerowaną od zatwierdzonego wpisu. Status „gotowe” jest niejasny, jeśli nie wiadomo, czy gotowy jest szkic, czy zapis w systemie.

Stan zadania	Informacja potrzebna użytkownikowi	Przykładowa etykieta
Przygotowanie	Co aplikacja właśnie przetwarza?	Tworzenie szkicu z wybranych notatek
Propozycja	Czy treść jest już zapisana?	Szkic do sprawdzenia
Decyzja	Jaki będzie skutek przycisku?	Zapisz zatwierdzony opis
Zakończenie	Czy operacja się powiodła?	Opis zapisany w zgłoszeniu
Błąd	Co można zrobić dalej?	Zapis nie powiódł się; szkic zachowany

Przykładowe etykiety trzeba dopasować do rzeczywistego działania. Nie pokazuj „szkic zachowany”, jeżeli po odświeżeniu znika. Nie wyświetlaj kolejnych etapów wyszukiwania tylko po to, żeby oczekiwanie wyglądało ciekawiej. Komunikat powinien odpowiadać stanowi aplikacji.

Modelowy test: czy ludzie wiedzą, co zatwierdzają

Poniższy przykład jest syntetyczny i nie opisuje projektu autora. Przygotuj dwie wersje tego samego ekranu. Pierwsza ma przycisk „Zastosuj”, druga opisuje skutek jako „Zapisz opis w zgłoszeniu” i pokazuje podgląd zmiany. Obie korzystają z identycznej odpowiedzi AI.

Załóżmy, że w próbie z dziesięcioma osobami sześć poprawnie przewiduje skutek pierwszego przycisku, a dziewięć rozumie drugi. Otrzymujesz odpowiednio 60% i 90% w tej próbie. Różnica wynosi 30 punktów procentowych. To sygnał do dalszego badania, nie dowód uniwersalnej poprawy produktywności.

Nie pytaj wyłącznie, która wersja wygląda lepiej. Poproś uczestnika, aby opisał spodziewany skutek, wykonał zadanie i znalazł sposób poprawienia wpisu. Zapisz momenty zawahania. Osoba może lubić ekran, a jednocześnie błędnie rozumieć jego działanie.

Wprowadź również błędną propozycję AI: na przykład pomylony numer sprawy. Sprawdź, czy użytkownik odnajdzie materiał źródłowy i zauważy niezgodność przed zapisem. Sam link „źródła” nie wystarcza, jeśli prowadzi do całego katalogu dokumentów i nie pomaga znaleźć konkretnego fragmentu.

Dostępność sprawdzaj w całej ścieżce

Dokumentacja dostępności Fluent przedstawia komponenty jako podstawę budowy dostępnego interfejsu. Nie oznacza to automatycznej zgodności gotowej aplikacji. Sposób połączenia elementów, etykiety, kolejność fokusu i treść komunikatów należą do odpowiedzialności zespołu produktu.

W praktycznym odbiorze przejdź całą ścieżkę bez myszy. Sprawdź, czy po zamknięciu okna dialogowego użytkownik wraca do sensownego miejsca. Powiększ tekst i zweryfikuj, czy przyciski nadal są dostępne. Błąd powinien być zrozumiały bez polegania wyłącznie na czerwonym kolorze.

Próba odbioru	Co obserwujesz
Nawigacja klawiaturą	Możliwość dotarcia do działania i powrotu
Powiększenie tekstu	Czytelność i dostęp do wszystkich kontrolek
Odczyt komunikatu błędu	Powiązanie problemu z właściwym polem
Długa odpowiedź AI	Dostęp do źródeł oraz decyzji bez zgubienia kontekstu
Przerwanie operacji	Jasność tego, co zostało wykonane

Ustal też, jak aplikacja zachowa się podczas długiego oczekiwania. Użytkownik potrzebuje informacji, czy może bezpiecznie przejść do innego zadania i gdzie później znajdzie wynik. Taką decyzję projektuj razem z mechanizmem przetwarzania, zamiast dopisywać komunikat dopiero na końcu.

Przy odbiorze użyj również danych dłuższych niż w makiecie: rozbudowanej nazwy klienta, kilku źródeł i wielozdaniowego uzasadnienia. Krótki tekst demonstracyjny łatwo ukrywa problemy z układem.

Zaplanuj obsługę informacji o błędzie

Przycisk negatywnej oceny odpowiedzi ma sens wtedy, gdy wiadomo, co dzieje się ze zgłoszeniem. Własna procedura może rozróżniać błędne dane, nieprzydatną treść i problem z działaniem aplikacji. Każda kategoria powinna prowadzić do osoby, która potrafi ją przeanalizować.

Nie wymagaj od użytkownika pisania długiego raportu w środku pracy. Daj możliwość wskazania problematycznego fragmentu oraz krótkiego komentarza. Przed wysłaniem pokaż, jakie dane zostaną dołączone. W przeciwnym razie prośba o opinię może nieświadomie obejmować pełną treść sprawy.

Spójny interfejs powinien wspierać zasady odpowiedzialności opisane w systemie pracy firmy z AI. Jeżeli budujesz rozwiązanie w środowisku Microsoft, sprawdź też wybór typu aplikacji Power Apps, zanim dopracujesz pojedyncze ekrany.

W poniedziałek wybierz jedną operację, która zmienia dane. Narysuj jej stan przed rozpoczęciem, propozycję, potwierdzenie i błąd. Następnie poproś trzy osoby o wyjaśnienie skutku każdego przycisku. Popraw najpierw to, czego nie rozumieją; dopiero potem dopracuj efekty wizualne.