Jeśli Twój CMS wymaga dwugodzinnego szkolenia, zanim ktokolwiek go użyje, to CMS ma problem z UX. Nie chodzi o lepsze szkolenie. Chodzi o system, który go nie potrzebuje.
Tradycyjne przekazanie CMS to rytuał, przez który przechodzi każdy, a z którego nikt nie ma pożytku. Dwugodzinne szkolenie, instrukcja PDF na dysku współdzielonym i nagranie ekranu, którego nikt nie ogląda. Miesiąc później wyszkolony redaktor zapomniał połowę, instrukcja jest nieaktualna, a jedyna osoba, która naprawdę rozumiała system, odeszła z firmy. Szkolenie traktowano jak remedium. W rzeczywistości było objawem.
Istnieje lepszy standard: zbudować CMS tak dobrze, żeby szkolenie stało się zbędne. CMS bez szkolenia to taki, w którym redaktor siada, patrzy na interfejs edycji i tworzy kompletną, poprawną stronę pierwszego dnia, bez przewodnika. Brzmi ambitnie, ale da się to osiągnąć. Zrobiliśmy to w produkcji.
W projekcie Edenred zespół marketingu dostał witrynę Drupal z poprawnie wdrożonym systemem komponentów, środowiskiem staging do eksploracji i bez formalnego szkolenia. Zaczął samodzielnie budować realne strony na produkcji, ten sam efekt, który opisujemy w case study Edenred, gdzie etapowa modernizacja CMS zastąpiła plany pełnej przebudowy. Ten artykuł omawia wzorce projektowe i implementacyjne, które czynią ten wynik powtarzalnym. Większość dotyczy każdego CMS, nie tylko Drupala.
W tym artykule:
- Dlaczego „bez szkolenia” to właściwy standard?
- Jak środowisko staging zastępuje szkolenie?
- Które wzorce UX panelu eliminują szkolenie?
- Jak organizować paragrafy, by były intuicyjne?
- Kiedy „bez szkolenia” to za mało?
- Jak zmierzyć, czy to zadziałało?
Dlaczego „bez szkolenia” to właściwy standard?
Po szkolenie sięga się wtedy, gdy interfejsu nie potrafi się zrozumieć. Każda minuta spędzona na uczeniu obsługi CMS to dowód na to, że system nie był wystarczająco intuicyjny. Jeśli musisz coś wyjaśniać sobie i innym, oznacza to, że nie jest to oczywiste.
Są trzy powody, dla których szkolenie to słaby fundament.
Szkolenie nie zostaje w głowie. Ludzie zapominają sesje z upływem czasu. Nikt nie czyta dokumentacji. Nagranie z onboardingu sprzed kwartału to nie miejsce, w którym zajęty redaktor szuka pomocy, gdy musi opublikować stronę danego popołudnia.
Rotacja resetuje zegar. Każdy nowy pracownik, każda reorganizacja, każdy kontraktor z agencji wymaga ponownego szkolenia. System zależny od szkolenia cicho się degraduje przy każdej zmianie zespołu. System, który "się sam wyjaśnia", onboarduje nowych ludzi za darmo.
Szkolenie ukrywa prawdziwy problem. Póki szkolenie łata dziury, nikomu nie chce się ruszyć etykiet pól, ich kolejności ani mylących nazw paragrafów. Dług UX rośnie, a rachunek płaci każdy redaktor, który siada do systemu. Tak samo było u nas w Edenred, zanim przebudowaliśmy Drupal Paragraphs pod niezależność redaktorów.
Test jest prosty: posadź zupełnie nowego redaktora przed systemem i zobacz, czy pierwszego dnia zbuduje kompletną stronę sam. Jeśli musisz szczerze przyznać, że nie, problem znajduje się w doświadczeniu edycji, a nie w redaktorze.
Jak środowisko staging zastępuje szkolenie?
Najskuteczniejszą alternatywą dla prezentacji szkoleniowej jest kompletna strona przykładowa na środowisku staging. Zamiast tłumaczyć, jak działa system, pokazujesz w pełni zbudowaną stronę i pozwalasz ją rozebrać.
Strona przykładowa powinna być wyczerpująca. Każdy typ paragrafu, każdy wariant koloru i stylu, treść wyglądająca na prawdziwą, a nie „lorem ipsum”. Chodzi o to, żeby redaktor w jednym miejscu zobaczył w pełni to, co może zbudować, w dopracowanym stanie, do którego może dążyć, i który może kopiować.
Potem cofasz się i pozwalasz zespołowi eksplorować we własnym tempie. Kliknąć w paragraf. Edytować tekst. Zmienić wariant koloru. Zobaczyć podgląd. Cofnąć. To szkolenie "self-service", które działa, bo ludzie uczą się znacznie lepiej przez działanie niż przez oglądanie. Eksploracja na bezpiecznej kopii staging nie niesie ryzyka: nic, czego dotkną, nie wpływa na witrynę live, a to właśnie sprawia, że chcą eksperymentować.
Tak właśnie było w Edenred. Przebieg wyglądał w sposób następujący: demo na stagingu, samodzielna eksploracja, potem produkcja, bez szkolenia. Zespół przeklikał stronę przykładową, zrozumiał model komponentów przez bezpośrednią pracę i zaczął tworzyć własne strony. Staging jako warsztat. W tej fazie odkrywania zwykle zaczyna się też przejście do mindsetu komponentowego, czyli moment, w którym redaktorzy łączą bloki w sposób, którego nikt nie planował.
Przeczytaj też: Drupal Paragraphs: od bezużytecznej konfiguracji do CMS, który wspiera redaktorów oraz Nie przebudowuj, ewoluuj: etapowy framework modernizacji CMS.
Które wzorce UX panelu eliminują szkolenie?
Zabawa na stagingu działa tylko wtedy, gdy interfejs jest zbudowany tak, żeby dało się go zrozumieć na pierwszy rzut oka. Te wzorce UX panelu robią pracę, a większość z nich kosztuje niewiele.
Opisowe nazwy paragrafów. „Sekcja hero z obrazem” mówi redaktorowi dokładnie, co wybiera. „Paragraph_hero_v2” nie mówi nic i zmusza do zgadywania. Nazywaj każdy komponent według tego, co robi i jak wygląda, językiem, jakiego użyłby nietechniczny redaktor.
Logiczna kolejność pól. Układaj pola tak, jak przebiega praca: tytuł, potem obraz, następnie treść i opcje. Nie alfabetycznie, nie w kolejności dodawania do bazy. Najczęściej używane pole na pierwszym miejscu, formularz ma czytać się od góry do dołu jak samo zadanie.
Rozsądne wartości domyślne. Wstępnie wybierz najczęstszy wariant koloru. Wypełnij opcjonalne pola przykładową treścią, żeby redaktor widział wzorzec i edytował go, zamiast wymyślać od zera. Dobre ustawienia domyślne oznaczają, że redaktor, który nic nie zmieni, i tak dostanie poprawny wynik.
Kontekstowa pomoc przy polach. Krótkie, konkretne wskazówki przy właściwym polu: „Zalecany rozmiar obrazu: 1200 × 600 px”. Dokumentacja dokładnie tam i wtedy, gdy jest potrzebna, zamiast w zewnętrznym pliku, którego nikt nie otwiera.
Możliwość podglądu. Redaktor powinien widzieć to, co buduje, w trakcie budowania. Gdy wynik działania jest od razu widoczny, ludzie eksperymentują. Moduły takie jak Geysir przyspieszają i wizualizują edycję paragrafów, a to obniża próg próbowania czegoś nowego.
Nowoczesny motyw administracyjny. Zamiana przestarzałego domyślnego panelu na współczesny motyw, np. Gin zmienia oczekiwania, zanim ktokolwiek dotknie pola. Nowoczesny interfejs sygnalizuje: „to aktualne, dobrze zrobione narzędzie”, więc redaktor podchodzi z pewnością, a nie z obawą wobec starego oprogramowania. Instalacja trwa minuty, a zmiana postrzegania jest duża.
Jak organizować paragrafy, żeby były intuicyjne?
Nawet przy dobrych etykietach i ustawieniach domyślnych redaktor staje przed ścianą piętnastu identycznie wyglądających opcji i zawiesza się. Organizacja zamienia bibliotekę komponentów w menu, po którym da się poruszać bez pomocy.
Grupuj komponenty według celu. Grupuj typy paragrafów w intuicyjne kategorie: treść, media, layout, wezwanie do działania. Grupowanie zamienia pytanie „który z tych piętnastu?” w „potrzebuję CTA, więc patrzę w grupie CTA”, czyli w pytanie, na które redaktor sam odpowie.
Ograniczaj to, co widać w danym kontekście. Nie udostępniaj wszystkich piętnastu typów paragrafów na każdym typie treści. Landing page i artykuł informacyjny potrzebują innych klocków. Pokazanie tylko pasujących komponentów w danym kontekście redukuje paraliż wyboru i zapobiega błędom.
Używaj wskazówek wizualnych. Ikony lub etykiety wizualne pomagają rozpoznać właściwy komponent szybciej niż czytanie każdej nazwy. Mała miniatura lub ikona przy „karuzeli” czy „akordeonie” pozwala wybierać wzrokiem, jak w każdej nowoczesnej aplikacji.
Spraw, żeby zmiana kolejności była naturalna. Przeciąganie paragrafów na stronie powinno być płynne i responsywne. Gdy przeorganizowanie treści wydaje się odbywać bez wysiłku, redaktor traktuje strukturę strony jako coś swojego, a to dokładnie takie zachowanie, jakie chcesz uzyskać.
Przeczytaj też: Tworzenie treści w Drupalu, moduł Paragraphs oraz Szybki sposób na edycję i dostosowanie paragrafu w Drupalu.
Kiedy „bez szkolenia” to za mało?
„Bez szkolenia” to właściwy domyślny standard, ale warto uczciwie przyznać, gdzie leżą jego granice. Niektóre rzeczy naprawdę wymagają krótkiego wyjaśnienia, a udawanie inaczej tylko frustruje.
Złożone workflow redakcyjne. Wieloetapowe łańcuchy akceptacji, stany moderacji i workflow tłumaczeń wymagają wiedzy o procesie, której sam formularz edycji nie przekaże. Redaktor musi rozumieć reguły organizacji, nie tylko przyciski.
Zaawansowane funkcje. Pola warunkowe, złożone layouty wieloregionowe lub integracje z systemami zewnętrznymi mogą nieść złożoność, której dobra etykieta w pełni nie usunie.
W takich przypadkach odpowiedzią jest krótkie, ukierunkowane szkolenie dotyczące konkretnej funkcji, a nie warsztat obejmujący cały CMS, który na nowo uczy podstaw, a których nikt nie potrzebował. I gdy to możliwe, dokumentuj złożone części w pomocy kontekstowej w interfejsie, a nie w pliku zewnętrznym. Pomoc obok pola jest widoczna, a PDF na dysku współdzielonym już nie. Zasada obowiązuje i tutaj: trzymaj wyjaśnienie jak najbliżej zadania.
Jak zmierzyć, czy to zadziałało?
„Bez szkolenia” to teza, którą można sprawdzić dowodami. Kilka sygnałów mówi, czy doświadczenie edycji jest naprawdę samowyjaśniające.
Czas do pierwszej strony. Jak szybko nowy redaktor stworzy pierwszą kompletną stronę? Jeśli zrobi to pierwszego dnia bez pomocy, interfejs działa. Jeśli trzeba tygodnia prowadzenia za rękę, nie.
Liczba zgłoszeń „jak to zrobić”. Licz zgłoszenia wsparcia, które w istocie dotyczą użyteczności: „jak dodać baner”, „gdzie zmienić kolor”. Niska i malejąca liczba oznacza, że interfejs sam odpowiada na te pytania. Stały strumień wskazuje prosto na pola i etykiety wymagające poprawy.
Użycie kreatywne kontra z góry narzucone. Czy redaktorzy używają komponentów tylko tak, jak pokazano, czy łączą je i przekształcają w sposób nieplanowany? Najlepszy wskaźnik naprawdę intuicyjnego systemu jest taki: redaktorzy budują strony, których nigdy nie zaplanowano w projekcie. W Edenred zespół samodzielnie wykorzystał paragrafy produktowe do promocji webinarów, czyli dostarczył dowód, że system był zrozumiany.
Gdy redaktorzy zaczynają Cię zaskakiwać, CMS przeszedł od „używalny z pomocą” do prawdziwego self-service, a szkolenie, którego nie zorganizowałeś, było dobrze zaoszczędzonym czasem.
Chcesz CMS Drupal, z którego redaktorzy korzystają od pierwszego dnia?
Ten artykuł opiera się na naszej produkcyjnej pracy dla Edenred Polska, gdzie poprawnie wdrożony, oparty na komponentach system Drupal pozwolił zespołowi marketingu budować realne strony na produkcji, bez żadnego szkolenia. Staging do eksploracji, opisowe komponenty, rozsądne ustawienia domyślne i nowoczesny panel razem sprawiły, że onboarding CMS nie wymagał warsztatu, po prostu się wydarzył.
Jeśli Twoi redaktorzy unikają CMS, zgłaszają tickety przy rutynowych zmianach albo co kilka miesięcy potrzebują przypomnienia, problem leży w doświadczeniu edycji, a nie w ludziach. Nasz zespół buduje intuicyjne, przyjazne redaktorom systemy Drupal, które nie wymagają instrukcji. Zobacz nasze usługi Drupal, żeby dowiedzieć się, jak podejście bez szkolenia może zmienić pracę Twojego zespołu.
