Допоміжний текст всередині полів введення ускладнює роботу з формою, оскільки користувачеві доводиться запам'ятовувати вміст плейсхолдера кожного поля. Крім того плейсхолдери створюють додаткові складнощі для людей з зоровими і когнітивними порушеннями.
Зрозуміло, самі по собі підказки зазвичай допомагають зрозуміти користувачеві, що потрібно ввести в кожне поле форми, що в свою чергу позитивно позначається на конверсії. І є багато способів дати користувачеві такі підказки. Один з них - використання тексту всередині самих елементів форм. На жаль, результати тестування свідчать про те, що плейсхолдери швидше погіршують юзабіліті форм, ніж покращують його.
Заголовки полів і плейсхолдери
Заголовок поля повідомляє користувачеві, що необхідно ввести у відповідне поле, і зазвичай розташовується поза самим полем. Плейсхолдер розташовується всередині поля вводу і є, як правило, або заголовком, або додатковою підказкою, або прикладом введення в конкретне поле, зникаючи, як тільки користувач починає набирати текст в цьому полі.
Плейсхолдер замість заголовка
В інтернеті часто можна зустріти форми, в яких заголовки полів відсутні, а їх роль виконують плейсхолдери. Як правило, так роблять для зменшення розміру самої форми і позбавлення від зайвого «шуму». Тобто, керуючись цілком благими намірами, дизайнери насправді знижують зручність роботи з формою.
Найгірший варіант: плейсхолдер використовується замість заголовка
Нижче наведено сім причин, чому не варто замінювати заголовки полів плейсхолдерами:
- Зникнення тексту плейсхолдерів навантажує короткочасну пам'ять користувачів
Якщо користувач забув зміст підказки, що часто трапляється при заповненні великих форм, то йому потрібно видалити введений текст з поля, а в деяких випадках ще й зняти фокус з поля форми, для того, щоб плейсхолдер знову став видно. В ідеальному випадку користувач повинен бути повністю сконцентрований на заповненні форми. Насправді ж він може відволікатися на інші вкладки в браузері, на повідомлення або телефонний дзвінок. Тому важливо максимально полегшити користувачеві повернення до заповнення форми.
Звичайно, часто використовувані форми з одним-двома полями введення, наприклад, рядок пошуку або логін-пароль, на відміну від складних форм, не навантажують пам'ять користувача. І в більшості таких випадків користувач може і так здогадатися, що потрібно вводити. Проте навіть з полем для логіна можуть виникнути труднощі - чи повинен користувач ввести свій логін або адресу пошти?
- Без заголовків користувач не може перевірити правильність заповнення форми перед її надсиланням
Додатково проблема ускладнюється можливістю неправильного автозаповнення полів браузером. Для перевірки користувачеві доведеться один за одним вирізати і вставляти текст у полях форми. Знову ж таки, в реальності користувач швидше за все просто не буде обтяжувати себе такою подвійною перевіркою, що підвищує ймовірність відправки форми з помилками.
- У разі помилки користувачеві складніше зрозуміти, що і як виправити
Якщо немає видимих підказок, користувачеві доведеться так само проходитися по всіх полях форми, щоб визначити, в чому помилка.
- Якщо плейсхолдер зникає фокусом на полі вводу, це створює проблеми для користувачів, які перемикаються між полями за допомогою клавіатури
Багато хто використовує клавішу Tab для швидкого переходу до наступного поля, як правило, не читаючи його зміст до того, як переключитися на нього.
- Поля з плейсхолдером менше схожі на поля для вводу
Результати окулографії свідчать про те, що погляд користувача сильніше «чіпляється» за порожні поля. У кращому випадку, користувач витратить зайвий час на визначення поля для введення, в гіршому ж - просто його пропустить, що може серйозно позначитися на конверсії.
- Користувач може сплутати плейсхолдер і автоматично заповнене поле
Коли в полі вже є текст, користувач може пропустити його як вже заповнене. Деякі користувачі можуть прийняти текст плейсхолдера за типове значення і також пропустити поле.
- Іноді користувачеві доводиться вручну видаляти текст плейсхолдера
З'являються реалізації, в яких текст підказки не зникає при переході до заповнення поля. І користувачеві доводиться вручну видаляти підказку перед тим, як ввести справжні дані. Це, зрозуміло, вкрай знижує зручність заповнення форми і створює непотрібні труднощі.
Плейсхолдер на додаток до заголовка
Використання плейсхолдера як додаткової підказки - вже крок у правильному напрямку. Заголовки полів, що несуть ключову інформацію, видно завжди, тоді як плейсхолдери містять більш повні інструкції до заповнення форми. Проте, навіть із заголовками, використання плейсхолдерів може призводити до описаних вище проблем, хоч і з дещо меншою ймовірністю. Якщо якісь поля потребують додаткового опису, критично важливого для коректного заповнення форми, найкраще помістити цей опис поруч з полем, щоб він завжди був доступний користувачеві.
Краще: тут плейсхолдер використовується як підказка додатково до заголовка
Плейсхолдери і загальнодоступність
Ще одна проблема з плейсхолдерами полягає в тому, що вони в основній своїй масі не загальнодоступні:
- Стандартний світлий колір тексту плейсхолдера слабо контрастує з більшістю фонів. Для користувачів з ослабленим зором слабкий контраст ускладнює прочитання підказок плейсхолдерів, при цьому, змінити їх колір за допомогою CSS дозволяють не всі браузери.
- Додаткові труднощі для користувачів з когнітивними і моторними порушеннями. Як описано вище, це і додаткове навантаження пам'яті і необхідність в додаткових діях з мишкою і клавіатурою для заповнення форм.
- Не всі екранні диктори зачитують вміст плейсхолдерів. Сліпі і слабозорі користувачі можуть через це повністю упустити важливі підказки.
Ув'язнення
Замість того, щоб ризикувати доставити користувачеві проблем із заповненням форм або змусити його витратити час на розуміння того, а як воно працює, краще зробити ясні, завжди видимі заголовки до порожніх полів форми.
Найкраще: заголовок і підказка завжди видно користувачеві
Підказки та додаткові інструкції найкраще теж дати поруч з відповідними полями вводу. Форми є одним з найважливіших елементів для підвищення конверсії, так що варто подбати про те, щоб користувач міг заповнити їх якомога швидше і з якомога меншою кількістю помилок.
