поле должно быть заполнено
Обязательно или нет? Как отмечать поля в формах
Привет, я Антон, UX-дизайнер в eLama — платформе для автоматизации интернет-рекламы. Мы довольно часто работаем с формами. Раньше мы выделяли обязательные поля, но увидели мнение, что этот подход не самый правильный. Мы решили разобраться, а как правильно, но быстро поняли, что единых правил нет: кто-то делает акцент на обязательных полях, кто-то, наоборот, говорит, что некоторые поля можно пропустить. Попробуем сравнить самые распространенные подходы.
Все делают по-разному
Самые распространенные способы
1. Отмечать обязательные поля звездочкой
➕ Занимает мало места.
➖ Обычно обязательных полей больше, чем необязательных, поэтому визуального шума тоже больше.
➖ Требуют расшифровки в коде для скринридера.
2. Подписывать необязательные поля
➕ Скорее всего, таких отметок будет немного, а значит, визуального шума будет меньше, чем от звездочек.
➕ Мы не давим на пользователя и не принуждаем его заполнять поля. Наоборот, мы экономим его время, показывая ему, что некоторые поля можно пропустить.
➖ Отметка может потеряться на фоне заголовка, и пользователь может ее не увидеть.
➖ Неочевидно, что поля в верхней части формы нужно заполнить обязательно. Пользователь может понять это, только когда увидит необязательные поля.
3. Вообще не отмечать поля, а показывать ошибки при отправке формы
➕ Отсутствие визуального шума. Особенно это важно в больших формах.
➖ Не всем понравится заполнять форму повторно после того, как она загорится красным.
➖ Не сразу понятно, какие поля можно пропустить, а какие нет.
4. Отмечать обязательные поля звездочкой, а необязательные —подписывать
➕ Согласно этому исследованию, такие формы самые удобные: пользователь сразу видит, какое поле пропустить можно, а какое нет.
➖ В больших формах такие отметки создают визуальный шум.
➖ Требуют расшифровки в коде для скринридера.
Важно: ставить обязательные поля выше необязательных
Если пользователь не заметит отметки, он скорее заполнит верхние поля. Если форма разбита на смысловые группы, в каждой из них обязательные поля должны быть выше, чем необязательные.
Как делаем в eLama
Мы решили использовать четвертый способ, потому что удобство пользователя важнее, и это преимущество перевешивает недостатки подхода.
Так обязательное поле не теряется даже в большой форме
Но в некоторых случаях мы используем и третий способ.
Когда не ставим отметки
1. Если поле одно
Чтобы разблокировать кнопку, можно сделать только одно: заполнить поле
2. Если можно заполнить любое поле
Кнопка разблокируется, если заполнить любое из полей
Вместо заключения
Кроме этих способов наверняка есть и другие. Важно выбрать один-два подхода, которые подходят вашему продукту.
Спасибо Сергею Токареву и Елене Отроковой за помощь в подготовке материала и редактуру.
Миф об обязательном поле
В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».
Считается также, что некорректные (неполные) данные настолько страшны, что даже хранить их в базе данных уже некорректно. Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Что на это имеет сказать современная наука проектирования взаимодействия с пользователем? Во-первых, стало ясно (уж не знаю, кому и когда, но достаточно давно точно, см. [1] и [2]), что все-таки программы разрабатываются для пользователей. В этом смысле программист уже не диктует условия, а скромно создает сугубо утилитарный продукт, инструмент, которым будут пользоваться люди для решения своих задач и достижения своих целей. Как утюг — если тебе нужно что-то погладить, ты его включаешь. Если он будет вместо того, чтобы гладить, модально предлагать скачать обновления из интернета, понятно, куда такой утюг полетит. Алан Купер [1] рекомендует представлять пользователей вашего продукта как очень умных, но очень занятых людей. Они, мол, не тупые и поймут, как вашим продуктом пользоваться, главное, вы только не вставайте у них на пути.
Я вообще считаю, что каждому программисту (дизайнеру, менеджеру, аналитику) следует проделать медитацию, упомянутую Сергеем Бодровым-мл.:
Ты становишься на углу оживленной улицы и представляешь, что тебя здесь нет. Вернее, тебя нет вообще. Пешеходы идут, сигналят машины, открываются двери магазинов, сменяются пассажиры на остановке. То есть в принципе мир продолжает жить и без тебя. Понимать это больно. Но важно.
Я, конечно, вовсе не хочу сказать, что программист — профессия ненужная, я сам программист и совсем так не считаю. Просто это неблагодарная профессия. Никто не придет и не похвалит за хорошо реализованный алгоритм. Если программа хороша, ей будут пользоваться без дополнительных вопросов. Так и должно быть, просто, чтобы быть программистом, надо к этому привыкнуть. А эти вот люди, которые идут по улице и сменяются на остановке — это ваши пользователи. Они используют вещи так, как они им нужны. В том числе и ваш продукт. Без вас. Они ничего о вас не знают, не хотят знать и никогда не узнают. Сергею Витальевичу, когда он в полярной тундре пытается вбить в систему снятые со счетчика показания, совершенно не интересно, почему система говорит ему, что сперва требуется указать какой-то там тип тарификации, даже если в момент проектирования вам казалось, что без типа тарификации ну уж никак не обойтись. А что касается примера про утюг, скачивающий обновления, то он взят совсем не из пальца — обратите внимание, как ведет себя при включении браузер Файерфокс.
Тут вообще будет что-нибудь про обязательные поля, спросит хабраюзер? Как раз сейчас начнется.
Штука в том, что реальный наш мир — это не математическая модель, параметры которой известны в любой момент времени. Для реальной жизни характерна скорее нехватка информации, чем ее наличие. У человека, заполняющего форму, требуемых данных может не быть — и не быть их может во всех обозримых пределах досягаемости, то есть не быть ваще. Эту проблему нельзя решить, просто сделав поле обязательным — значение из воздуха не возьмется. Вводя на формах обязательные поля в угоду целостности и полноте данных, мы на самом деле мешаем пользоваться системой. Столкнувшись с такой ситуацией, пользователь либо не станет заполнять форму (и не сможет работать с системой вовсе), либо заполнит недостающие данные рыбой — выдуманными или бессмысленными данными. И это свидетельствует не о том, что пользователь плохой или плохо старался, а лишь о том, что разработанная система недостаточно гибка для использования в условиях реального мира. То, что произошло во втором случае (ввод рыбы) — это вообще обман. Разработчик системы может сколько угодно делать вид, что все в порядке, но на самом деле в этом обмане виноват именно он. Причем непонятно, кто и что вообще выиграл — пользователь поимел головную боль, а в систему попали некорректные данные. Да попали так, что обнаружить, отфильтровать или подчистить их автоматически уже невозможно — в отличие от случая, если бы пользователь просто указал, что информация отсутствует.
Что же делать? Делать нужно хорошие программы. А именно, да, таки не ставить целостность схемы БД во главу угла, а ставить туда цели и задачи пользователей. Другими словами, принимать у пользователя неполные, а в некоторых случаях и некорректные данные, естественно, с возможностью исправить их в будущем. Вопреки заблуждению (да, еще одному) это возможно, это не так сложно и это даже работает. Кроме этого, нужно еще каким-то образом помогать, подсказывать пользователю, где, каких данных и для чего ему не хватает. Чтобы он видел и контролировал ситуацию.
Сколько обязательных полей должно быть на форме? В идеале, ноль. Всегда ли такое возможно? Для меня одним из примеров высшего пилотажа является операция создания папки в Виндоус. Казалось бы, уж меньше одного поля тут не сделаешь, однако нет, они умудрились реализовать создание так, что система не спрашивает ничего — даже несмотря на то, что технические ограничения не позволяют системе создать папку без имени. Это идеал, к которому нужно стремиться.
Естественно, система должна быть минимально умной, спрашивая у пользователя только то, что имеет отношение к задачам пользователя, а не к потребностям самой системы. Система как инструмент, помните? Как раз про пример с Файерфоксом — Гугл Хром, например, решил проблему Файерфокса, обновляясь тихонько в тот момент, когда пользователь его перезагружает. Пользователю об этом знать совсем не нужно — он и не знает. Достойный пример для подражания. Я, признаться, даже сперва не понял, чегой-то он меня ни разу не спрашивал, когда ему обновляться?
Еще был миф о важных полях (это те, которые необязательны, но желательны к заполнению). Здесь все еще проще — принудительно заставить заполнить поле нельзя. Следовательно, хоть помечай поле как обязательное, хоть не помечай — все равно напишут рыбу, чушь, отписку, если не захотят заполнять. Интерфейсного решения у этой проблемы нет. Важность полей нужно доносить до сотрудников на местах. А разработчику пометить поле как необязательное. И позволить редактировать.
UPD: В комментариях trijin и zhindetz понятнее сформулировали основную мораль топика: речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво. То есть да, делать необязательными даже те поля, без которых система не будет работать. Естественно, она и не будет работать, но пусть хотя бы данные похранит.
UPD #2: Уточню еще одну вещь, которую я сам не осозновал ясно, когда писал топик. Я не обсуждаю здесь вопросов уместности тех или иных полей на форме (это важная, но все-таки немного другая тема, чем та, которую мне хочется донести). Я скорее предлагаю переосмыслить саму концепцию ввода информации с помощью форм, тот традиционный подход, когда нужно заполнить всю форму сразу и корректно. Вместо этого я предлагаю промежуточное состояние (неполное, некорректное, противоречивое) тоже позволять сохранять в БД, явным образом помечая такое состояние как неполное/некорректное/противоречивое. Таким образом все ситуации «я сейчас знаю не все, но завтра, может быть, узнаю», которые традиционно решаются записыванием на бумажку, можно обрабатывать с помощью информационной системы. Естественно, такие данные не нужно пускать в бизнес-процесс в силу их некорректности — тут все остается как раньше. Они просто полежат в БД до лучших времен — не пригодятся, ну и бог с ними.
Форма и состав реквизитов платежного поручения
Платежное поручение — основной документ, используемый организациями при безналичных расчетах. С 10.09.2021 его форма и состав реквизитов определены положением Банка России «О правилах осуществления перевода денежных средств» от 29.06.2021 № 762-П. Допустимо составление поручения в электронном виде и на бумажном носителе.
ВНИМАНИЕ! Для уплаты налогов ООО и ИП, у которых есть расчетный счет в банке, заполняют платежные поручения. Физлицам для уплаты налогов ФНС присылает квитанцию по форме ПД-налог.
Поля платежного поручения представлены в рисунке ниже.
Рассмотрим подробный порядок заполнения полей платежки.
Номер и дата платежного поручения
Номер и дата платежки — это поля 3 и 4 соответственно. Номер должен быть отличен от нуля и содержать максимум 6 символов. Дата в бумажном документе приводится в формате ДД.ММ.ГГГГ, а в электронном — в формате, установленном банком.
Как заполнить платежное поручение на уплату налогов, подробно разъяснили эксперты КонсультантПлюс. Получите бесплатно пробный доступ к системе К+ и переходите к Готовому решению.
Вид платежа
В поле 5 указывается вид платежа: «Срочно», «Электронно», «Почтой», иное значение в порядке, установленном банком. Если это предусмотрено банком, поле может оставаться пустым.
В электронной платежке значение указывается в виде кода, установленного банком.
Статус плательщика
Это поле 101. Его заполняют в налоговых платежках. Перечень кодов статуса приведен в приложении 5 к приказу Минфина России от 12.11.2013 № 107н. Основные коды:
Данные лица должны указывать единый код 13, который ранее использовали только обычные «физики».
Сумма платежа
Для указания суммы в платежке имеется 2 поля:
Информация о плательщике
Для нее предусмотрены следующие поля:
Об особенностях заполнения платежного документа при оплате налога третьим лицом читайте в статьях:
Банковские реквизиты плательщика
После указания плательщика приводятся его банковские реквизиты:
Информация о получателе платежа
Для получателя платежа необходимо указать ту же информацию, что и для плательщика, только немного в ином порядке. Сначала указываются его банковские реквизиты: наименование банка (в бумажной платежке), номер счета, БИК и корр. счет (поля 13, 14, 15 и 17).
С 01.05.2021 года в платежках на уплату налогов и взносов нужно обязательно указывать номер банковского счета, который входит в состав ЕКС, в поле 15. Также изменились реквизиты в полях 13,14 и 17. В период с 01.01.2021 по 30.04.2021 года банки будут принимать платежки как со старыми так и с новыми реквизитами. С 01.05.2021 можно использовать только новые реквизиты. О том, какие изменения произошли в реквизитах налоговых платежек с 2021 года, мы рассказали здесь.
ВАЖНО! Будьте внимательны при указании банка! Если сделать ошибку, налог (взнос) могут признать неуплаченным (п. 4 ст. 45 НК РФ). А значит, будут начислены пени.
После банковских реквизитов приводится информация о получателе: его наименование, ИНН и КПП (поля 16, 61 и 103).
В платежках по налогам и взносам в качестве получателей фигурируют те организации, которые их администрируют. При этом указывается сокращенное наименование органа Федерального казначейства и в скобках сокращенное наименование администратора, например: «УФК по г. Москве (ИФНС России № 16 по г. Москве)». Название нужно уложить в 160 символов — такая длина реквизита предусмотрена в приложении 11 к положению № 762-П.
ИНН и КПП можно узнать на сайтах ФНС России и ФСС.
Какие нюансы учесть при заполнении платежки на уплату страхвзносов, узнайте в Готовом решении от КонсультантПлюс. Если у вас еще нет доступа к системе, получите пробный онлайн-доступ бесплатно.
О том, где узнать реквизиты для налоговых платежей, читайте здесь.
Вид операции
Это поле 18. Здесь указывается шифр платежного поручения. Ему присвоен код 01 (приложение 1 к положению Банка России от 29.06.2021 № 762-П).
Срок и назначение платежа
Поля 19 «Срок платежа» и 20 «Назначение платежа» заполняются только в тех случаях, когда это прямо предусмотрено указаниями Банка России (приложение 1 к положению Банка России от 29.06.2021 № 762-П).
Так, в поручениях по налогам и взносам их оставляют пустыми. С 01.06.2020 в поле 20 нужно проставлять код вида дохода при платежах в адрес работников (по зарплате, пособиям и др.).
Подробнее о новых кодах в платежках на зарплату читайте здесь.
Очередность платежа
В поле 21 нужно указать очередность платежа в соответствии с гражданским законодательством. Для самостоятельно уплачиваемых налогов и взносов это 5.
Подробнее о заполнении данных об очередности платежа читайте здесь.
Поля 22 «Код» и 23 «Рез. поле»
Это поле предназначено для уникального идентификатора платежа (УИП). Его проставляют только тогда, когда он установлен получателем средств и доведен до плательщика (п. 1.1 указания Банка России от 15.07.2013 № 3025-У). Для текущих платежей по налогам, сборам и страховым взносам идентификатор не устанавливается. При этом в поле «Код» ставится 0. Оставлять поле незаполненным нельзя — банк не возьмет такую платежку к исполнению.
А вот резервное поле 23 в налоговых поручениях, наоборот, не заполняют.
Подробнее об УИП и о том, чем он отличается от УИН, читайте в этой статье.
Информация о платеже
В поручениях на перевод денег контрагентам указывают только назначение платежа: номер счета или договора, за что уплачивается НДС (это поле 24).
В платежках по налогам и взносам в обязательном порядке заполняются также поля 104–110. При этом нужно руководствоваться приказом Минфина России от 12.11.2013 № 107н. Рассмотрим эти поля далее.
Указываем КБК
Код бюджетной классификации (КБК) приводится в поле 104. В 2021 году перечень КБК определен приказом Минфина от 08.06.2020 № 99н. В 2022 году перечень нужно искать в новом приказе Минфина от 08.06.2021 № 75н.
Какие КБК изменились, см. здесь.
Приводим ОКТМО
Код по ОКТМО приводится в поле 105 в соответствии с Общероссийским классификатором территорий муниципальных образований (утвержден приказом Росстандарта от 14.06.2013 № 159-СТ). Он заменил код ОКАТО.
Этот код может состоять из 8 или 11 знаков:
Порядок распределения можно узнать из региональных нормативных актов или в ИФНС.
ОКТМО в платежном поручении должен соответствовать ОКТМО, указанному в налоговой декларации.
Таблица с кодами ОКТМО очень объемная, поэтому не всегда просто в ней ориентироваться. Указать правильный ОКТМО в расчете 6-НДФЛ вам поможет наш специальный сервис. Здесь достаточно ввести ИНН, если вы ИП или организация, либо адрес. Система быстро обработает запрос и выдаст нужный код.
О нюансах указания ОКТМО в платежках мы рассказывали здесь.
Основание платежа
В поле 106 указывается состоящий из 2 знаков код основания платежа. Основные коды следующие:
С 01.10.2021 в поле 106 больше не используются коды:
Вместо них нужно проставлять единый код ЗД — погашение задолженности по истекшим налоговым, расчетным (отчетным) периодам, в том числе добровольное.
Ранее код ЗД ставился только при добровольном погашении задолженности. Эта его функция также сохранилась.
В случае указания в поле 106 значения 0 ИФНС при невозможности однозначно идентифицировать платеж самостоятельно отнесет поступившие деньги к одному из оснований.
Налоговый период
Этот реквизит вносится в поле 107. Под него отводится 10 знаков, 2 из которых (3-й и 6-й) являются разделительными точками («.»). В общем виде он выглядит так: ХХ.ХХ.ХХХХ.
Показатель отражает периодичность уплаты налогового платежа или конкретную дату его уплаты, установленную законом.
Периодичность может быть месячной (МС), квартальной (КВ), полугодовой (ПЛ) или годовой (ГД).
В 4-м и 5-м знаках для месячных платежей проставляется номер месяца (от 01 до 12), для квартальных платежей — номер квартала (от 01 до 04), для полугодовых — номер полугодия (01 или 02).
7–10 знаки — это год, за который производится уплата налога.
При уплате налогового платежа 1 раз в год на месте 4-й и 5-й знаков показателя налогового периода ставится ноль (0). Если по годовому платежу предусматривается более 1 срока уплаты и установлены конкретные даты, то указываются эти даты.
Образцы заполнения показателя налогового периода:
МС.02.2021; КВ.01.2021; ПЛ.02.2021; ГД.00.2021; 04.09.2021.
Налоговый период указывается для платежей текущего года, а также в случае самостоятельного обнаружения ошибки в ранее представленной декларации и добровольной уплаты доначисленного налога (сбора) за истекший налоговый период при отсутствии требования налогового органа об уплате налогов (сборов). Основания платежа в поле 106 — ТП и ЗД соответственно.
Если гасится задолженность по требованию ИФНС, в формате «день.месяц.год» указывается срок уплаты, установленный в требовании, если задолженность по акту проверки (АП) — ставится 0.
В случае досрочной уплаты налога приводится 1-й предстоящий налоговый период, за который должна производиться уплата.
Поля 108 «Номер документа» и 109 «Дата документа»
В поле 108 указывается номер документа, который является основанием платежа.
Ноль (0) проставляется (п. 9 приложения 2, п. 6 приложения 4 к приказу Минфина России от 12.11.2013 № 107н):
В остальных случаях приводится номер документа, на основании которого переводится платеж. При этом знак № не ставится.
С 01.10.2021 по полю 108 можно отличить добровольное погашение задолженности от принудительного. Дело в том, что использовавшиеся ранее в поле 106 коды ТР, ПР, АП и АР нужно теперь указывать в поле 108 перед номером документа-основания:
В поле 109 отражается дата документа — основания платежа.
Формат даты следующий:
Для текущих платежей (ТП) приводится дата подписания декларации (расчета), для добровольно погашаемой задолженности прошлых периодов (ЗД) ставится ноль (0).
При недобровольном погашении задолженности с 01.10.2021 в поле 109 нужно указывать дату соответствующего документа:
Тип платежа (поле 110)
В настоящее время это поле не заполняется. Его нужно оставить пустым (подп. «г» п. 2 приложения к приказу Минфина России от 30.10.2014 № 126н, письмо Казначейства России от 03.04.2015 № 07-04-05/05-215).
Назначение платежа в налоговой платежке
В поле 24 «Назначение платежа» можно привести любую дополнительную информацию, связанную с платежом. В платежах по взносам следует всегда указывать месяц, за который идет перечисление. Дело в том, что при отсутствии такой пометки возможен зачет оплаты не в счет текущих платежей, а в счет погашения просроченной задолженности, если таковая имеется.
Заполненный образец полей платежного поручения в 2021 году можно скачать на нашем сайте по ссылке ниже:
Итоги
Проектируем идеальные текстовые поля: понятность, доступность и минимум усилий
В любое приложение или веб-сервис пользователь вводит свои данные: где-то в начале использования, где-то на протяжении всего взаимодействия. Поэтому продуктовые дизайнеры, разработчики и менеджеры продукта должны искать и реализовывать самые оптимальные способы ввода данных в продукт.
В этой статье мы поговорим о текстовых полях и рассмотрим ключевые факторы, способные улучшить процесс ввода данных. Помните, что это просто общие рекомендации — у всех правил есть исключения.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Текстовое поле
Текстовое поле — это базовый элемент управления текстом, который позволяет пользователю ввести определенное количество данных. Какое приложение ни возьми — во всех можно найти небольшое поле, куда вас просят ввести личные данные. Даже когда вы вводите запрос в Google — вы тоже заполняете форму с одним единственным текстовым полем.
Понятность
Понятное название поля
Пользователь хочет знать, какую информацию нужно вводить в поле: именно поэтому у поля должно быть понятное название (лейбл). Конечно, иногда назначение поля можно понять по иконке (например, изображение лупы дает понять что перед нами поле поиска), но в большинстве случаев нужно четкое, всегда видимое название каждого поля.
Понятные названия полей придают пользователю уверенности: значит, он все правильно понимает и совершает правильные действия.
Короткое название поля
Название поля — это не подсказка. Название должно быть краткими, лаконичными и описательными ( слово или пара слов), чтобы пользователь мог быстро просканировать содержимое. Если хотите предоставить дополнительную информацию, подсказать или погрузить в контекст — добавьте подсказки, но не нужно перегружать название.
Правильный размер поля
Размер поля должен соответствовать предполагаемому объему данных — так пользователям будет проще и понятнее. Поле должно быть такой длины, чтобы в него полностью помещалось большинство возможных вариантов ввода.
Фокус поля ввода
Когда поле в фокусе, это нужно подчеркнуть визуально: поле должно поменять цвет, или рамка должна подсветиться, или курсор должен моргнуть — что угодно.
Подсказки для полей
Данные бывают разного формата. Конечно, в идеале нужно проектировать так, чтобы пользователю было удобно вводить свои данные. Но это не всегда возможно.
К примеру, номер телефона можно ввести через “+”, или через код страны, или через местный код, или вообще без кодов. Чтобы решить эту проблему, можно добавить инструкцию, пример или подсказку — и пользователь сам поймет, в каком формате вводить номер. Есть несколько способов решить проблему формата телефонных номеров:
Полезная информация
Полезную информацию (или сопроводительный текст) нужно использовать только если это необходимо: например, объяснить, зачем запрашиваем данные кредитки, или как будет использована информация о дате рождения, или чтобы дать ссылку на “Условия предоставления услуги”. Сопроводительный текст — отличный способ развеять сомнения пользователя и предотвратить ошибки ввода. Только есть такое правило: объем текста не должен превышать 100 слов.
Только для мобильных: тип клавиатуры должен соответствовать формату поля
Пользователи приложений любят, когда тип клавиатуры, которая появляется при нажатии на поле, соответствует данным, которые нужно ввести. На примере ниже мы видим, что пользователю слева придется дополнительно нажать на кнопку с цифрами, чтобы открыть цифровую клавиатуру и ввести нужное число.
Доступность
Цель: Чтобы всем пользователям (вне зависимости от их физических возможностей) было проще сканировать/заполнять поля.
Не пишите названия заглавными буквами
Никогда не используйте все заглавные — такое название будет очень сложно прочитать, и еще сложнее просканировать, потому что все буквы одной высоты.
ЗАГЛАВНЫЕ БУКВЫ сложнее читать, потому что у всех заглавных одинаковая прямоугольная форма, а для нашего восприятия это непривычно.
Размер шрифта
Шрифт должен быть достаточно крупным, чтобы текст легко читался. Безопасный вариант — 16 px для основного текста. Конечно, размер шрифта зависит от контента и от других элементов на странице, но если вы сомневаетесь — выбирайте более крупный вариант.
Цвет текста в названии
Цвет названия должен соответствовать цветовой палитре вашего приложения, но в то же время должен быть достаточно контрастным (не слишком темным, не слишком ярким). В руководстве W3C предлагается такое соотношение для основного текста:
Сделайте удобные тап-зоны
В наше время можно сказать с уверенностью: кто-то из ваших пользователей открывает сайт/приложение на сенсорном устройстве. При проектировании мобильного интерфейса важно продумать удобные тап-зоны: они должны быть достаточно большими, чтобы нажать пальцем. Общепринятый размер тап-зоны — 45–57px, но если подгонять поля под этот размер, то на мобильных они будут казаться огромными. Поле размером 32px — 40px не выглядит слишком большим, и при этом достаточно удобно для нажатия пальцем.
Высота поля в Bootstrap 3 по умолчанию 34px — и это хороший базовый размер. Не стоит делать поля меньше.
Только для десктопов: задействуйте клавиатуру
Настройте форму так, чтобы пользователь мог заполнять все поля с клавиатуры. Опытные пользователи часто все делают при помощи клавиатуры: позаботьтесь, чтобы они могли легко переключаться между полями и заполнять их, не отрывая рук от клавиатуры. Подробные рекомендации по взаимодействию через клавиатуру вы найдете здесь.
Минимум усилий
Цель: Чтобы пользователь вводил как можно меньше данных.
Автозаполнение с умом
Вводить данные в поля совсем не весело. Поэтому вы можете облегчить пользователю этот процесс и автоматически заполнить некоторые поля. Например, можно определить штат по введенному ранее индексу. Еще можно предложить варианты, которые пользователь уже вводил ранее.
Еще пример: можно определить страну пользователя по IP-адресу. WhatsApp существенно облегчает ввод телефонного номера. Если вы заходите в приложение из США, код страны заполняется автоматически.
Автозаполнение и автопредложение
Автозаполнение предлагает варианты ввода в режиме реального времени — это помогает пользователям заполнять форму точнее и эффективнее. Это особенно актуально для малограмотных и иностранных пользователей.
Автопредложение — это отображение списка ключевых слов и фраз по теме, которые могут соответствовать (а могут и не соответствовать) введенному запросу. Если автозаполнение помогает пользователю закончить начатую фразу, то автопредложение выдает несколько разных вариаций этой фразы.
Если автозаполнение и автопредложение работают правильно, они значительно ускоряют процесс заполнения полей. В Google используются обе функции, чтобы опыт взаимодействия с поиском был максимально отзывчивым.
В заключение
Процесс ввода данных нужно сделать максимально простым. Даже небольшие изменения — такие как вспомогательный текст и уточнение типа информации в каждом поле — могут существенно поднять юзабилити полей, а, значит, и качество UX в целом.
Изначально опубликовано на babich.biz
Если вам понравилась статья и перевод, дайте нам знать — нажмите ♡
А если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Мобильное приложение «Заметки о психике» | Mental Notes
Полезный инструмент для встряхивания мозгов. Подкидывает идей как привлечь, удержать и направить внимание пользователя
Mental notes — это колода из 53 карточек с описанием психофизиологических моделей поведения людей, которые лежат в основе принципов веб-дизайна. Они помогают дизайнерам, проектировщикам лучше понять поведение пользователей и найти эффективные решения при создании дизайна интерфейсов.