Prawdziwym efektem wdrożenia opartego na paragrafach nie są paragrafy. To moment, w którym klient przestaje prosić o „nową stronę”, a zaczyna prosić o „nowy komponent”.
W każdym udanym projekcie CMS jest cichy 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 pada: „potrzebujemy typu paragrafu z funkcjami w dwóch kolumnach i musi dać się go użyć gdzie indziej”. Ta prośba to sukces. Oznacza, że klient przyjął mindset komponentowy - nawyk myślenia klockami wielokrotnego użytku zamiast jednorazowych stron - i patrzy na witrynę tak jak Ty.
Ta zmiana jest warta więcej niż jakakolwiek pojedyncza funkcja. Klient myślący stronami zależy od Ciebie przy każdej poprawce. Klient myślący komponentami sam składa strony, zadaje lepsze pytania i wraca, by rozwijać system, a nie go naprawiać. Dla project managerów i account managerów wspieranie tej zmiany jest jedną z najskuteczniejszych rzeczy, jakie możesz 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 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ć, by stworzyć warunki do tej zmiany.
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.” „Czy możecie zrobić stronę na kampanię wiosenną?” Każda prośba uruchamia ten sam cykl: nowy design, nowe zadanie developerskie, nowa pozycja w budżecie i dni lub tygodnie oczekiwania na publikację.
Ten model ma trzy problemy strukturalne - i żaden z nich nie jest winą klienta.
Całkowita zależność. Klient bez agencji nie może zrobić nic. Aktualizacja numeru telefonu, podmiana obrazu hero czy zmiana kolejności dwóch sekcji 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 było wolniejsze niż otwarcie narzędzia do projektowania graficznego. To nie leniwy zespół. To zespół uwięziony w systemie opartym na stronach - ten sam wzorzec 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 rynku.
Cykl frustracji, który niszczy zaufanie. Klient czeka, agencja buduje, klient chce zmian i pętla się powtarza. Każdy obrót kosztuje czas i dobrą wolę. Wystarczająco długo i klient uznaje, że problem leży 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 vs. przebudowa staje się decyzją zarządu.
Model oparty na stronach uczy klientów traktować witrynę jako serię jednorazowych dostaw, których nie mogą dotknąć. Dopóki tak myślą, relacja pozostaje transakcyjna i krucha.
Co się zmienia, gdy klienci zaczynają prosić o komponenty?
W modelu komponentowym jednostką pracy nie jest już strona. Jednostką pracy staje się klocek wielokrotnego użytku. Prośba zmienia się z „zróbcie mi tę stronę” na „zróbcie mi tę funkcję” - a gdy funkcja istnieje, klient sam składa z niej strony.
Mindset komponentowy widać w 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 oceniał każdy dokładnie według tego kryterium: ile kontekstów może obsłużyć?
Trzy rzeczy stają się możliwe, gdy klient tak myśli.
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 popołudnie spędzone na wyborze paragrafów, uzupełnieniu treści i publikacji.
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 data wydarzenia, opis jako szczegóły. Nikt o to nie prosił. Komponenty były wystarczająco uniwersalne, by kreatywne użycie pojawiło się samo.
Lepsze briefy. Klient myślący komponentami formułuje prośby, które da się realnie zrealizować, bo rozumie różnicę między jednorazowym blokiem a typem wielokrotnego użytku. Rozmowa przechodzi od „zróbcie ładnie” do „zróbcie to wszechstronnie”.
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 instaluje się tak jak moduł. Rozwija się etapami, a Twoim zadaniem jest stworzenie warunków dla każdego etapu, a nie wykład dla klienta. W projektach ta progresja zwykle ma cztery fazy.
Faza 1: demonstracja
Budujesz pierwszy zestaw komponentów i pokazujesz, co jest możliwe. To często pierwszy moment, w którym 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. Nowoczesne doświadczenie w panelu administracyjnym bardzo 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ą wykorzystującą każdy komponent i każdy wariant, a potem cofnij się. Zespół ds. treści w Edenred dostał dokładnie to i zaczął budować realną treść produkcyjną bez formalnego szkolenia - 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 tu, podczas swobodnej eksploracji.
Faza 3: internalizacja
Klient zaczyna prosić o komponenty zamiast o strony. Zmienia się język próśb. Zamiast „zróbcie nam stronę na nowy produkt” pada: „potrzebujemy paragrafu, który robi X i da się go użyć ponownie”. To kamień milowy z początku artykułu. Gdy widzisz to na piśmie, przejście do mindsetu komponentowego nastąpiło.
Faza 4: rzecznictwo
Klient myśli o uniwersalności wcześniej niż Ty. Przy briefingu nowego projektu pyta, jak bardzo będzie wielokrotnego użytku i gdzie jeszcze może się przydać. Zaczyna bronić podejścia wewnętrznie i wobec innych. W tym momencie klient nie jest już konsumentem Twojej pracy; jest 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, by zaskakiwać twórców, i cierpliwość, by 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 - na Twoją korzyść.
Od dostawcy do twórcy narzędzi. Przestajesz być zespołem budującym strony, a stajesz się zespołem budującym narzędzia, z których klient składa strony. To strukturalnie lepsza pozycja. Twórców narzędzi trudniej zastąpić niż fabryki stron, bo wartość, którą dostarczasz, kumuluje się na każdej stronie klienta.
Praca o wyższej wartości. Zamiast kolejki powtarzalnych ticketów „zmień ten tekst” zespół skupia się na projektowaniu nowych typów komponentów, ciekawych problemach i rozwijaniu systemu. Praca jest ciekawsza dla developerów i bardziej wartościowa dla klienta.
Dłuższe relacje. Klient, który rozumie system, wraca, gdy jego potrzeby rosną - nie dlatego, że coś się zepsuło, lecz dlatego, że chce robić więcej. Edenred przeszła od minimalnego miesięcznego pakietu wsparcia dziewięciu godzin do regularnego zamawiania komponentów i planowania kolejnych faz rozwoju.
Wzrost konta i polecenia. Klient, który przyjął to podejście, inwestuje więcej w rozwój tego podejścia 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. Wzmocniony klient staje się referencją i źródłem nowego biznesu.
Głębszy wniosek: działający system komponentów nie poprawia tylko witryny. Zmienia relację klienta z technologią - i relację klienta z Tobą.
Jak wspierać przejście do mindsetu komponentowego?
Zmiana to coś, co klient odkrywa - ale wszystko, co robisz, 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 działające na wielu typach stron, a nie bloki dopasowane do jednej strony. Pytanie testowe dla każdego komponentu brzmi: „jak można by go użyć w kontekście, o którym 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”. Nazwy opisujące lokalizację zamykają komponent w jednej stronie w głowie klienta. Nazwy opisujące funkcję zapraszają do ponownego użycia.
Pokazuj, nie tylko opowiadaj. Przy przekazaniu projektu zademonstruj kreatywne użycie zamiast je opisywać. Pokaż zespołowi, jak paragraf produktowy może promować webinar. Gdy zobaczą jedno nieoczekiwane zastosowanie, zaczną wymyślać własne.
Świętuj nieoczekiwane użycia. Gdy klient użyje komponentu inaczej niż planowano, traktuj to jako sukces, nie odstępstwo. Ta reakcja wzmacnia dokładnie zachowanie, którego chcesz, i sygnalizuje, że system należy do niego i może eksperymentować.
Nie przespecyfikowuj. Zostaw miejsce na kreatywną interpretację. Komponent z jednym poprawnym użyciem uczy klienta czekać na instrukcje. Komponent z rozsądną elastycznością zachęca do eksploracji. Ta sama rezerwa przy przekazaniu projektu: dobra strona przykładowa na stagingu robi więcej niż dwugodzinne szkolenie.
Chcesz, by 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 do porzucenia platformy 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 od Ciebie zależą przy każdej stronie, problem może leżeć w modelu, a nie w relacji. Nasz zespół specjalizuje się w budowaniu uniwersalnych komponentów Drupal wielokrotnego użytku i doświadczenia redakcyjnego, które pozwala klientom pracować samodzielnie. Zobacz nasze usługi Drupal, by dowiedzieć się, jak podejście oparte na komponentach zmienia to, co klienci mogą zrobić sami.
