Dodajmy Mały Ficzer w Aplikacji! Czy Na Pewno Taki Mały i Ile Będzie Kosztował?

Dodajmy Mały Ficzer w Aplikacji! Czy Na Pewno Taki Mały i Ile Będzie Kosztował?

„Dodajmy jedno dodatkowe pole w formularzu rejestracji, które pozwoli opisać użytkownikowi własną osobę”. No i zespół wrzucił kolejny ficzer do zakresu. Wycenili go na 15 minut roboty. Nie za mało?

To tylko mały Ficzer…

A czy dodanie tego pola (textarea) nie spowoduje zwiększenie wysokości formularza rejestracyjnego? Tym samym dla wielu mniejszych rozdzielczości użytkowników, dolny przycisk „Zarejestruj” być może nie będzie od razu widoczny na ekranie (przewijanie)? O ile to zmniejszy konwersję rejestracji?
No to zmieńmy layout aby formularz był w dwóch kolumnach (dodatkowe zadanie)! A może pozostawmy jedną kolumnę, ale pole będzie mieć domyślnie 1 wiersz, a dopiero po jego kliknięciu zwiększy swoją wysokość? Ile już siedzicie na tym spotkaniu i obgadujecie ten ficzer (koszt)?
Jest też takie powiedzenie, że każdy klik czy akcja użytkownika zmniejsza ilość konwersji o kolejne 50%… Więc czy samo zwiększenie ilości pól w formularzu nie spowoduje zmniejszenia wartości konwersji? To może dodajmy link obok pola „wklej opis opis z Facebook lub Twitter” (kolejne zadanie).

ficzer
Mega ficzery w scyzoryku

Kolejna rzecz to kwestia długości tego opisu. Być może za długi tekst popsuje wygląd zapisanego profilu użytkownika. To może w zapisanym widoku tego profilu pokazywać pierwsze 100 znaków i przycisk „zobacz cały opis”. Zrobiliście? Jednak okazało się, że po rozwinięciu opisu layout tej podstrony i tak się rozjeżdża. Zaczęliście poprawki, ciągle rozjazdy… Dość!
Dajecie ograniczenie ilości znaków za pomocą atrybutu: maxlength. Ale użytkownik pisząc opis w pewnym momencie widzi, że pisze i dalej nie może. Myśli: błąd strony? To może dodać javascript, który po przekroczeniu limitu ilości znaków pokazuje obok pola ładną informację w chmurce.
A co jeśli opis jest zbyt krótki? Jakoś marnie to wtedy wygląda na podstronie profilu. To dodajmy też ograniczenie z dołu! Ale weryfikować te ograniczenia po  stronie przeglądarki czy serwera? A może po obu?
W końcu jest na stronie nowy „ficzer” (jako zmiana). Nikt nie wypełnia tego pola. Może dać jako wymagane? Jeszcze bardziej spadła konwersja rejestracji? To może dodać w polu podpowiedź do czego ono służy i dać z powrotem jako opcjonalne do wypełnienia? Uff… Długie te 15 minut.

Czytaj również:  Product Manager vs. Project Manager?

Ale może to przecież tylko MVP!?

Ktoś powie, ale takie pierdoły nie zawsze są istotne. Są istotne, bo one stanowią o jakości. Użytkownik przychodzi na Twoją stronę najczęściej w jednym celu. Kwestia tego aby poznać dobrze ten cel (większości użytkowników). Większość działań teraz powinna się skupić na tuningu elementów serwisu, które pomagają realizować ten cel (zasada 80/20), w jak najmniej bolesny sposób (jakość).
Masz to robić po to aby użytkownik nie był bombardowany nowymi fajerwerkami, ale żeby jeszcze lepiej używało mu się tego co dotychczas. Dlatego planując kolejny ficzer, nie miej złudzeń, że jego wykonanie, w dobrej jakości, zajmie Ci 5 minut…
Wymyślanie nowości w zakresie pracy nad stroną jest łatwe. Gorzej z poprawnym szacowaniem czasu ich wykonania. Kiedy spojrzysz na pojedynczą zmianę w kontekście wspomnianej jakości, może się okazać, że ta zmiana jest mało istotna w twoim startupie, w odniesieniu do kosztów jej wykonania.
Pracuj nad szacowaniem czasu wykonania zadań (używaj danych historycznych) i wtedy ustalaj priorytety kolejności wykonania dla dobra Twojego e-biznesu.