W poprzednich artykułach dotyczących procesu tworzenia portalu internetowego przybliżyłem kilka początkowych etapów przygotowania i projektu oraz nasz sposób realizowania planu projektowego. Niektórym wydawałoby się, że portal jest już gotowy – zbudowany na podstawie analiz rynku i grupy docelowej, zaprojektowany pod względem funkcjonalności i treści, zakodowany oraz ubrany w grafikę i animacje. Ale to jeszcze nie wszystko. Dziś przedstawię jeszcze kilka niezwykle istotnych etapów.
Etap VIII – rwd
RWD czyli responsywność – dostosowanie portalu do wyświetlania w różnych formatach, nie tylko na monitorach komputerów, ale także tabletów i smartfonów.
Celowo nie poruszałem tego etapu wcześniej, jednak musimy zdawać sobie sprawę, że jeśli chcemy mieć dobrze przygotowane wersje portalu musimy to przewidzieć na etapach IV-VII, bo to wyraźnie odbije się na naszym kosztorysie. Część inwestorów rozwiązuje to tworząc portal tylko na komputery stacjonarne i udostępniając osobno stworzoną do pobrania aplikację mobilną, na przykład booking.com.
Etap IX – SEO
Prawdopodobnie minimum 50% twojego ruchu w portalu będzie pochodziło z wyszukiwarki Google, dlatego koniecznością jest stworzenie serwisu, który będzie w 100% przyjazny dla Google. Działamy zgodnie z wytycznymi Google dla webmasterów tak, aby już na starcie portal był wypozycjonowany wyżej w wynikach wyszukiwania.
Etap X – Beta testy
Źle podpięte linki, brakujące treści, które Klient miał dostarczyć od prawnika (np. regulaminy), niedziałające podstrony – to częste sytuacje po przepięciu strony z adresu serwerowego na docelowy adres portalu. Zanim pokażemy nasz portal światu zadbajmy o to, aby był przetestowany przez użytkowników testowych, aby wszelkie drobne błędy zostały poprawione.
Wtedy zwiększamy prawdopodobieństwo, że będzie spełniał swoje cele sprzedażowe – użytkownicy nie opuszczą portalu z powodu problemów z poruszaniem się wewnątrz i znalezieniem celu, ale dokonają konwersji (kupna, zapisu do formularza itp.)
ETAP XI – Maintenance and Cyclic Upgrade
Mało kto bierze pod uwagę, że koniec projektu i jego uruchomienie to nie koniec kosztów. Wręcz zaczynamy dopiero realnie z użytkownikami nad nim pracować.
Aby projekt mógł się rozwijać, potrzeba ludzi którzy będą nad nim czuwać. Standardowy tryb reklamacyjny to 14 dni ale w IT to nie może tak działać, ponieważ często trzeba reagować natychmiast dlatego firmy podpisują tz Maitenance aby programiści mogli podejmować prace od razu nie analizując czy to problem z serwerem, aplikacją, błąd w oprogramowaniu czy jeszcze inny czynnik zewnętrzny. Trzeba działać natychmiast jednak z tym wiążą się koszty utrzymania zespołu w projekcie który takie prace może podjąć.
Osobną kwestią jest praca i analiza tego co robią użytkownicy. W wielu z naszych projektów nagrywamy i przeglądamy wszystkie sesje użytkowników, aby sprawdzić które działania można zoptymalizować i zrobić jeszcze bardziej intuicyjnie. To całkowicie normalny etap projektowy. Musimy do tego podejść jak to sytuacji w której oddaliśmy dobrze opracowany prototyp i sprawdzamy jakie usprawnienia należy do niego wprowadzić aby jeszcze lepiej realizował potrzeby użytkowników. To nigdy nie jest tak, że oddajemy projekt podpinając go pod domenę i to koniec współpracy. W naszym budżecie projektowym musimy założyć, że po prostu wchodzimy w kolejny etap rozwoju projektu i on również wymaga zespołu projektowego, który pracuje nad produktem.
Case Study
Nasz klient z branży druku 3D zatrudnił dwóch grafików oraz trzech programistów do stworzenia portalu internetowego. Projekt okazał się pochłonąć 70.000 zł i powstał kompletnie nieintuicyjny bubel. Dlaczego tak się stało? Ponieważ nie było specjalisty od stworzenia koncepcji i modelu biznesowego, nie było kompetentnego managera projektu, nie było nawet dokumentacji, z której można rozliczyć zespół projektowy. Nie było człowieka po stronie właściciela, który dbałby o jego interesy i audytował projekt. Funkcjonalności nie działały, część z nich została nawet celowo ukryta przez programistów, aby ich nie naprawiać.
Próbowaliśmy ratować ten projekt. Powstała na naszą prośbę pełna dokumentacja projektowa – miała ponad 200 stron. Spisaliśmy funkcje, zgłosiliśmy ponad 100 uwag tylko do kodu i funkcji. Klient zrozumiał, że błędy projektowe wynikają z zaniechania procesu UX, archaicznego projektu graficznego oraz braku zaplanowania wersji mobilnych. Sam model biznesowy, czyli fundament działań był nieprawidłowo przemyślany i Klient za naszą radą odpuścił dalsze inwestowanie w reanimowanie martwego projektu, który i tak nie miał się prawa udać.
Pomagaliśmy naszym klientom ratować wiele nieudanych projektów i wiemy, że to nie ma sensu. Nie raz najlepszym rozwiązaniem jest fundamentalna zmiana i rozpoczęcie projektu od początku.
Jesteśmy partnerem dla firm, które mają świadomość tego, że efektywny, zarabiający projekt to nie jest praca na szybko i za małe pieniądze. Szukamy poważnych partnerów, którzy:
a) mają doświadczenie i tworzą kolejny projekt;
b) nie mają doświadczania, ale chcą dać się w tym procesie poprowadzić.
Nie jesteśmy w stanie pomóc klientom, którzy forsują podejście, że dokumentacja nie jest potrzebna lub na podstawie dość skromnych wytycznych oczekują wyceny, aby porównać to z innymi agencjami. Takie podejście powoduje, że wyceny mogą różnić się diametralnie – te różnice nie wynikają z chęci oszustwa i sztucznego zawyżania cen, ale pokazują jakość i zakres wykonywanych usług. Jedni chcą budować Fiata Pandę z gotowych części, inni Mercedesa CLS nastawionego na niezawodność. My chętnie budujemy mercedesy według konkretnych standardów, ewentualnie Toyoty, które też słyną z niezawodności;) Nie oznacza to, że nie zbudujemy dla kogoś Fiata, jeśli takie są Twoje potrzeby. Należy jednak pamiętać, że jeśli marzy Ci się Mercedes, musisz być przygotowany na inwestycję dostosowaną do tej marki – za wartość Fiata, Mercedesa nie otrzymasz.
