Prawdziwym efektem wdrożenia opartego na paragrafach nie są same paragrafy. To moment, w którym klient przestaje pytać o „nową stronę”, a zaczyna pytać o „nowy komponent”.
W każdym udanym projekcie CMS jest kamień milowy, który nie trafia do raportu statusu. To dzień, w którym prośba klienta zmienia formę. Zamiast „potrzebujemy landing page dla nowej karty podarunkowej” w mailu pojawia się: „potrzebujemy typu paragrafu z funkcjami w dwóch kolumnach, tak żeby dało się go użyć również gdzie indziej”. Taka prośba to sukces.
Oznacza to, że klient przyjął mindset komponentowy, czyli nawyk myślenia klockami wielokrotnego użytku zamiast jednorazowych stron i patrzy na witrynę tak samo jak Ty.
Ta zmiana jest warta więcej niż jakakolwiek pojedyncza funkcja. Klient myślący stronami jest zależny od Ciebie przy każdej najmniejszej poprawce. Klient myślący komponentami sam składa strony, zadaje mądrzejsze pytania i wraca po to, żeby rozwijać system, a nie go naprawiać. Dla project managerów i account managerów wspieranie tej zmiany to jedna z najskuteczniejszych rzeczy, jakie w ogóle można zrobić dla długiej relacji.
Ten artykuł opiera się na realnym projekcie dla Edenred Polska, międzynarodowej firmy z branży benefitów, która przeszła drogę od planu całkowitego odejścia od Drupala do regularnego zamawiania nowych komponentów. Opisujemy, jak rozwija się mindset komponentowy, dlaczego nie da się go wymusić i co możesz zrobić, żeby stworzyć warunki, w których taka zmiana ma szansę się wydarzyć.
W tym artykule:
- Dlaczego model „zróbcie mi stronę” hamuje klientów?
- Co się zmienia, gdy klienci zaczynają prosić o komponenty?
- Jak przebiega przejście do mindsetu komponentowego?
- Co ta zmiana oznacza dla relacji z agencją?
- Jak wspierać przejście do mindsetu komponentowego?
Dlaczego model „zróbcie mi stronę” hamuje klientów?
W tradycyjnym modelu każda potrzeba treściowa przychodzi jako prośba o stronę. „Potrzebuję landing page dla produktu X”. „Zrobicie stronę na kampanię wiosenną?”. Każda taka prośba uruchamia ten sam cykl: nowy design, nowe zadanie dla developerów, nowa pozycja w budżecie i dni albo tygodnie oczekiwania na publikację.
Ten model ma trzy strukturalne problemy i żaden z nich nie jest winą klienta.
Całkowita zależność. Bez agencji klient nie zrobi nic. Aktualizacja numeru telefonu, podmiana obrazu hero, zmiana kolejności dwóch sekcji, wszystko wymaga ticketu. W projekcie Edenred zespół marketingu doszedł do punktu, w którym wklejał gotowe grafiki na stronę zamiast edytować tekst, bo zgłoszenie prośby i czekanie zajmowało dłużej niż skorzystanie z narzędzia graficznego. To nie leniwy zespół. To zespół uwięziony w systemie opartym na stronach, ten sam wzorzec, który opisujemy w przewodniku o wdrożeniach Drupal Paragraphs, z których redaktorzy naprawdę korzystają.
Wolna iteracja. Gdy każda strona to osobna realizacja, od pomysłu do publikacji mijają tygodnie. Kampanie się przesuwają. Sezonowe okazje przepadają. Kalendarz marketingu układa się wokół kolejki developmentu, a nie wokół tego, co robi rynek.
Frustracja, która niszczy zaufanie. Klient czeka, agencja buduje, klient prosi o poprawki i pętla się powtarza. Wszystko zjada czas i dobre chęci. Wystarczająco długo i klient dochodzi do wniosku, że problem tkwi w samej platformie. Edenred doszła dokładnie do tego wniosku: planowała pełną przebudowę na innej technologii i w ogóle nie uwzględniła Drupala w zapytaniu ofertowym. Wtedy modernizacja CMS kontra przebudowa staje się decyzją zarządu.
Model oparty na stronach uczy klientów traktować witrynę jak serię jednorazowych dostaw, których nie wolno im dotykać. Dopóki tak myślą, relacja pozostaje transakcyjna.
Co się zmienia, gdy klienci zaczynają prosić o komponenty?
W modelu komponentowym jednostką pracy nie jest już strona. Jest nią klocek wielokrotnego użytku. Prośba zmienia się z „zróbcie mi tę stronę” na „zróbcie mi tę funkcję”, a gdy funkcja już istnieje, klient sam składa z niej strony.
Mindset komponentowy widać po pytaniach, które klient zaczyna zadawać. Zamiast „jak będzie wyglądać ta strona” pyta: „jak uniwersalny jest ten komponent i gdzie jeszcze możemy go użyć?”. Każdy nowy Drupal Paragraph ocenia pod kątem potencjału ponownego użytku. W projekcie Edenred po udanym pierwszym zestawie komponentów klient zamówił od sześciu do dziewięciu nowych typów paragrafów i każdy był oceniany według tego samego kryterium: ile kontekstów da się nim obsłużyć?
Gdy klient tak myśli, otwierają się trzy nowe możliwości.
Samodzielne składanie stron. Zespół marketingu układa zupełnie nowe strony z istniejących komponentów, bez angażowania developera. Strona kampanii, która kiedyś zajmowała tygodnie, to teraz popołudnie: wybór paragrafów, uzupełnienie treści, publikacja.
Kreatywne użycie, którego nikt nie planował. To najwyraźniejszy sygnał, że mindset się utrwalił. W Edenred zespół wykorzystał paragrafy prezentacji produktu do promocji webinarów: pole podtytułu jako datę wydarzenia, opis jako szczegóły. Komponenty były na tyle uniwersalne, że kreatywne użycie pojawiło się samo.
Lepsze briefy. Klient myślący komponentami formułuje prośby, które da się realnie wykonać, bo rozumie różnicę między jednorazowym blokiem a typem wielokrotnego użytku. Rozmowa przechodzi od „zróbcie ładnie” do „zróbcie tak, żeby dało się użyć wielokrotnie”.
Przeczytaj też: Drupal Paragraphs: od bezużytecznej konfiguracji do CMS, który wspiera redaktorów oraz szybki sposób na edycję i dostosowanie paragrafu w Drupalu.
Jak przebiega przejście do mindsetu komponentowego?
Mindsetu komponentowego nie da się zainstalować tak jak modułu. Rozwija się etapami, a Twoim zadaniem jest stworzyć warunki dla każdego z nich, a nie wygłaszać klientowi wykładu. W naszej praktyce ta droga zwykle ma cztery fazy.
Faza 1: demonstracja
Budujesz pierwszy zestaw komponentów i pokazujesz, co jest możliwe. To często pierwszy moment, kiedy klient widzi, że może sam zmieniać prawdziwą treść. Celem nie jest omówienie każdej funkcji. Chodzi o jeden moment „wow”, w którym klient rozumie, że witryna jest teraz jego do edycji. Nowoczesny panel administracyjny bardzo tu pomaga; wymiana przestarzałego motywu administracyjnego na aktualny sprawia, że te same możliwości wydają się znacznie bardziej przystępne.
Faza 2: odkrywanie
Klient zaczyna eksplorować i używa komponentów w sposób, którego nikt nie planował. To najważniejsza faza i ta, nad którą masz najmniejszą kontrolę. Daj klientowi środowisko staging z pełną stroną przykładową, która pokazuje każdy komponent i każdy wariant. Zespół Edenred zaczął budować realną treść produkcyjną bez żadnego formalnego szkolenia, czyli ten sam efekt CMS bez szkolenia, do którego dążymy przy każdym przekazaniu projektu. Sztuczka z webinarami narodziła się właśnie tutaj w trakcie swobodnej eksploracji.
Faza 3: internalizacja
Klient zaczyna prosić o komponenty zamiast o strony. Język próśb się zmienia. Zamiast „zróbcie nam stronę na nowy produkt” pada: „potrzebujemy paragrafu, który robi X i da się użyć ponownie”. To ten kamień milowy z początku artykułu. Gdy widzisz to na piśmie, przejście do mindsetu komponentowego się dokonało.
Faza 4: rzecznictwo
Klient myśli o uniwersalności wcześniej niż Ty. Przy briefingu nowego projektu sam pyta, jak wielokrotnego użytku będzie dane rozwiązanie i gdzie jeszcze może się przydać. Zaczyna bronić tego podejścia wewnętrznie i wobec innych. W tym momencie nie jest już konsumentem Twojej pracy tylko współwłaścicielem systemu.
Wspólny wątek wszystkich czterech faz: tworzysz warunki i pozwalasz klientowi odkryć wartość. Staging do eksploracji, komponenty na tyle wszechstronne, żeby zaskakiwały samych twórców i cierpliwość, żeby nie tłumaczyć za dużo. Zmiany nie wymusisz, ale możesz sprawić, że stanie się niemal nieunikniona.
Przeczytaj też: jak uniknęliśmy kosztownej przebudowy Drupala i podnieśliśmy konwersję o ok. 24% oraz moduł Geysir do szybszej edycji paragrafów.
Co ta zmiana oznacza dla relacji z agencją?
Gdy klient przechodzi na mindset komponentowy, Twoja rola się zmienia. I to na Twoją korzyść.
Od dostawcy do twórcy narzędzi. Przestajesz być zespołem, który buduje strony, a stajesz się zespołem, który buduje narzędzia, z których klient sam składa strony. To strukturalnie znacznie lepsza pozycja. Twórców narzędzi trudniej zastąpić niż fabryki stron, bo wartość, którą dostarczasz, kumuluje się na każdej kolejnej stronie klienta.
Praca o wyższej wartości. Zamiast kolejki powtarzalnych ticketów w stylu „zmień ten tekst” zespół skupia się na projektowaniu nowych typów komponentów, ciekawych problemach i rozwoju systemu. Robota robi się ciekawsza dla developerów i bardziej wartościowa dla klienta.
Dłuższe relacje. Klient, który rozumie system, wraca wtedy, gdy jego potrzeby rosną. Nie dlatego, że coś się zepsuło, tylko dlatego, że chce robić więcej. Edenred przeszedł od minimalnego pakietu wsparcia dziewięciu godzin miesięcznie do regularnego zamawiania komponentów i planowania kolejnych faz rozwoju.
Wzrost i polecenia. Klient, który przyjął to podejście, inwestuje więcej w jego rozwój i o tym mówi. Sukces Edenred powtórzył się u innego klienta, który też planował odejście od Drupala; tym razem mogliśmy oprzeć argument na konkretnym case study.
Głębszy wniosek: działający system komponentów nie poprawia tylko witryny. Zmienia relację klienta z technologią, a przy okazji relację klienta z Tobą.
Jak wspierać przejście do mindsetu komponentowego?
Zmiana to coś, co klient odkrywa sam, ale wszystko, co robisz po drodze, wpływa na to, jak prawdopodobne będzie to odkrycie. Oto, co regularnie prowadzi klientów w stronę myślenia komponentami:
Projektuj pod uniwersalność od pierwszego dnia. Buduj komponenty, które działają na wielu typach stron, a nie bloki dopasowane do jednej. Pytanie testowe dla każdego komponentu brzmi: „gdzie można by go użyć, a o czym jeszcze nie myśleliśmy?”. Jeśli odpowiedź brzmi „nigdzie”, przeprojektuj go. Mała biblioteka wszechstronnych komponentów zawsze wygrywa z dużym katalogiem jednorazowych bloków.
Nazywaj komponenty według funkcji, nie miejsca. „Siatka funkcji" albo „wyróżnienie dwukolumnowe", a nie „sekcja 3 strony głównej". Nazwa opisująca miejsce przykuwa komponent do jednej strony, klient dokładnie tak go zapamięta. Nazwa opisująca funkcję działa odwrotnie: sama sugeruje, żeby sięgnąć po niego znowu.
Pokazuj, nie opowiadaj. Przy przekazaniu projektu zademonstruj kreatywne użycie zamiast je opisywać. Pokaż zespołowi, jak paragraf produktowy może wypromować webinar. Gdy zobaczą jedno nieoczekiwane zastosowanie, zaczną wymyślać własne.
Nieoczekiwane użycia. Gdy klient użyje komponentu inaczej niż planowałeś, traktuj to jak sukces, a nie odstępstwo od instrukcji. Taka reakcja wzmacnia dokładnie to zachowanie, którego chcesz i wysyła klientowi jasny sygnał: system należy do Ciebie, wolno Ci eksperymentować.
Nie opisuj wszystkiego z góry. Zostaw miejsce na kreatywną interpretację. Komponent z jednym poprawnym zastosowaniem uczy klienta czekać na instrukcje. Komponent z rozsądną elastycznością zachęca do eksploracji. To samo obowiązuje przy przekazaniu projektu: dobra strona na stagingu robi więcej niż dwugodzinne szkolenie.
Chcesz, żeby Twoi klienci myśleli komponentami?
Ten artykuł opiera się na naszej realnej pracy produkcyjnej dla Edenred Polska, gdzie poprawnie wdrożony, oparty na paragrafach system Drupal zamienił klienta gotowego porzucić platformę w kogoś, kto aktywnie zamawia nowe komponenty i sam buduje strony. Przejście od próśb o strony do próśb o komponenty było prawdziwym miernikiem sukcesu, obok wzrostu konwersji o ok. 24% na pierwszej przebudowanej stronie.
Jeśli Twoi klienci nadal są od Ciebie zależni przy każdej stronie, problem może leżeć w modelu, a nie w relacji. Nasz zespół specjalizuje się w budowaniu uniwersalnych, wielokrotnego użytku komponentów Drupal i doświadczenia redakcyjnego, które pozwala klientom pracować samodzielnie. Zajrzyj do naszych usług Drupal i przekonaj się, jak podejście oparte na komponentach zmienia to, co klienci mogą zrobić sami.
