Kiedy siadałem do budowy mojej pierwszej strony internetowej, ekscytacja była autentyczna. Zakładałem, że najtrudniejsze będzie nauka kodowania – zapamiętywanie tagów, rozumienie funkcji, pilnowanie składni. Myliłem się. Pisanie kodu okazało się najłatwiejszą częścią. Prawdziwym wyzwaniem było przekształcenie tych linii w coś, czego ludzie mogliby używać bez konfuzji czy frustracji. Ten pierwszy projekt nauczył mnie, że development to mniej pisanie w izolacji, a bardziej rozwiązywanie problemów ludzi, których nie obchodzi twój stack technologiczny. Popełniłem błędy, które kosztowały mnie czas, sen i pierwszych użytkowników. Pięć z nich szczególnie zapadło mi w pamięć.
Dążenie do perfekcji przed publikacją
Wpadłem w pułapkę perfekcjonizmu na długo przed tym, zanim zasłużyłem na miano kogoś, kto tworzy rzeczy idealne. Spędzałem całe popołudnia na zmianie kodów hex o jeden odcień, korygowaniu wartości border-radius z ośmiu na dziesięć pikseli i z powrotem, oraz na pięciokrotnym przepisywaniu nagłówków, zanim jakikolwiek odwiedzający zobaczył stronę. Wmawiałem sobie, że dopracowuję szczegóły, ale w rzeczywistości uprawiałem prokrastynację pod przykrywką dbałości o jakość. Rezultat? Wystartowałem z trzytygodniowym opóźnieniem. Kiedy strona w końcu ruszyła, ani jeden użytkownik nie skomentował krzywizny przycisków, nad którą tak się głowiłem. Interesowało ich tylko to, czy formularz wysyła się bez błędów.
Lekcja została ze mną: najpierw wypuść swoją pracę. Nie możesz iterować na podstawie informacji zwrotnych, których nie otrzymałeś. Zadbaj o solidną strukturę, upewnij się, że główna ścieżka użytkownika działa, i opublikuj stronę. Dopracowywanie należy do wersji drugiej, a nie wersji zero. Twoi użytkownicy powiedzą ci, co faktycznie nie działa, a co jest jedynie twoim wyobrażeniem o niedoskonałości.
Budowanie zbyt wiele i zbyt wcześnie
Mój projekt zaczął się jako proste narzędzie do dzielenia się rekomendacjami książkowymi. To był cały koncept. W drugim tygodniu nakreśliłem już system logowania użytkowników, dynamiczny wykres ocen, sekcję komentarzy, przełącznik trybu ciemnego i podsumowanie e-mailowe. Żadna z tych rzeczy nie działała dobrze. Proces logowania psuł się w połowie przypadków. Wykres nie miał żadnych realnych danych do wyświetlenia. Sekcja komentarzy pozwalała na duplikaty. Tymczasem podstawowa funkcja listy książek – cały powód, dla którego ta strona w ogóle istniała – została pogrzebana pod stosem niedziałających, niedokończonych dodatków, które dezorientowały każdego, kto trafił na stronę główną.
Prosta strona, która czysto rozwiązuje jeden problem, zawsze wygra ze skomplikowaną stroną, która robi dziesięć rzeczy słabo. Zanim napiszesz kolejną linię kodu, zdefiniuj jedno zadanie, które twój produkt wykonuje dla użytkownika. Zbuduj to. Przetestuj to. Dopracuj, aż będzie niezawodne. Jeśli użytkownicy faktycznie poproszą o panel sterowania lub kanał społecznościowy, będziesz mógł to dodać. Do tego czasu powstrzymaj się od chęci zbudowania szwajcarskiego scyzoryka, gdy wszystkim, czego potrzeba, jest po prostu ostry nóż kuchenny.
Ignorowanie doświadczenia użytkownika na rzecz wyglądu
Spędzałem godziny na wyborze eleganckich czcionek i stylowej palety kolorów. Obsesyjnie zajmowałem się gradientem tła w sekcji hero. Następnie ignorowałem to, jak strona faktycznie sprawia wrażenie podczas użytkowania. Strony ładowały się powoli, ponieważ serwowałem pliki PNG w pełnej rozdzielczości bez kompresji. Etykiety nawigacji używały błyskotliwych sformułowań, które dobrze wyglądały, ale zmuszały ludzi do zgadywania, dokąd prowadzi dany link. Przyciski były cienkie i stylowe, ale zbyt małe, by w nie kliknąć na ekranie telefonu.
Nauczyłem się na własnej skórze, że design wizualny i doświadczenie użytkownika (UX) nie są zamienne. Piękny interfejs zawodzi, jeśli odwiedzający muszą czekać kilka sekund na obraz banera lub jeśli nie potrafią dowiedzieć się, jak się z Tobą skontaktować w mniej niż dwa kliknięcia. Spraw, aby każda interakcja była prosta. Opisuj nawigację prostym językiem. Kompresuj zasoby. Sprawdź, czy elementy klikalne są wystarczająco duże. Szybkość i przejrzystość to nie bonusy, które dodaje się na końcu; to fundament, na którym opiera się wszystko inne.
Testowanie tylko na własnym komputerze
Opracowałem całą stronę na jednym laptopie, w jednej przeglądarce i przy jednej rozdzielczości ekranu. Na moim sprzęcie wszystko wyglądało bez zarzutu. Potem znajoma otworzyła stronę na swoim iPhonie. Przyciski nachodziły na siebie. Tekst wychodził poza kontener. Inny znajomy użył Safari na Macu, a cały układ CSS grid zawalił się w nieczytelną stertę. Po cichu założyłem, że skoro działa u mnie, to działa u wszystkich. To założenie kosztowało mnie weekend gorączkowych poprawek i pełnych zażenowania przeprosin.
Nie powtarzaj mojego błędu. Zanim opublikujesz stronę, sprawdź ją w Chrome, Firefox, Safari i Edge. Użyj narzędzi deweloperskich przeglądarki, aby symulować telefony, tablety i laptopy o różnych szerokościach. Kliknij każdy link. Wyślij każdy formularz. Agresywnie zmieniaj rozmiar okna. Błędy, które wyłapiesz podczas testów, są znacznie tańsze niż te, które Twoi użytkownicy znajdą na produkcji.
Traktowanie informacji zwrotnej jak osobistego ataku
Udostępnienie projektu sprawiło, że poczułem niepokój. A co, jeśli ludzie go znienawidzą? Kiedy kolega zasugerował porzucenie funkcji, nad którą spędziłem