Nowe formularze do castingów

Nowe formularze do Castingów w programach TVN

Tło projektu

TVN do publikacji formularzy castingowych używał przestarzałej platformy “Redaktor”, która miała dobre 15 lat. Nie spełniała ona do końca wymagań biznesu, miała swoje wady a zaciągnięty dług technologiczny powodował, że nad platformą nie opłacało się pracować i dalej jej rozwijać. Lepiej było stworzyć nowe narzędzie. Postawiono na nową platformę Manhattan, która pozwalała nie tylko na publikację formularzy, ależ sond.

W tym projekcie pełniłam rolę UX Designera

Wszystkie mockupy, które zobaczysz poniżej nie są ostateczną wersją produktu. Są tylko prezentacją rozwiązania, bez ostatecznego UI

Moją rolą było wymyślenie działania i funkcjonowania nowych formularzy

Moi zadaniem było zaprojektowanie 2 rozwiązań dla 2 różnych person:

Platforma do tworzenia formularzy (Manhattan)

Persona: redaktor, który chce opublikować nowy casting do programu

Jeśli pojawia się potrzeba na uruchomienie castingu do nowego lub istniejącego już programu, to produkcja danego TV Show przesyła do redakcji tvn.pl jakie dane chcą pozyskać od kandydatów. Platforma do tworzenia formularzy zatem musiała być intuicyjna, prosta w obsłudze, nawet bez wstępnego przeszkolenia.

Formularz, który widzi user

Persona: użytkownik zgłaszający się do TV show (czyli tak naprawdę każdy)

Czyli to, co zobaczy user w formularzu, gdy będzie chciał zgłosić się do “Top model” i do wielu innych programów. Ważnym elementem była tu dla mnie dostępność, wiedząc o tym, że narzędzie będzie publiczne, skierowane praktycznie do każdego.

Design System

Dodatkowym celem projektu było stworzenie Design Systemu do formularzy, który byłby re-używalny i możliwy do stosowania na innych stronach ekosystemu TVN- np. w formularzach kontaktowych stron różnych programów i serwisów.

Jakie były główne bolączki 'starych formularzy'?

Zadziałałam dwutorowo.

1. Pierwszym moim krokiem była analiza UX obecnych formularzy (tych, które widzi user). O tym poniżej.

2. W drugim kroku spotkałam się z osobami, obsługującymi dotychczasową platformę i zapytałam o główne bolączki. To, czego się dowiedziałam:

obecnie jest słabe zabezpieczenie przed bootami, co oznacza, że złośliwe oprogramowanie może wypełnić formularz i wysłać je wiele razy, dodatkowo obciążając nasze serwery ciężkimi plikami.
dodawanie plików – jeśli chcieliśmy, żeby użytkownik dodał do swojego zgłoszenia 10 zdjęć, to musieliśmy zadać 10 osobnych pytań, było to pracochłonne i męczące dla nas (redaktorów) a co dopiero dla osoby wypełniającej formularz.
kwestia estetyczna – design platformy Redaktor był rodem z lat 2000 😎
jesteśmy świadomi, że obsługa formularzy przez usera z poziomu telefonu była wyzwaniem. nasze rozwiązanie nie do końca było uszyte pod mobile.

Wnioski z mojej analizy UX obecnego stanu formularzy

Zaczęłam od analizy formularzy na mobile:

"Ściana płaczu", czyli monotonność formularza, brak podzielenia jej na etapy informowania ile jeszcze kroków przed userem:

Proces dodawania pliku:

Tak wygląda obecnie panel do tworzenia formularzy w castingach:

Widok listy (wszystkie castingi) :

Tak wygląda dodawanie informacji podstawowych o formularzu:

A tak wygląda dodawanie już pierwszych pól (pytań) do formularza:

Kolejny krok: moja analiza pól formularzy

Wiedząc, że muszę zaprojektować narzędzie kompletne i uniwersalne, wzięłam pod lupę wszystkie castingi, które były dostępne na stronie, ale też te archiwalne. Zależało mi na zidentyfikowaniu rodzajów pól potrzebnych w developmencie.

1. Spisałam wszystkie pytania stosowane w castingach:

imię
nazwisko
wiek
miasto
telefon
adres e-mail
data urodzenia
płeć

narodowość
ulica
miasto
kod pocztowy
kraj
wykształcenie
ukończone szkoły
ukończone kursy

twoja strona internetowa prywatna lub biznesowa
strona bądź profil w mediach społecznościowych
rodzaj występu
rodzaj talentu
pseudonim artystyczny
język ojczysty

pytania (tak-nie)
pytania otwarte
załączanie plików

2. Na tej podstawie wyróżniłam rodzaje pól do zaimplementowania

Input prosty
Text area small
Text area large
Data
Liczba
Email
Telefon
Select jednokrotny wybór
Multiselect wielokrotny wybór
Radiogrupa
Załączniki

Decyzja o szerokości pól w formularzach

Na desktop zdecydowałam się wprowadzić dwie szerokości pól: krótkie i długie. Dlaczego? Nie chciałam aby w pytaniu o telefon, czyli potencjalnie krótką odpowiedź, input zajmował całą szerokość ekranu. Dzięki krótkim polom można je też umieszczać obok siebie, tworzyć też grupy pól:

Jak ominąć reCAPTCHE i zwiększyć dostępność formularza?

Zaproponowałam dwa sposoby ominięcia przez usera ‘potwierdzania że nie jest robotem`. Dla osób z trudnościami np. (np. niedowidzący) niezbyt dostępnym rozwiązaniem wydaje się np. popularne zaznaczanie 3-ech zdjęć spośród 9-ciu na których znajduje się przejście dla pieszych.

Jedną z wad obecnego rozwiązania było słabe zabezpieczenie, które umożliwiało przesyłania przez złośliwe boty setki leadów, dodatkowo obciążając serwer cięzkimi plikami.

1) Honey Pot

Złośliwy bot zobaczy pole formularza i wypełni je. To pole będzie zaszyte w kodzie, ale niewidoczne dla usera na froncie. Podczas zbierania leadów należy użyć jednego ‘IF’ czyli z automatu usuwać leady zawierające to niewidoczne pole jako wypełnione.

tak formularz zobaczy bot:

a tak formularz zobaczy user:

2) Time stamp

Dzięki zastosowaniu tego mechanizmu możemy wykluczyć leady które wypełnił bot. Kluczowe jest tutaj określenie minimalnego czasu wypełnienia formularza. Przykładowo, user nie jest w stanie wypełnić pól formularza w 0,5 sekundy, nawet używając autouzupełnienia.

Okej, czas na moje projekty UX:

Nazwy pól trzeba było przełożyć na język polski

To zabieg, na jaki się zdecydowaliśmy chcąc być spójnym z całym panelem Manhattan. Ta platforma już była w TVN wykorzystywana do tworzenia sond i cała jest w języku polskim. Teraz przyszedł czas na formularze, które miały być tworzone przed redaktorów, nie znających nomenklatury komponentów (np. drop-down)

Input
Text area
Date
Number
Email
Phone
Select jednokrotny wybór
Multiselect wielokrotny wybór
Radiogroup
Attachments

inne nazewnictwo:

Drop down list
Radiogroup

Tekst – jedna linia
Tekst – wieloliniowy
Data
Liczba
Email
Telefon
Jednokrotny wybór
Wielokrotny wybór
Lista do
Załączniki

inne nazewnictwo:

Lista rozwijana
Lista na wierzchu

Nowy widok listy formularzy:

Opis poszczególnych pól formularza:

Input prosty

Szczegóły

Zastosowanie: w prostych polach typu imię, nazwisko, wykonywany zawód, pseudonim artystyczny itp.
Maksymalna liczba znaków 255 (systemowo). Po osiągnięciu limitu dalsze wpisywanie nie jest możliwe. Jednak jeśli user wklei liczbę znaków powyżej 255, to walidujemy takie pole

Jak to pole będzie wyglądać podczas konfiguracji w panelu Manhattan?

Text area

Szczegóły

Chcąc być elastycznym wprowadziłam dwa rozmiary pola. Czasami pytania są krótkie i nie wymagają rozbudowanych odpowiedzi. Dłuższa forma wypowiedzi będzie przydatna np. w formularzu kontaktowym w którym można opisać i zgłosić sprawę (np. do programu “UWAGA!”)
Na mobile nie będzie ikonki do powiększania pola

Jak to pole będzie wyglądać podczas konfiguracji w panelu Manhattan?

Data

Szczegóły

Pole “data” było trochę bardziej skomplikowane, gdyż mogło być użyte w pytaniu o wiek, ale także po prostu o datę.
Przykład pytania o datę: kiedy zgłaszasz się do udziału w programie, w którym remontowane są domy, formularz może zawierać pytanie od datę ostatniego remontu. (program “Totalne remonty Szelągowskiej” w TVN)
Pokazujemy placeholder z formatem daty
Możliwe jest ręczne wypełnianie
Klik na kalendarz otwiera natywny kalendarz urządzenia
Dalsza logika rozpisana poniżej, wraz z walidacją

Jak default'owo to pole będzie wyglądać podczas konfiguracji w panelu Manhattan?

po zaznaczeniu dodatkowych opcji będzie to wyglądać tak:

Wygląd rozwiniętych list drop-down, gdy wybrana wartość to 'data' :

Liczba

Szczegóły

Domyślna długość inputu: krótka
Na mobile userowi pokazuje się klawiatura numeryczna
Na desktopie może wpisać tylko liczbę i przecinek. Jeśli wpisze kropkę, to system sam zamienia to na przecinek
Dodatkowe warunki rozwiają się po zanzaczeniu tej opcji

Jak to pole będzie wyglądać podczas konfiguracji w panelu Manhattan? Zaznaczone są od razu opcje dodatkowe:

Na mobile oczywiście od razu wysuwamy klawiaturę numeryczną

Email

Szczegóły

Rezygnujemy z placeholdera wewnątrz inputu, dlatego, że czytniki głosowe nie będą w stanie tego przeczytać. Lepiej użyć do tego tekstu pomocniczego
Domyślnie długość inputu jest “długa”.