Nieedytowalna strona Drupal: jak uniknęliśmy kosztownej przebudowy i podnieśliśmy konwersję o ok. 24%

Zanim zdecydujesz się na kosztowną przebudowę strony, warto zadać jedno pytanie: czy problem leży w platformie - czy może w tym, że nigdy nie skonfigurowano jej tak, by robiła to, do czego jest zdolna?

Nieedytowalna strona Drupal - strona, na której zespół marketingu nie może samodzielnie zmienić tekstu, obrazów ani układu bez zgłoszenia do developera - to jeden z najczęstszych powodów, dla których firmy decydują się na budowę witryny od zera. To historia międzynarodowej firmy z branży benefitów, która niemal poszłaby tą drogą i popełniła kosztowny błąd.

Firma przyszła do nas z jasnym komunikatem: „Chcemy przebudować stronę od podstaw. Na innej platformie”.

Ich argumentacja była trudna do obalenia. Zespół marketingu nie mógł edytować nawet podstawowego tekstu na stronie. Każda zmiana - bez względu na to, jak mała - wymagała zgłoszenia do developera. Zespół uciekł się do wgrywania statycznych obrazów zamiast edytowalnych treści, bo to jedyny sposób, by cokolwiek zaktualizować bez czekania kilku dni. Efekt? Strona, która wyglądała coraz bardziej przestarzale, nie była responsywna na urządzeniach mobilnych i słabo wypadała w wyszukiwarkach.

Przygotowali już RFP na zupełnie nową stronę. Drupal - platforma, na której witryna została zbudowana - nie figurował nawet w liście technologii do rozważenia. Z perspektywy klienta Drupal był problemem.

My spojrzeliśmy na stronę inaczej. Problemem nie był Drupal. Problemem było to, jak Drupal został wdrożony. Naprawa implementacji kosztowałaby ułamek tego, co wymagałaby pełnej przebudowy.

To historia o tym, jak przekonaliśmy sfrustrowanego klienta korporacyjnego, by nie popełnił drogiego błędu - i jak zamieniliśmy istniejący CMS w narzędzie, w które firma dziś aktywnie inwestuje.

W tym artykule:

• Dlaczego Twoja strona Drupal wydaje się nieedytowalna?
• Przebudowa czy modernizacja nieedytowalnej strony Drupal?
• Jak zmodernizować stronę Drupal zamiast ją przebudowywać?
• Jakie były rezultaty?
• Czy Twoja strona Drupal jest nieedytowalna? Jak to rozpoznać?
• Wnioski

Dlaczego Twoja strona Drupal wydaje się nieedytowalna?

Strona klienta działała na Drupalu - technologii narzuconej przez globalną centralę. Formalnie miała zainstalowany moduł Drupal Paragraphs - jedną z najpotężniejszych funkcji zarządzania treścią w ekosystemie Drupal. Ale „zainstalowany” i „poprawnie skonfigurowany” to dwie różne rzeczy.

W praktyce moduł Paragraphs był obecny w kodzie, lecz nigdy nie został podłączony tak, jak trzeba. Redaktorzy nie mieli sensownego sposobu na tworzenie i edycję treści stron przez CMS. Panel administracyjny ich nie prowadził. Typy paragrafów istniały w bazie danych, ale nie były połączone z procesem edycji w użyteczny sposób. To klasyczny objaw nieedytowalnej strony Drupal: narzędzia są, ale redaktorzy nie mają do nich dostępu.

Zespół marketingu zrobił więc to, co robi każdy pomysłowy zespół: znalazł obejście. Zamiast walczyć z CMS-em, zaczął wgrywać obrazy - zrzuty ekranu z tekstem, grafiki z informacjami o produktach, mockupy zapisane jako JPEG i wstawiane na stronę. To wzorzec, który widzimy często, a koszty SEO i dostępności rosną szybko.

Działało - jakoś. Treść się aktualizowała. Skutki uboczne były jednak poważne:

• Brak responsywności. Obrazy nie dopasowują się do różnych rozmiarów ekranu. Strona źle wyglądała na urządzeniach mobilnych i nie spełniała podstawowych wymagań dostępności.
• Problem z SEO. Wyszukiwarki nie indeksują tekstu w obrazach, dlatego strukturalna, edytowalna treść ma znaczenie dla SEO. Strona stawała się niewidoczna.
• Słaba wydajność. Ciężkie pliki graficzne spowalniały ładowanie.
• Całkowita sztywność. Zmiana jednego słowa oznaczała tworzenie grafiki od nowa.

Z perspektywy klienta firma miała CMS, który nie pozwalał zarządzać treścią. Logicznym wnioskiem było, że potrzebuje innego systemu. Zaczęli szukać opcji na zupełnie nową stronę na zupełnie nowej platformie.

Przeczytaj też: dlaczego strona Drupal wydaje się zepsuta, choć platforma jest w porządku oraz jak wygląda modernizacja systemu legacy, gdy problem leży we wdrożeniu.

Przebudowa czy modernizacja nieedytowalnej strony Drupal?

Gdy przeanalizowaliśmy sytuację, widzieliśmy dwie ścieżki o bardzo różnych kosztach, harmonogramach i ryzyku.

Plan klienta to ścieżka A: pełna przebudowa na nowej platformie - 6-18 miesięcy pracy, spory budżet, ryzyko nowego dostawcy i stosu technologicznego oraz niemal pewna utrata wartości SEO i ciągłości adresów URL, bez gwarancji, że nowa witryna będzie skonfigurowana lepiej niż stara.

Zaproponowaliśmy ścieżkę B: naprawić to, co już jest. Instalacja Drupala działała, rdzeń technologii był aktualny i aktywnie rozwijany. Problem leżał wyłącznie w warstwie implementacji - konkretnie w tym, jak system Paragraphs został (nie) skonfigurowany. Utrzymanie istniejącej instalacji i poprawne wdrożenie uniwersalnych komponentów wielokrotnego użytku kosztowałoby ułamek przebudowy, a efektem byłaby nowoczesna, edytowalna, responsywna strona dzięki modernizacji Drupal, a nie replatformingowi.

Nasz klient to typowy przypadek modernizacji: platforma potrafiła wszystko, czego potrzebowali; po prostu nigdy nie dano jej szansy. Pełnej logiki decyzyjnej (przebudowa kontra modernizacja) nie powtarzamy tutaj - rozbicie kosztów, wąskie przypadki, w których przebudowa ma sens, i etapowy framework do zastosowania u siebie opisujemy w osobnym przewodniku o etapowej modernizacji CMS.

Jak zmodernizować stronę Drupal zamiast ją przebudowywać?

Nie proponowaliśmy wielomiesięcznego projektu. Proponowaliśmy skupione, etapowe podejście, które szybko daje widoczne efekty i na tym buduje dalszą pracę.

Krok 1: zrozumieć realne potrzeby

Zanim otworzyliśmy jakiekolwiek narzędzie projektowe, usiedliśmy z zespołem marketingu do serii spotkań discovery. Bez designerów, bez wireframe'ów - tylko rozmowy o tym, co naprawdę muszą robić na stronie i co im w tym przeszkadza.

Wniosek był jasny: w sesjach discovery redaktorzy mówili, że zdecydowana większość frustracji wynikała z braku możliwości edycji treści. Nie potrzebowali nowych funkcji. Nie potrzebowali innej architektury. Potrzebowali możliwości aktualizacji tekstu, podmiany obrazów, zmiany układu sekcji i tworzenia nowych landing page'ów - rzeczy, które każdy poprawnie skonfigurowany CMS powinien obsłużyć od razu.

Krok 2: zaprojektować uniwersalne komponenty

Na podstawie tych rozmów zespół projektowy stworzył zestaw komponentów paragrafowych - nie layoutów stron, lecz klocków wielokrotnego użytku. Każdy komponent zaprojektowano w 3-4 wariantach kolorystycznych, żeby marketing mógł wybierać jasne tło, ciemne tło, kolory marki albo neutralną stylistykę w zależności od kontekstu.

Każdy komponent dostał osobny layout na urządzeniach mobilnych. Nie „pomniejszoną wersję desktopu” - osobno zaprojektowane doświadczenie na mniejszych ekranach.

Kluczowa zasada projektowa: uniwersalność. Każdy komponent miał działać na stronach produktowych, landing page'ach, ogłoszeniach eventów i w kontekstach, o których jeszcze nie myśleliśmy.

Krok 3: zbudować to porządnie

Prace developerskie były proste, gdy design był gotowy. Poprawnie wdrożyliśmy Drupal Paragraphs - każda sekcja każdej strony stała się niezależnym, edytowalnym komponentem, który redaktorzy mogą dodawać, usuwać, zmieniać kolejność i konfigurować. Pełne omówienie tego, co odróżnia zepsutą konfigurację Paragraphs od przyjaznej redaktorom, znajdziesz w naszym artykule o prawidłowym wdrożeniu Drupal Paragraphs.

Zastąpiliśmy treści oparte na obrazach prawdziwym, edytowalnym tekstem - z poprawną strukturą nagłówków (H1, H2, H3) pod SEO. Zmodernizowaliśmy panel administracyjny motywem Gin, żeby redaktorzy mieli współczesny, intuicyjny interfejs zamiast przestarzałego domyślnego wyglądu.

Przeczytaj też: szybki sposób na edycję i dostosowanie paragrafu w Drupalu oraz moduł Geysir do szybszej edycji paragrafów.

Krok 4: przekazać bez szkolenia

Zamiast planować formalne szkolenie, zbudowaliśmy na stagingu kompletną stronę przykładową z każdym dostępnym typem i wariantem paragrafu. Zespół marketingu eksplorował ją we własnym tempie, klikał opcje i eksperymentował z treścią.

Gdy przeszli na produkcję, zaczęli samodzielnie tworzyć strony. Bez instrukcji. Bez warsztatu. System był na tyle intuicyjny, że nauczyli się go przez działanie - dokładnie tak, jak powinien działać CMS. Etapowe przekazanie przez staging bez szkolenia opisujemy w osobnym przewodniku.

Jakie były rezultaty?

Efekt było widać na dwóch poziomach: mierzalne liczby biznesowe w krótkim terminie oraz głębsza zmiana w tym, jak klient pracuje z własną platformą.

Jaki był bezpośredni wpływ biznesowy?

Pierwszą stroną, którą przebudowaliśmy, był landing page kart podarunkowych - uruchomiony tuż przed sezonem świątecznym, kluczowym okresem dla klienta. Rezultat: około 24% wzrost współczynnika konwersji w porównaniu ze starą wersją opartą na obrazach.

Redaktorzy zaczęli samodzielnie tworzyć nowe landing page'y. Budowali strony pod nowe produkty, promocje webinarów i ogłoszenia eventów - bez jednego zgłoszenia do developera. Zamówili 6-9 nowych typów paragrafów, żeby rozszerzyć swój zestaw narzędzi.

Co zmieniło się poza liczbami?

Poza liczbami wydarzyło się coś ważniejszego. Klient przestał prosić o „strony”, a zaczął prosić o „komponenty”. Oceniał nowe projekty paragrafów pod kątem uniwersalności i możliwości ponownego użycia. Zaczął myśleć jak projektant systemu - nie dlatego, że go tego uczyliśmy, lecz dlatego, że podejście oparte na komponentach naturalnie to ułatwiało. Jak ta zmiana wygląda w praktyce, opisujemy w przewodniku o uczeniu klientów myślenia komponentami.

Zespół marketingu odkrył, że paragrafy zaprojektowane pod prezentacje produktów świetnie sprawdzają się przy ogłoszeniach webinarów. Pola przeznaczone pod opisy produktów wykorzystywali pod daty i szczegóły eventów. System był używany kreatywnie, w sposób, którego nie planowaliśmy - niezawodny znak, że architektura działa.

Dlaczego odzyskanie zaufania było największym sukcesem?

Klient przeszedł od planu całkowitego porzucenia Drupal do aktywnej inwestycji w platformę. Wierzy w tę technologię - nie przez argumentację sprzedażową, lecz dlatego, że zaczęła przynosić realne wyniki biznesowe. Ta zmiana zaufania jest warta więcej niż pojedyncza metryka konwersji.

Podejście powtórzyliśmy później u innego klienta w niemal identycznej sytuacji - gotowego do odejścia od Drupala, sfrustrowanego niefunkcjonalnym CMS-em, przygotowującego RFP na nową platformę. To sprawdzone case study znacznie ułatwiło rozmowę.

Czy Twoja strona Drupal jest nieedytowalna? Jak to rozpoznać?

Jeśli którykolwiek z poniższych punktów brzmi znajomo, Twoja nieedytowalna strona Drupal może kwalifikować się do modernizacji zamiast przebudowy:

Czerwone flagi sugerujące problem wdrożenia, a nie platformy:

• CMS ma funkcje, z których zespół nie potrafi korzystać
• Redaktorzy unikają CMS i stosują obejścia (wgrywanie obrazów, maile do developerów ze zmianami)
• Strona wygląda przestarzale, ale technologia pod spodem jest aktualna
• Ktoś powiedział „w naszym CMS nie da się tego zrobić” bez szczegółowego wyjaśnienia technicznego
• Istnieje szkic RFP na nową stronę, który nie wspomina obecnej platformy

Pięć pytań, zanim zdecydujesz się na przebudowę:

1. Czy ktoś z ekspertyzą platformy audytował, czy funkcje obecnego CMS są poprawnie skonfigurowane?
2. Czy specjalista potrafi pokazać, na co naprawdę stać CMS po prawidłowym ustawieniu?
3. Ile kosztowałaby naprawa implementacji w porównaniu z budową od zera?
4. Ile treści, wartości SEO i wiedzy instytucjonalnej straciłbyś przy migracji platformy?
5. Czy zespół jest sfrustrowany samą platformą, czy doświadczeniem korzystania z niej?

Jeśli choć dwa z tych pytań Cię zatrzymują, warto uzyskać drugą opinię, zanim podpiszesz umowę na przebudowę.

Wnioski

Przebudowa strony od zera czasem jest właściwym wyborem. Ale tak jest znacznie rzadziej, niż zakłada większość osób. W wielu przypadkach - zwłaszcza z dojrzałymi platformami jak Drupal - technologia w pełni nadąża za potrzebami biznesu. Gdy masz nieedytowalną stronę Drupal, luka prawie zawsze leży we wdrożeniu, nie w platformie.

Najtańszy, najszybszy i najmniej ryzykowny projekt strony to ten, którego nie musisz zaczynać od zera. Zanim podpiszesz umowę na przebudowę, zainwestuj w zrozumienie, na co naprawdę stać obecną platformę. Możliwe, że od witryny, o którą prosi zespół, dzieli Cię jedno porządne wdrożenie.

Myślisz o przebudowie? Najpierw uzyskaj drugą opinię

Ten case study opiera się na realnym projekcie produkcyjnym dla międzynarodowej firmy z branży benefitów, w którym zmodernizowaliśmy istniejącą stronę Drupal zamiast przebudowywać ją od podstaw. Efekt: edytowalna, responsywna platforma oparta na komponentach, około 24% wzrost konwersji na pierwszej przebudowanej stronie oraz klient, który dziś aktywnie inwestuje w rozbudowę systemu. Strona działa na produkcji od wielu miesięcy.

Zastanawiasz się, czy Twoja witryna potrzebuje pełnej przebudowy, czy tylko mądrzejszego wdrożenia? Nasz zespół specjalizuje się w maksymalnym wykorzystaniu istniejących platform Drupal - od poprawnie skonfigurowanych Paragraphs po przyjazny redaktorom panel administracyjny. Zobacz nasze usługi Drupal, żeby sprawdzić, na co naprawdę stać Twoją obecną platformę.