Słownik: UX, UI, layout, makieta i prototyp

Pracując nad przygotowaniem nowej strony lub odświeżeniem jej wyglądu napotkasz na fachowe określenia. Pewnie usłyszysz „zacznijmy od funkcji i mapy strony”, a potem usłyszysz o „makiecie”, „prototypie w widoku mobilnym”. Dla osób zajmujących się tym na co dzień to całkowicie zrozumiałe, dla Ciebie jako Klienta ważne jest to, co w praktyce oznaczają te określenia i jakich decyzji oczekują wykonawcy. I to właśnie wyjaśniamy.

Nie musisz znać różnicy między wireframe’em, mockupem, layoutem i prototypem. Ważne jest zrozumienie aktualnego etapu prac i tego, jaką jest w nim Twoja rola: co widzisz, co stanowi przedmiot oceny i jaki jest następny krok: Twój i wykonawcy projektu. To ważne także dlatego, że nie wszystkie zespoły używają słów „makieta”, „layout” i „prototyp” w tym samym znaczeniu. Ta sama nazwa może oznaczać prosty szkic, dopracowany widok albo klikalną prezentację. Nazwa pliku lub etapu nie wystarcza więc do ustalenia zakresu.

Wyjaśniamy terminy, które faktycznie pojawiają się w ofertach, warsztatach, komentarzach do projektu, narzędziach projektowych i odbiorze wdrożenia. Napotkasz je w trakcie prac z wybranym przez Ciebie wykonawcą. Przy każdym ważnym pojęciu wskazujemy:

• co oznacza;
• gdzie pojawia się podczas pracy;
• co można wtedy ocenić;
• z czym nie należy go mylić.

Nie opisujemy „jedynego dobrego” modelu prac. Prosta strona firmy usługowej, katalog producenta i sklep internetowy mogą wymagać innego podejścia i etapowania. Ważne jest nie to, czy powstał każdy możliwy dokument, lecz czy klient i wykonawca tak samo rozumieją cel, zakres oraz kryterium akceptacji danego etapu. Bo właśnie to decyduje o efektach i sukcesie przedsięwzięcia.

Nazwa, czyli funkcja, nie kompletność

W perspektywie klienta i wykonawcy ważny jest etap prac. Ważne jest to, co faktycznie jest oceniane i jakie decyzje ze strony klienta są potrzebne w danym momencie. Zanim zaakceptujesz makietę, layout albo prototyp, ustal:

1. jakie strony, widoki i warianty obejmuje;
2. czy zawiera treść przykładową, roboczą czy zatwierdzoną;
3. czy jest statyczny, czy pozwala wykonywać określone działania;
4. jakie szerokości, urządzenia i stany elementów pokazuje;
5. co zatwierdzasz teraz;
6. czego jeszcze nie oceniasz;
7. jaki dowód będzie potrzebny przy odbiorze wdrożenia.

Co można ocenić?

Etapy projektu i oceniane materiały powinny odpowiadać jego złożoności. Jeden projekt może być prostszy i krótszy, złożoność innego może wymagać rozbicia decyzji na większą liczbę etapów, wymagających większej liczby „materiałów”, na których pracujemy. A to oznacza większą liczbę koniecznych decyzji. Ważne, aby mieć jasność, co jest oceniane w danej chwili i jakie decyzje należy podjąć – i na jakiej podstawie. Aby to wyjaśnić, przygotowaliśmy krótkie zestawienie.

UX, UI, użyteczność i dostępność

UX — user experience

UX to doświadczenie związane z użyciem albo przewidywanym użyciem strony, sklepu lub usługi. Obejmuje więcej niż wygląd ekranu. UX pojawia się podczas rozpoznawania potrzeb, planowania, projektowania, testowania i późniejszego rozwijania strony. Problemem UX może być niejasna informacja, trudna nawigacja, brak potrzebnych danych o produkcie, zbyt długa droga do formularza albo sytuacja, w której klient wysyła zapytanie i nie wie, co stanie się dalej.

Co oceniasz? Czy strona pomaga określonemu odbiorcy wykonać określone zadanie w rzeczywistych warunkach.

Nie mylić: poprawa UX nie zawsze oznacza zmianę wyglądu. Czasem ważniejsza jest treść, kolejność kroków albo sposób obsługi zgłoszenia.

UI — user interface

UI to elementy, przez które strona przekazuje informacje i przyjmuje działania użytkownika. Do UI należą między innymi menu, przyciski, linki, pola formularza, komunikaty, przełączniki, ikony i kontrolki wyboru. Projekt UI określa również ich wygląd, rozmieszczenie, stany oraz sposób reagowania na działanie użytkownika.

Co oceniasz? Czy element jest czytelny, zrozumiały, możliwy do obsłużenia i zachowuje się przewidywalnie.

Nie mylić: UI jest częścią UX, ale nie opisuje całego doświadczenia klienta.

Użyteczność — usability

Użyteczność opisuje, czy określeni użytkownicy mogą osiągnąć określony cel skutecznie, sprawnie i z odpowiednim poziomem satysfakcji w danym kontekście. Pytanie „czy strona jest użyteczna?” jest zbyt ogólne. Trzeba wiedzieć: dla kogo, w jakiej sytuacji i przy jakim zadaniu. Sklep może pozwalać łatwo znaleźć produkt po nazwie, a jednocześnie utrudniać wybór wariantu. Formularz może wyglądać prosto, ale nie wyjaśniać błędu po wysłaniu.

Co oceniasz? Czy użytkownik rozumie, co ma zrobić, potrafi zakończyć zadanie i otrzymuje informację o rezultacie.

Nie mylić: atrakcyjny wygląd nie jest dowodem użyteczności.

Dostępność — accessibility

Dostępność cyfrowa oznacza projektowanie i wykonanie strony tak, aby osoby z niepełnosprawnościami mogły postrzegać treść, rozumieć ją, poruszać się po serwisie i korzystać z jego funkcji bez barier. Dostępność dotyczy zarówno projektu, treści, jak i kodu. Na etapie widoków można ocenić między innymi hierarchię, kontrast, kolejność informacji, komunikaty i widoczność fokusu. Dopiero działające wdrożenie pozwala sprawdzić również semantykę kodu, obsługę klawiaturą i współpracę z technologiami asystującymi.

Co oceniasz? Czy projekt uwzględnia różne sposoby postrzegania i obsługi oraz czy przewidziano późniejsze testy techniczne.

Nie mylić: ogólna wygoda nie zastępuje wymagań dostępności, a sam audyt automatyczny nie sprawdza całego doświadczenia.

Projektować dla ludzi, nie dla maszyn

Projektowanie zorientowane na człowieka — HCD

Human-centred design to iteracyjne projektowanie oparte na zrozumieniu użytkowników, ich zadań i kontekstu oraz na sprawdzaniu kolejnych rozwiązań. W praktyce oznacza to, że zespół nie zaczyna wyłącznie od pytania „jak ma wyglądać strona?”, lecz ustala, komu ma służyć, co ta osoba próbuje osiągnąć i jakie ma ograniczenia. Następnie projektuje rozwiązanie, sprawdza je i poprawia.

Co oceniasz? Czy decyzje wynikają z rozpoznanego problemu i dowodów, a nie wyłącznie z preferencji osób uczestniczących w projekcie.

Nie mylić: HCD nie jest pojedynczym warsztatem ani stylem wizualnym.

Projektowanie interakcji — interaction design

Potrzeba użytkownika opisuje rezultat, który dana osoba chce osiągnąć, a nie z góry wybrane rozwiązanie. „Chcę sprawdzić, czy firma wykonuje usługę w moim mieście” może być potrzebą. „Potrzebuję wyskakującego okna z mapą” jest już propozycją rozwiązania. To rozróżnienie chroni projekt przed budowaniem funkcji, zanim zespół zrozumie problem.

Co oceniasz? Czy potrzeba brzmi jak realne zadanie odbiorcy i czy ma oparcie w danych, rozmowach, obserwacjach albo innych wiarygodnych materiałach.

Nie mylić: życzenie właściciela strony nie jest automatycznie potrzebą jej użytkownika.

Badanie użytkowników — user research

User research to planowe zbieranie i analizowanie informacji o użytkownikach, ich zachowaniach, potrzebach i warunkach działania. Może obejmować rozmowy, obserwacje, analizę zapytań, danych z wyszukiwarki, zgłoszeń do obsługi i sposobu wykonywania zadań. Metodę dobiera się do pytania, na które zespół chce odpowiedzieć.

Co oceniasz? Jakie pytanie badawcze postawiono, kogo objęto badaniem, z jakiego materiału wynikają wnioski i jak wpłynęły one na projekt.

Nie mylić: rozmowa wyłącznie z właścicielem firmy nie zastępuje kontaktu z rzeczywistymi albo prawdopodobnymi użytkownikami.

Zadanie i scenariusz

Zadanie określa rezultat do osiągnięcia, a scenariusz umieszcza go w realistycznej sytuacji. Przykład dla strony usługowej: „Szukasz wykonawcy, który może rozpocząć pracę we wrześniu. Sprawdź zakres usługi i dowiedz się, jak zapytać o termin”. Przykład dla sklepu: „Znajdź produkt w odpowiednim rozmiarze, sprawdź dostawę i przejdź do koszyka”.

Co oceniasz? Czy scenariusz jest wiarygodny, zrozumiały i nie zdradza uczestnikowi sposobu wykonania zadania.

Nie mylić: lista kroków napisana przez projektanta nie jest neutralnym zadaniem testowym.

Test użyteczności

Test użyteczności polega na obserwowaniu, jak uczestnik próbuje wykonać konkretne zadania przy użyciu prototypu albo działającej strony. W trakcie testu ważne jest nie tylko to, co uczestnik mówi, ale również gdzie się zatrzymuje, czego szuka, jak interpretuje komunikaty i czy potrafi zakończyć zadanie. Test może dotyczyć całej ścieżki albo jednego ryzykownego fragmentu.

Co oceniasz? Czy zadania odpowiadają pytaniom badawczym, a uczestnicy przypominają osoby, które rzeczywiście mogą korzystać z rozwiązania.

Nie mylić: pytanie „czy projekt Ci się podoba?” nie jest testem użyteczności.

Persona

Persona to fikcyjny, lecz oparty na rozpoznanych cechach opis reprezentatywnego typu użytkownika. Może porządkować informacje o celach, zachowaniach, barierach i kontekście. Nie każda mała strona potrzebuje formalnych person. Czasem wystarczy dobrze opisany odbiorca, jego zadanie i sytuacja.

Co oceniasz? Z jakich badań lub danych wynika opis oraz które decyzje pomaga podejmować.

Nie mylić: wymyślone imię, zdjęcie ze stocka i ogólne zainteresowania nie tworzą jeszcze wiarygodnej persony.

Struktura treści i drogi użytkownika – IA

Architektura informacji to sposób organizowania, grupowania, nazywania i łączenia treści, aby odbiorca mógł je odnaleźć i zrozumieć. IA pojawia się przy porządkowaniu oferty, kategorii produktów, menu, filtrów, nazw sekcji i relacji między stronami. Powinna odpowiadać sposobowi myślenia odbiorcy, a nie wyłącznie strukturze działów firmy.

Co oceniasz? Czy grupy informacji są logiczne dla użytkownika, a ich nazwy pomagają przewidzieć zawartość.

Nie myl: architektura informacji nie jest samym menu. Menu pokazuje jedynie część przyjętej organizacji.

Mapa serwisu — sitemap

Mapa serwisu pokazuje planowane strony lub sekcje oraz ich relacje. Może mieć postać drzewa, listy albo diagramu. Pomaga ustalić zakres nowej witryny, zauważyć brakujące strony, powtórzenia i niewłaściwe miejsca w hierarchii. Przy przebudowie może również wspierać plan migracji treści.

Co oceniasz? Kompletność, hierarchię, nazwy i zależności między stronami.

Nie myl: projektowa mapa serwisu nie jest tym samym co techniczna mapa XML przeznaczona dla robotów wyszukiwarek.

Nawigacja

Nawigacja obejmuje sposoby poruszania się po stronie lub procesie. Należą do niej nie tylko pozycje głównego menu, ale również linki w treści, wyszukiwarka, okruszki, stopka, paginacja, wskaźnik kroków i możliwość powrotu do poprzedniego etapu.

Co oceniasz? Czy użytkownik rozumie, gdzie się znajduje, dokąd może przejść i jak wrócić.

Nie myl: nawigacja nie jest wyłącznie nagłówkiem strony.

Taksonomia

Taksonomia to uzgodniony sposób klasyfikowania i nazywania treści, usług albo produktów. W sklepie może porządkować kategorie, typy, marki i cechy używane w filtrach. W bibliotece wiedzy pomaga konsekwentnie przypisywać tematy. Dobra taksonomia ułatwia rozwój, ponieważ nowe treści trafiają do przewidzianego systemu zamiast tworzyć kolejne przypadkowe grupy.

Co oceniasz? Czy kategorie się nie dublują, ich znaczenie jest rozłączne tam, gdzie powinno, a nazwy są zrozumiałe dla odbiorców.

Nie myl: kategoria, tag i filtr mogą korzystać z taksonomii, ale nie muszą być jednym mechanizmem.

User flow

User flow pokazuje typową albo planowaną sekwencję kroków potrzebnych do wykonania konkretnego zadania. Może opisywać wysłanie zapytania, zapis, zakup, rezerwację, odzyskanie hasła albo wybór produktu. Powinien uwzględniać istotne decyzje, rozgałęzienia, błędy i zakończenie procesu.

Co oceniasz? Punkt rozpoczęcia, kolejność kroków, potrzebne informacje i obsługę wyjątków.

Nie myl: flow opisuje drogę w jednym zadaniu; nie zastępuje obrazu całego doświadczenia klienta.

Wireflow

Wireflow łączy uproszczone widoki wireframe z diagramem przejść między nimi. Jest przydatny, gdy sam schemat blokowy nie pokazuje wystarczająco dobrze zawartości ekranów, a pełny prototyp nie jest jeszcze potrzebny. Pozwala ustalić, co użytkownik widzi na danym etapie i dokąd prowadzi każde działanie.

Co oceniasz? Czy widoki zawierają informacje potrzebne do podjęcia decyzji i czy przejścia tworzą kompletną drogę.

Nie myl: wireflow nie musi być klikalnym prototypem.

Szkic, makieta, layout i prototyp

Szkic — sketch

Szkic to szybkie, uproszczone przedstawienie pomysłu. Może powstać na papierze, tablicy albo w prostym narzędziu. Służy porównaniu wariantów i rozpoczęciu rozmowy, zanim zespół poświęci czas na szczegóły.

Co oceniasz? Pomysł, zakres i ogólną logikę rozwiązania.

Nie myl: szkic nie jest zobowiązaniem do finalnego wyglądu.

Moodboard

Moodboard to zestaw obrazów, kolorów, typografii, faktur i innych odniesień komunikujących kierunek albo nastrój wizualny. Pomaga sprawdzić, czy słowa takie jak „spokojny”, „techniczny”, „premium” albo „naturalny” są podobnie rozumiane przez klienta i projektanta.

Co oceniasz? Czy kierunek pasuje do marki, odbiorców i sytuacji użycia.

Nie myl: moodboard nie jest projektem strony, zestawem finalnych zdjęć ani biblioteką gotowych komponentów.

Wireframe

Wireframe to uproszczony szkielet widoku pokazujący strukturę, kolejność informacji i podstawowe funkcje przed pełnym projektem wizualnym. Pozwala wcześnie poprawić priorytety i kompletność, zanim uwaga przeniesie się na kolory, typografię i obrazy. Wireframe może być bardzo prosty albo nieco bardziej szczegółowy — zależnie od celu.

Co oceniasz? Czy widok zawiera potrzebne informacje i działania oraz czy ich kolejność wspiera zadanie.

Nie myl: wireframe nie służy do zatwierdzania finalnej oprawy wizualnej.

Makieta

Słowo „makieta” wymaga doprecyzowania w konkretnym projekcie. W jednym zespole może oznaczać wireframe, w innym statyczny projekt o wysokim poziomie szczegółowości, a jeszcze gdzie indziej cały zestaw widoków. Jeżeli termin pojawia się w ofercie lub umowie, trzeba opisać zakres ekranów, treści, poziom szczegółowości i interaktywność.

Co oceniasz? Dokładnie te cechy, które zostały wskazane w zakresie makiety.

Nie myl: sama nazwa „makieta” nie określa poziomu ukończenia projektu.

Mockup

Mockup to statyczna, zwykle szczegółowa symulacja wyglądu planowanego interfejsu. Pokazuje typografię, kolory, obrazy, hierarchię i styl elementów. Może przedstawiać tylko wybrane, reprezentatywne widoki, dlatego trzeba ustalić, w jaki sposób pozostałe strony będą z nich wynikać.

Co oceniasz? Hierarchię wizualną, czytelność, kierunek marki i sposób prezentowania rzeczywistej treści.

Nie myl: mockup nie jest klikalnym prototypem ani działającą stroną.

Layout

Layout opisuje rozmieszczenie elementów i relacje przestrzenne w widoku. W polskiej praktyce często oznacza także wizualny projekt strony. Termin może dotyczyć ogólnego układu, konkretnego widoku albo rodziny podobnych stron. Dlatego również tutaj warto zapisać, czy odbierany jest sam system rozmieszczenia, czy gotowy wygląd z treścią i obrazami.

Co oceniasz? Widoczność najważniejszych informacji, hierarchię, czytelność i zgodność z charakterem organizacji.

Nie myl: zaakceptowany layout nie jest jeszcze działającą stroną.

Prototyp

Prototyp to wersja przygotowana do sprawdzenia określonego pomysłu, przejścia, zachowania albo funkcji przed pełnym wdrożeniem. Może być papierowym szkicem, klikalną prezentacją albo uproszczoną wersją w kodzie. Rodzaj prototypu powinien odpowiadać pytaniu. Do sprawdzenia kolejności treści nie potrzeba symulacji wszystkich animacji. Do testu checkoutu statyczny obraz może jednak nie wystarczyć.

Co oceniasz? Tylko te interakcje i zadania, które prototyp rzeczywiście obejmuje.

Nie myl: realistyczny wygląd nie potwierdza kodu produkcyjnego, bezpieczeństwa, wydajności ani pełnej funkcjonalności.

Wierność — fidelity

Wierność opisuje stopień odwzorowania wybranych cech planowanego rozwiązania. Prototyp może mieć wysoką wierność wizualną i niską wierność zachowania albo odwrotnie. Dlatego określenia low fidelity i high fidelity nie mówią samodzielnie, co już działa.

Co oceniasz? Które cechy odwzorowano — wygląd, treść, przejścia, dane, interakcje lub zachowanie na różnych ekranach.

Nie myl: high fidelity nie oznacza „prawie gotowe” pod każdym względem.

Handoff — przekazanie projektu

Handoff to przekazanie wykonawcy materiałów i ustaleń potrzebnych do wdrożenia. Może obejmować widoki, komponenty, treści, zasoby, wymiary, zachowania, stany, warianty, reguły responsywności i kryteria akceptacji. Zakres zależy od sposobu współpracy projektanta z wykonawcą.

Co oceniasz? Czy wykonawca otrzymał informacje potrzebne do odtworzenia zamierzonego działania, a nie tylko wyglądu jednego ekranu.

Nie myl: sam link do pliku projektowego nie zawsze jest kompletną specyfikacją.

Jak powstaje spójny interfejs?

Hierarchia wizualna

Hierarchia wizualna pomaga rozpoznać ważność i kolejność informacji. Powstaje przez zestawienie rozmiaru, położenia, kontrastu, odstępów, typografii i grupowania. Powinna wspierać zadanie odbiorcy: najważniejszy element nie zawsze jest największym elementem marketingowym.

Co oceniasz? Co zauważasz najpierw, co rozumiesz jako element powiązany i jaki następny krok sugeruje widok.

Grid — siatka

Grid to system kontenerów, kolumn, rzędów i odstępów pomagający porządkować oraz wyrównywać treści. Siatka ułatwia budowanie spójnych widoków i ich zmianę przy różnych szerokościach. Nie musi mieć zawsze dwunastu kolumn, a użytkownik nie powinien widzieć jej jako osobnego elementu.

Co oceniasz? Czy treści są logicznie wyrównane, układ ma rytm i nie rozpada się przy zmianie ilości materiału.

Spacing, odstępy i white space

Odstępy to przestrzeń między elementami i wokół nich. Pomagają grupować, oddzielać oraz budować rytm. White space nie musi być biały. Chodzi o wolną przestrzeń, która pozwala rozpoznać relacje i zmniejsza wizualny tłok. Zbyt małe odstępy mogą łączyć elementy, które nie są powiązane; zbyt duże mogą rozrywać jedną całość.

Co oceniasz? Czy grupowanie jest zrozumiałe, tekst daje się czytać, a interfejs nie sprawia wrażenia przypadkowego.

Komponent

Komponent to wielokrotnie używana część interfejsu, np. przycisk, pole formularza, karta produktu, komunikat lub nawigacja. Komponent powinien mieć opis przeznaczenia, treści, wariantów, stanów i zasad użycia. Dzięki temu podobne elementy nie są projektowane od nowa na każdej stronie.

Co oceniasz? Czy komponent rozwiązuje konkretną potrzebę, zachowuje się spójnie i ma wszystkie potrzebne odmiany.

Wzorzec — pattern

Wzorzec to utrwalony sposób rozwiązania określonego zadania lub typu strony, często złożony z kilku komponentów. Przykładem może być sposób wprowadzania adresu, odzyskiwania hasła albo przechodzenia przez wieloetapowy formularz. Wzorzec powinien być dostosowany do kontekstu i sprawdzony, a nie kopiowany tylko dlatego, że występuje w znanym serwisie.

Co oceniasz? Jakie zadanie rozwiązuje, z jakich elementów się składa i w jakich warunkach powinien być używany.

Design token

Design token to nazwana decyzja projektowa, której przypisano wartość, np. kolor tekstu podstawowego, odstęp sekcji albo rozmiar nagłówka.

Tokeny pomagają używać tych samych decyzji w narzędziach projektowych i kodzie. Zamiast wielokrotnie wpisywać konkretny kolor, zespół może posługiwać się nazwą opisującą jego rolę. Standard wymiany tokenów między narzędziami rozwija Design Tokens Community Group; jego raport nie jest jednak standardem W3C.

Co oceniasz? Czy nazwy opisują funkcję, wartości są utrzymywane centralnie i wiadomo, gdzie obowiązują.

Design system — system projektowy

System projektowy łączy standardy, komponenty, wzorce i dokumentację potrzebne do spójnego projektowania oraz rozwijania interfejsu. Najbardziej przydaje się przy większych serwisach, wielu powiązanych usługach albo pracy kilku zespołów. Mała strona nie zawsze potrzebuje rozbudowanego systemu. Czasem wystarczy dobrze opisany zestaw komponentów, typografii, kolorów i zasad.

Co oceniasz? Zakres, jakość dokumentacji, dostępne komponenty oraz odpowiedzialność za utrzymanie i rozwój.

Wspólny język pomaga podejmować właściwe decyzje

Nie musisz zapamiętywać wszystkich angielskich nazw. Wystarczy wiedzieć, jakiego rodzaju materiał oglądasz, do jakiej decyzji ma prowadzić i czego jeszcze nie dowodzi. Zasadniczo, to kwestia tego, nad czym obecnie pracujemy i jakie trzeba podjąć decyzje – czego one dotyczą.

Jeżeli wykonawca używa innego nazewnictwa, nie musi to oznaczać błędu. Przed rozpoczęciem etapu warto jednak zapisać:

• co powstanie;
• jaki zakres obejmie;
• jak szczegółowy będzie materiał;
• co będzie można w nim zrobić;
• jakie treści i dane wykorzysta;
• co podlega akceptacji;
• po czym poznamy, że etap został zakończony.

Wspólny słownik ma chronić klienta i wykonawcę przed sytuacją, w której obie strony zatwierdzają ten sam plik, ale każda rozumie tę decyzję inaczej. A równocześnie, przyśpiesza i „uwspólnia” pracę. Przygotowaliśmy krótką ściągę pytań, na które zawsze warto znać odpowiedź:

1. Czy wiem, jaki problem lub zadanie rozwiązuje ten materiał?
2. Czy wiem, jakie strony, widoki i warianty obejmuje?
3. Czy używa treści przykładowej, roboczej czy finalnej?
4. Czy jest statyczny, czy pozwala wykonywać działania?
5. Czy pokazuje tylko stan domyślny, czy także błędy, ładowanie, powodzenie i brak danych?
6. Czy uwzględnia różne szerokości i sposób zmiany układu?
7. Czy mogę ocenić dostępność już teraz, czy część testów wymaga wdrożenia?
8. Czy wiem, które elementy są komponentami używanymi również w innych miejscach?
9. Czy zgłaszana uwaga dotyczy bieżącej decyzji, czy zmienia wcześniejsze ustalenie?
10. Czy zapisano, czego akceptacja tego materiału jeszcze nie potwierdza?

Źródła

• ISO 9241-110:2020 — Interaction principles (https://www.iso.org/standard/75258.html)
• W3C WAI — Accessibility, Usability, and Inclusion (https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/)
• Nielsen Norman Group — UX Deliverables Glossary (https://media.nngroup.com/media/articles/attachments/UX-Deliverables-Glossary-PDF-2.pdf)
• U.S. Web Design System — Design principles (https://designsystem.digital.gov/design-principles/)
• Material Design 3 — States (https://m3.material.io/foundations/interaction/states/overview)
• Paetzold-Byhain, Stoiber i Ognevoj — Potential and limitations of prototypes in developer-user communication (https://www.designsociety.org/publication/48705/potential_and_limitations_of_prototypes_in_developer-user_communication)

*Źródła zweryfikowano 15 września 2026 roku.