Strona pokazywała umiejętności, ale nie ułatwiała decyzji
Pierwsza wersja mojego portfolio robiła to, co robi wiele stron technicznych: wymieniała narzędzia, pokazywała projekty i kończyła się formularzem. Osoba z branży mogła ocenić, czy znam konkretną technologię. Przedsiębiorca nadal nie wiedział, czy przejmę niedokończony system, czy powiem wprost, że pomysł nie ma sensu, i jak wygląda pierwszy krok współpracy.
Problem nie dotyczył wyglądu. Dotyczył kolejności informacji.
Od czego zacząłem przebudowę
Zamiast pytać „co potrafię?”, rozpisałem pytania, z którymi klient wchodzi na stronę:
- czy ta osoba rozumie sytuację podobną do mojej,
- czy potrafi naprawić coś po poprzednim wykonawcy,
- czy zajmie się całością bez przekazywania mnie między ludźmi,
- czy powie, że projektu nie warto robić,
- co muszę przygotować przed pierwszym kontaktem,
- skąd mam wiedzieć, że wynik nie jest tylko obietnicą.
Te pytania wyznaczyły nowy układ strony.
Najpierw obietnica, później dowody
Pierwszy ekran ma powiedzieć jednym zdaniem, czym się zajmuję: naprawiam i buduję systemy, dzięki którym firma pracuje sprawniej. Nie próbuję w tym miejscu streszczać całej oferty.
Niżej pokazuję sytuacje, w których najczęściej pomagam: porzucony system, ręczna praca w biurze, nieudana próba z AI, błędy przy rezerwacjach lub pieniądzach. Dopiero potem pojawiają się konkretne wdrożenia.
Technologie nadal są na stronie, ale pełnią inną rolę. To dowód zaplecza dla osoby, która chce je sprawdzić, nie główny język rozmowy z właścicielem firmy.
Realizacje muszą odpowiadać na trzy pytania
Każdy opis wdrożenia zaczyna się od:
- Co działo się w firmie?
- Jaką decyzję podjąłem i dlaczego?
- Co zmieniło się po wdrożeniu?
Dopiero druga warstwa wyjaśnia sposób wykonania. Dzięki temu osoba nietechniczna może zrozumieć wynik, a specjalista nadal ma możliwość sprawdzenia warsztatu.
Liczby zostają tylko wtedy, gdy mają źródło i kontekst. „21 zmian” ma sens, jeśli tyle punktów zawierała umowa i wszystkie zostały dostarczone. „14 minut” ma sens, jeśli to zmierzony czas przełączenia działającego systemu. Sama duża liczba bez punktu odniesienia nie buduje wiarygodności.
Dwie drogi kontaktu
Nie każdy chce od razu umawiać rozmowę. Nie każdy potrafi też napisać pełny opis sprawy. Dlatego strona daje dwa równorzędne wejścia:
- bezpośrednią wiadomość dla osoby, która wie, czego potrzebuje,
- rozmowę z asystentem, który zadaje jedno pytanie naraz i porządkuje materiał.
Asystent nie wycenia projektu i nie zastępuje mnie. Po rozmowie dostaję opis problemu, obecnego sposobu pracy, używanych systemów i oczekiwanego wyniku. Na tej podstawie mogę zdecydować, czy wystarczy krótka wycena, potrzebna jest rozmowa, płatny audyt albo mała wersja pokazowa.
Co usunąłem po drodze
Jedna z wcześniejszych wersji strony miała płatną konsultację prowadzoną przez AI. Technicznie działała, ale mieszała role: klient mógł zapłacić za analizę, której osobiście jeszcze nie widziałem. Usunąłem ją.
Zniknęła też stała obietnica odpowiedzi w 48 godzin. Przy dobrze opisanym, małym zadaniu wycenę można przygotować szybciej. Przy dostępie do cudzego kodu, danych albo umów uczciwa ocena wymaga więcej czasu. Jedna liczba udawała precyzję, której nie da się zachować dla każdej sprawy.
Podobnie potraktowałem przypadkowe liczniki, angielskie nazwy procesów i zdania napisane głównie dla innych programistów. Strona ma mówić językiem klienta, nie narzędzi wykonawcy.
Osiem dni i 58 zapisanych zmian — co te liczby właściwie mówią
Pierwszy duży etap budowy zajął osiem dni i pozostawił 58 zapisanych zmian w historii projektu. Te liczby nie są obietnicą tempa dla klienta. Pokazują coś innego: strona nie powstała jako jeden idealny projekt. Była publikowana, sprawdzana i poprawiana małymi krokami.
Od tamtej pory zmieniła się ponownie — między innymi dlatego ten artykuł ma datę aktualizacji. Opisywanie własnego procesu nie ma sensu, jeśli tekst nadal reklamuje funkcję, której już nie ma.
Cztery wnioski
Strona usługowa ma pomagać podjąć decyzję
Ładny wygląd i lista umiejętności są potrzebne, ale klient przychodzi po odpowiedź: „czy ta osoba poradzi sobie z moją sytuacją?”. Układ i tekst powinny prowadzić właśnie do niej.
Język techniczny warto przesunąć niżej
Nie trzeba go usuwać całkowicie. Wystarczy najpierw wyjaśnić skutek dla firmy, a dopiero później sposób wykonania.
Automatyzacja powinna wspierać kontakt, nie go udawać
Asystent może zebrać informacje o dowolnej porze. Ocena sensu projektu, ryzyka i ceny pozostaje po stronie osoby, która będzie odpowiadała za wdrożenie.
Usunięcie funkcji bywa rozwojem
Płatna rozmowa z AI była bardziej złożona niż obecny proces. Jej usunięcie uprościło decyzję klienta i lepiej pasuje do obietnicy bezpośredniej współpracy.