--- title: "Fluent Design w aplikacji AI: czytelność i kontrola" url: "https://majchrzycki.com/blog/microsoft-fluent-design-system-ai-apps" description: "Poznaj Fluent 2 w projektowaniu aplikacji AI. Sprawdź etykiety działań, stany błędu, dostępność i kontrolę użytkownika na modelowym przykładzie." --- # Fluent Design w aplikacji AI: czytelność i kontrola 30 czerwca 2024· Aktualizacja: 17 września 2026·3 min czytania·Krzysztof Majchrzycki Temat: [AI SDLC](https://majchrzycki.com/blog/filar/ai-sdlc) 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](https://fluent2.microsoft.design/) 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](https://fluent2.microsoft.design/responsible-AI) 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](https://fluent2.microsoft.design/accessibility) 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](https://majchrzycki.com/system). Jeżeli budujesz rozwiązanie w środowisku Microsoft, sprawdź też [wybór typu aplikacji Power Apps](https://majchrzycki.com/blog/co-to-jest-microsoft-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. - Copilot ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Material Design w aplikacji AI: kryteria wyboru](https://majchrzycki.com/blog/google-material-design-system-ai-apps) - [Design system dla aplikacji AI: jak wybrać](https://majchrzycki.com/blog/open-source-design-systems-ai-apps) - [IBM Carbon w aplikacji AI: projekt i odbiór](https://majchrzycki.com/blog/hugging-face-ai-apps-genai-0-0-0) - [Power Apps: jak wybrać typ aplikacji biznesowej](https://majchrzycki.com/blog/co-to-jest-microsoft-power-apps)