Powtarzalny element potrzebuje wspólnej reguły
Na jednej podstronie przycisk otwiera formularz, na drugiej podobny element prowadzi do pliku, a w panelu identyczny kolor oznacza usunięcie danych. Problem nie wynika z braku atrakcyjnej grafiki. Brakuje wspólnego języka interfejsu. System komponentów porządkuje ten język: określa wygląd, zachowanie, dostępne warianty i sytuacje, w których dany element ma być używany.
Nie musi to być wielki projekt dla korporacji. Niewielka firma może zacząć od kilku rzeczy: przycisku, pola formularza, karty usługi, komunikatu i nagłówka sekcji. W przykładowym serwisie szkoleniowym te elementy pojawiają się w ofercie, zapisach i panelu uczestnika. Zmiana ich wspólnej definicji jest prostsza do kontrolowania niż ręczne poprawianie każdego ekranu osobno.
Oddziel wartości bazowe od gotowych wzorców
Kolor, odstęp czy promień narożnika to wartości bazowe. Przycisk korzysta z tych wartości, ale dodatkowo określa zachowanie podczas aktywacji. Wzorzec zapisu na szkolenie łączy przyciski, pola i komunikaty w cały proces. GOV.UK rozróżnia komponenty oraz wzorce odpowiadające na konkretne zadania użytkownika. To przydatna inspiracja organizacyjna, nie obowiązek kopiowania ich wyglądu.
Nazwy powinny opisywać rolę. „Tekst pomocniczy” jest stabilniejszy niż „szary 12”, bo pomaga zrozumieć przeznaczenie, nawet gdy zmieni się paleta. Ogranicz liczbę wariantów do rzeczywistych potrzeb. System z kilkudziesięcioma podobnymi przyciskami odtwarza chaos, który miał usunąć, tylko w bardziej uporządkowanym katalogu.
Zaprojektuj stany, których nie widać na makiecie
Komponent to nie tylko wygląd początkowy. Pole może być puste, wypełnione, błędne, nieaktywne albo oczekiwać na sprawdzenie. Przyciski potrzebują widocznego fokusu i informacji o trwającym działaniu. Formularz powinien mieć czytelne etykiety oraz komunikaty powiązane z odpowiednimi kontrolkami. WAI opisuje te zasady niezależnie od użytej biblioteki interfejsu.
Przygotuj stronę demonstracyjną pokazującą stany obok siebie. Dodaj długie polskie etykiety, cenę z większą liczbą cyfr oraz pustą listę wyników. To nie są szczegóły kosmetyczne. Takie dane ujawniają, czy element ma sztywną wysokość, czy może się zawinąć i czy komunikat nadal mieści się na wąskim ekranie bez obcinania treści.
Daj redaktorom bezpieczne możliwości wyboru
CMS nie powinien wymagać wpisywania dowolnego koloru i rozmiaru przy każdym nagłówku. Lepiej udostępnić rozpoznawalne warianty: zwykła sekcja, wyróżniona informacja, lista korzyści. Redaktor koncentruje się wtedy na znaczeniu materiału. Możliwość zmiany wszystkiego bez ograniczeń bywa pozorną swobodą, po której kilka osób tworzy niezgodne style i przypadkowe odstępy.
MyTworzymy.pl może być punktem kontaktu przy planowaniu tak uporządkowanej witryny dla firmy z całej Polski. Rozmowa o komponentach jest szczególnie przydatna wtedy, gdy stronę później uzupełnia kilka osób. Warto ustalić nie tylko wygląd pierwszych ekranów, lecz także zakres samodzielnej edycji, który nie rozbije spójności serwisu.
Aktualizuj przez wersje i sprawdzaj zależności
Zmiana komponentu może objąć wiele miejsc. Dlatego przy poprawce zapisz, co zmieniono i gdzie element jest używany. Wersja z nową etykietą nie musi wymagać tego samego odbioru co zmiana sposobu walidacji. Rozróżnienie zmiany kosmetycznej od zachowania pomaga dobrać zakres testu i uniknąć sprawdzania całej witryny bez konkretnego celu.
Dobrym przykładem jest podsumowanie błędów. Jeżeli prowadzi odnośnikami do pól, trzeba sprawdzić zarówno treść, jak i działanie tych odnośników oraz kolejność fokusu. GOV.UK zaleca spójność komunikatu w podsumowaniu i przy polu. Ujednolicenie tekstu pomaga osobie poprawiającej dane rozpoznać ten sam problem w dwóch miejscach.
Pilnuj wyjątków zamiast zakazywać ich bezwzględnie
Nie każda sekcja musi wyglądać tak samo. Cennik, czytelnik dokumentu i kalendarz mają różne potrzeby. Wyjątek powinien jednak mieć uzasadnienie: inny rodzaj danych, odmienne zadanie albo istotne ograniczenie urządzenia. Zapisz, czy to jednorazowy element, czy kandydat na nowy komponent. Bez tej decyzji rozwiązanie łatwo zostanie skopiowane i zacznie żyć jako nieudokumentowany standard.
Przy rozbudowie serwisu z MyTworzymy.pl warto pokazać nie tylko obecną stronę, ale także planowane funkcje. Inaczej będzie projektowany zestaw dla kilku podstron informacyjnych, a inaczej dla przyszłego portalu klienta. Współpraca obejmująca firmy z całej Polski pozwala omawiać te decyzje zdalnie; kluczowe jest udokumentowanie ich skutków dla dalszej edycji.
Odbierz system na rzeczywistych treściach
Przygotuj próbkę reprezentującą codzienną pracę: długi tytuł, dwa akapity opisu, formularz z błędem i tabelę na telefonie. Poproś redaktora o złożenie strony wyłącznie z dostępnych elementów. Zapisz, gdzie potrzebował pomocy i gdzie był zmuszony obchodzić narzucony układ. To pokaże, czy system wspiera pracę, czy tylko dobrze wygląda w prezentacji.
Na końcu powinny istnieć trzy rzeczy: działające komponenty, krótkie zasady ich użycia i osoba odpowiedzialna za zmiany. Bez właściciela nawet dobra biblioteka z czasem staje się archiwum. Spójność nie polega na zamrożeniu projektu, lecz na tym, że nowa potrzeba jest rozpatrywana świadomie i nie wprowadza przypadkowej reguły na jednej podstronie.
W dokumentacji dodaj również przykład niewłaściwego użycia. Karta usługi nie musi nadawać się do komunikatu o błędzie, a kolor akcentu nie powinien automatycznie oznaczać ostrzeżenia. Jeden kontrprzykład często wyjaśnia regułę lepiej niż długa definicja. Nowy redaktor szybciej rozpozna granicę między dostępnym wariantem a przypadkowym obejściem.