Input Field: полная анатомия UI/UX-дизайна полей ввода или идеальный инпут

Всё, что нужно знать дизайнеру про UI/UX-дизайн инпутов для веба, интерфейсов и мобильных приложений. После этого лонгрида ваши формы и поля будут сделаны профессионально и удобно. Поля ввода — это как винтики в огромной машине интерфейса: мелкие, но без них ничего не работает. Ни авторизация, ни поиск, ни заполнение корзины.

Введение или вся важность UI/UX-дизайна Input Fields

Когда дизайнер делает поле ввода, Бог где-то морщится. Потому что дизайн инпутов — это не про пиксели. Это про боль, недосып и трёхчасовую попытку вспомнить, какой именно символ допустим в твоём почтовом индексе.

Поле ввода — это крошечный забор между пользователем и его целью. И от того, как ты его нарисуешь, зависит, перепрыгнет он через него с радостью или разобьёт лоб. А если таких заборов десять подряд — всё, UX-дизайн превращается в квест, где главный босс — форма регистрации.

Зачем вообще говорить о полях ввода и их дизайне?

Казалось бы, ну что там говорить: прямоугольничек, в него вводится текст. Всё. До тех пор, пока не попытаешься купить билет на сайте, где маска ввода телефона работает только с американским форматом, а ты из Владивостока.

Поля ввода — это как гвозди в доме: если сделаны плохо, будешь спотыкаться на каждом шагу. Они незаметны, пока не ломаются. А ломаются они чаще всего по вине дизайнера, который «не знал, как будет на проде». Или, что хуже, — знал, но «потом поправим».

Когда человек заходит в интерфейс, он почти всегда хочет что-то ввести: имя, email, адрес доставки, ключевое слово в поиске, отзыв, пароль от забытого аккаунта. Это первое касание, точка входа, handshake. И если оно скрипит, пользователь разворачивается и идёт вон.

Почему инпуты критичны для UX-дизайна?

Text Input — это диалог. Только не голосом, а курсором. Ты что-то спрашиваешь, человек тебе что-то отвечает. И если ты:

• задаёшь глупый вопрос (лейбл у инпута неинформативный),
• перебиваешь (автовалидация орёт при каждом символе),
• не слушаешь (поле не принимает то, что человек пытается ввести),

то UX идёт по бороде. Инпуты — одна из немногих зон в интерфейсе, где пользователь проявляет активность. Он не просто тыкает, он доверяет тебе информацию о себе. А ты должен сделать так, чтобы это доверие не треснуло от первого нажатия.

На UX дизайн полей влияют:

• текст, который рядом с ними (лейблы, ошибки, подсказки);
• визуальные состояния (фокус, ховер, ошибки);
• физическое поведение (маски, автоформат, табы);
• логика валидации (в реальном времени или по отправке).

И, как правило, если пользователю где-то плохо, это или поле формы, или скролл. Сегодня говорим про первое.

Примеры провальных и удачных полей ввода и их дизайна

Пример №1: добавляем товар в корзину, идём оформлять заказ. Что может делать поле ввода телефона? Начинает танцы с бубном, не принимает +7, требует 8, не даёт вставить номер из буфера, орёт ошибку до того, как ты вообще закончил ввод. UX-провал в прямом эфире.

Пример №2: теперь заходим на Т-Банк, например — форма обратной связи. Всё с полями сделано с хирургической точностью: маска, автотаб, валидация после заполнения. Поле не душит, а ведёт пользователя за руку. Вот оно — уважение в каждом пикселе.

Что такое Input Field и зачем он нужен

Определение: что мы называем инпутом в дизайне

Поле ввода — это интерфейсный элемент, куда пользователь вводит текстовую информацию. Ключевое слово — «вводит». Оно активно, требует участия, реакции, действия. Это не просто блок с текстом — это портал, через который пользователь что-то сообщает системе.

По сути, это текстовое окно, чаще всего прямоугольной формы, которое может выглядеть как угодно: с рамкой, без рамки (с заливкой), с иконкой, с плейсхолдером, внутри формы или само по себе. Но суть одна — пользователь туда пишет.

Чем Input Field отличается от выпадашек, радиокнопок и прочего

Всё просто: Text Input Field требует ввести данные с клавиатуры. Выпадашки, радиокнопки, чекбоксы — всё это про выбор. Там пользователь тыкает в уже готовое. Тут — создаёт сам.

Вот почему поле ввода всегда опаснее. Оно непредсказуемо. Ты не можешь знать, что именно введёт пользователь. Он может вбить номер карты кириллицей. Могут прийти смайлики, пробелы, HTML. И ты как дизайнер должен быть к этому готов.

Радиокнопки — это опрос. Поле ввода — это диалог, и не всегда вежливый.

Где чаще всего встречается инпут: формы, фильтры, регистрации, поиски

Текстовые инпуты буквально везде:

• Формы регистрации и авторизации — имя, email, пароль, подтверждение.
• Поиск — и в шапке, и в каталоге, и на мобильной версии.
• Формы оплаты — карты, адреса, индексы.
• Фильтры — диапазоны цен, площади, рейтинги.
• Комментарии и отзывы — многострочные поля с ограничениями.
• Обратная связь — имя, контакт, сообщение.

Даже если ты делаешь интерфейс с тремя экранами и двумя кнопками — шанс, что тебе придётся вставить поле ввода, близок к 100%.

Почему на инпутах и их дизайне «горит» половина пользовательского опыта

Потому что на них всегда завязано что-то важное. Никто не вводит email просто так. Если поле не работает, ломается вся цепочка:

• не получается зарегистрироваться;
• не приходит СМС или письмо;
• не отправляется заявка;
• не проходит плата.

А если ещё и поле говорит с тобой на странном языке — всё. Пользователь выходит из чата. Причём навсегда.

Проблема полей в том, что их «делают в конце». Нарисовали макет, навесили кнопки, подключили API, а потом такие: «ой, тут же ещё поля». И начинается UX-хаос. Неправильные маски, баги с клавиатурой, невнятные ошибки, лейблы, которые исчезают на фокусе.

Так не надо. Поле — это не хвостик. Это начало. Начало взаимодействия, доверия и, если повезёт, конверсии. А для работы над полями могут быть полезны UX-исследования.

Анатомия и UI-элементы поля ввода

Разбираем по косточкам, как будто собираем своего Франкенштейна — только доброго и удобного.

Лейбл (input label) — зачем подписывать, как размещать

Лейбл — это табличка на двери. Без неё ты не знаешь, куда ведёт коридор. Лейбл говорит пользователю: «Вот сюда ты вводишь имя. Не номер карты. Не промокод. Имя». Говоря проще — это название поля и какую информацию надо ввести.

• Лейбл всегда должен быть.
• Лейбл не должен исчезать при фокусе.
• Лейбл не должен быть внутри поля вместо плейсхолдера.
• Хорошо, когда он располагается сверху, а не сбоку — глаз читает форму сверху вниз.

Примеры хороших лейблов можно подсмотреть у Avito — у них формы говорят человеческим языком, а не машинным.

Плейсхолдер (input placeholder) — друг или враг

Плейсхолдер — это временная подсказка внутри поля. Его задача — намекнуть, а не объяснить. Проблема в том, что он исчезает при вводе, и всё, что он говорил — уходит в никуда.

• Никогда не используем плейсхолдер вместо лейбла.
• Используем плейсхолдер, если нужно показать пример данных.
• Делаем его светлым, неярким, но читаемым.
• Не пихаем туда инструкции по форматированию — это не его работа.

Поле (input field) — зона для текста: ширина, высота, поведение

Это то, куда попадает курсор. Самое важное.

• Высота должна быть минимум 40px, чтобы палец не промахнулся.
• Ширина — по контенту или 100%, если место позволяет.
• Не забывай про паддинги внутри.
• Фокус должен быть заметен: цвет рамки, свечение, что угодно.
• Текст внутри — чёткий, читаемый, не серый на сером, а с достаточным контрастом.

Иконка (иконка внутри поля) — лупа, крестик, глазик, стрелка

Иконки помогают:

• Лупа — для поиска.
• Крестик (backspace) — для очистки.
• Глаз — показать/скрыть пароль.
• Стрелка — автозаполнение или дропдаун (шеврон).

Важно:

• Иконка не должна перекрывать текст.
• Клик по иконке — это действие, не просто декор (хотя иногда возможно и такое).
• Иконка должна быть частью компонента, а не на глаз наложенной.

Тултипы и хелперы — как объяснять, не раздражая

Тултип — это как шёпот: «если что, вот формат». Он должен появляться по запросу, а не лезть в глаза. Хелперы — текст под полем: объясняют, дают советы, подсказывают формат.

• Хелпер не должен дублировать плейсхолдер.
• Он должен быть кратким и уместным.
• Не делай его серым на белом — его должны видеть.

Ошибки и подсказки (captions) — где, как и в каком виде

Ошибки — это честный фидбек. Лучше услышать «неверный формат», чем «ошибка 422».

• Сообщение должно быть человеческим.
• Не пугай пользователя, объясни, что сделать.
• Расположение — под полем.
• Цвет — красный для ошибок, но не ядовитый.
• Иконка рядом — плюс, если не мешает.

Интерактивные элементы — кнопки внутри, переключатели и т.п.

Иногда инпут содержит кнопки: очистить, показать пароль, подгрузить данные. Это не должно ломать флоу.

• Кнопка должна быть внутри поля, но не в ущерб тексту.
• Она должна быть доступна по табу и кликабельна.
• Если это «загрузить код» — покажи таймер, не оставляй в подвешенном состоянии.

Примеры плохой и хорошей анатомии инпута

Плохо:

• Нет лейбла, только плейсхолдер.
• Ошибки без текста, только красная рамка.
• Иконка наложена и закрывает текст или между ними недостаточно пространства.
• Фокус не виден.

Хорошо:

• Лейбл сверху, не исчезает.
• Плейсхолдер — с примером.
• Ошибка с внятным текстом.
• Подсказка про формат.
• Фокус — явный.
• Иконка — работает, а не мешает.

Посмотри на форму Сбера — их поля ввода сделаны с оглядкой на доступность и юзерфлоу. Или на Miro — минимализм, но всё по делу.

Виды input и типы полей ввода

Поля бывают разные: белые, синие, красные, под формат, без формата, с маской и без неё. Это не просто «input» — это целая армия, где каждый выполняет свою задачу. Разбираем от солдата до диверсанта.

Текстовое поле — универсальный солдат

Самое простое и самое частое. Поле input type="text", которое подходит почти подо всё: имя, город, промокод, отзыв, название компании.

• Принимает любой текст.
• Не проверяет формат.
• Лучше всего сочетается с лейблом и плейсхолдером.

Если не знаешь, какое поле нужно — скорее всего, текстовое. Но не злоупотребляй. Если данные требуют валидации, подумай, может, нужен другой тип.

Пароль (input password) — скрытый, но важный

Тип password. Показывает звёздочки или точки. UX-боль, если сделан неправильно.

• Добавляй кнопку «показать пароль» с иконкой-глазом.
• Не скрывай повторный ввод за звёздами — пользователь должен видеть, что ввёл.
• Подсказывай требования к полю пароля до ошибки, а не после.

Хороший пример — форма от Notion или Figma: там всё логично, понятно и без сюрпризов.

Поля форм email и телефон — со своими ограничениями

Email и телефон требуют не просто текста, а валидного текста. Формат инпута должен соответствовать шаблону, иначе — ошибка.

• Используй type="email" и type="tel" — это активирует нужную клавиатуру на мобильных.
• Добавляй маску или автоформат — чтобы номер сам расставлял пробелы и скобки.
• Не проси дважды ввести email, если не в банке.

Классный пример маски телефона — у Tinkoff, где поле само приводит номер к нужному виду.

Поиск — с лупой, автоподсказкой и багами

Инпут для поиска — отдельная история. На поверхности всё просто: строка, куда ты вводишь запрос. Но под капотом — ад. Автокомплит, фильтрация, кэш, дебаунс, отображение результатов.

• Иконка лупы — по дефолту.
• Можно добавлять кнопку очистки.
• Не забывай про задержку между вводом и результатами (дебаунс).
• Подсвечивай совпадения в выпадающем списке.

Хороший UX поиска — у Booking и Aviasales. Там даже начинаешь печатать — и система уже думает за тебя.

Многострочное поле (textarea) — чем отличается от input

Когда нужно ввести больше одного предложения — используем textarea. Например:

• Отзывы.
• Сообщения.
• Комментарии.

Отличия:

• Растягивается по высоте.
• Поддерживает перенос строк.
• Не всегда удобно на мобилке, поэтому тестируй.

Совет: добавь счётчик символов или автоподстройку высоты, а также максимальное значение по высоте. И не забывай про максимальную длину.

Маскированное поле ввода — карты, даты, номера

Маска — это как вождение с разметкой на дороге. Она не даёт пользователю уйти в кювет.

• Используется для карт, телефонов, дат, времени, CVV.
• Помогает визуально ориентироваться.
• Но может раздражать, если не работает с копипастом.

Маска должна быть адаптивной, позволять вставку, реагировать на backspace. Иначе UX превращается в бой с интерфейсом.

Пример хорошей маски — у Yandex Go, где дата и время подстраиваются моментально.

Автокомплит и дропдауны внутри input

Автокомплит — когда ты начинаешь вводить, а интерфейс предлагает варианты. Это может быть:

• Адрес (на основе карт).
• Название (из базы).
• Email (из сохранённого).

Важно:

• Подсвечивай совпадения.
• Управляй стрелками и enter.
• Не давай «вылетать» за рамки поля.

Смесь input и dropdown часто встречается в фильтрах, адресах, тегах. Если реализовано плохо — UX падает со скалы.

Файловые поля (upload) — как сделать не уродливо

Поле type="file" — самое уродливое из коробки. Его приходится прятать и стилизовать вручную.

• Показывай имя выбранного файла.
• Добавляй кнопку «изменить» или «удалить».
• Используй прогресс загрузки.
• Ограничивай типы и размер.

Хороший пример — у Dropbox и Google Диска. Всё наглядно, понятно и без багов.

Разграничение по типу данных и по поведению

Всё выше можно классифицировать по двум осям:

• Тип данных: текст, число, email, дата, пароль, файл.
• Поведение: ввод вручную, выбор из подсказки, маска, автокомплит, кнопки внутри.

Важно понимать: один и тот же тип данных можно реализовать по-разному. Например:

• Телефон — просто текст? Плохо.
• Телефон с type="tel"? Уже лучше.
• Телефон с маской и автоформатом? Идеально.

Состояния полей ввода, UI/UX-дизайн инпутов

Поле — как актёр в хорошем театре: в зависимости от сцены, оно должно уметь играть разные роли. Быть скромным, когда оно пустое, ярким, когда активно, и не мешать, когда не его выход. Вот почему состояния полей — это не «дополнительные стили», а сценарий поведения.

Инпут по умолчанию (default input)

Это исходное состояние. То, как инпут выглядит, когда ничего не происходит:

• нет фокуса;
• нет ошибки;
• нет данных.

Здесь важно не переусердствовать. Не надо навешивать три тени, перелив и анимацию. Это просто поле. Оно должно быть нейтральным — не привлекать внимание, но и не сливаться с фоном.

• Рамка (обычно светло-серая).
• Читаемый плейсхолдер.
• Явный лейбл.

Ховер инпута (input hover) — нужен ли он вообще

Ховер — когда курсор зависает над полем, но ещё ничего не произошло. На десктопе — полезно. На мобилке — бесполезно.

• Делать или не делать — решает продукт.
• Если делать, то еле заметное изменение: светлее фон, чуть темнее бордер.
• Ховер не должен быть агрессивным.

Многие дизайн-системы вообще убирают ховер у input'ов — и правильно. Это не кнопка, не ссылка. Ховер — не обязательный гость.

Инпут в фокусе (focus input) — визуальная реакция

Фокус — это «я готов, пиши». Поле получает курсор, пользователь начинает вводить.

• Меняется бордер (чаще всего — на синий, фиолетовый, чёрный или акцентный цвет).
• Может появляться лёгкое свечение.
• Поле визуально выделяется среди остальных.

Фокус должен быть видимым — нельзя, чтобы пользователь не понял, куда попал курсор. Контрастным, но не токсичным.

Плохо:

• Нет реакции на фокус.
• Реакция такая же, как у ошибки.

Хорошо:

• Бордер стал насыщеннее, появился индикатор, курсор мигает.

Заполненное поле (filled input) — подсвечивать или нет

Когда поле уже содержит данные, оно может выглядеть по-другому. Часто это делают, чтобы пользователь понял: «ага, я тут уже ввёл».

• Чаще всего поле просто остаётся как есть, но текст внутри — чёрный.
• Иногда применяют лёгкий фон, чтобы отличить от пустого.
• Лейбл может уменьшиться и уйти вверх (например, в Material Design).

Важно:

• Не делай так, чтобы заполненное поле выглядело как disabled.
• Не убирай лейбл — человек может забыть, что он вводил.

Неактивное поле (disabled input) — зачем его вообще показывать

Поле заблокировано. Нельзя взаимодействовать. Вопрос: а зачем тогда его показывать?

Ответ — чтобы пояснить, что оно есть, но сейчас недоступно. Например:

• Поле «ИНН» в анкете, если человек указал «не ИП».
• Автозаполненное поле, которое пока нельзя редактировать.

Выглядит так:

• Серая рамка.
• Нельзя кликнуть.
• Курсор не появляется.
• Цвет текста — тусклый.
• Контраст относительно фона — тусклый.

Не делай поле слишком блеклым — его всё равно должно быть видно. И обязательно поясняй, почему оно недоступно.

Инпут с ошибкой (error input) — как не испортить человеку вечер

Ошибка — это не наказание. Это помощь. Человек что-то ввёл не так, и ты ему подсказываешь, как надо.

Правила:

• Красная рамка — классика.
• Текст ошибки — под полем, кратко и ясно.
• Иконка ошибки рядом — если не мешает.
• Тон сообщения — доброжелательный: «Проверь формат», а не «Ошибка!».

Плохо:

• Ошибка появляется сразу при вводе первого символа.
• Нет объяснения, в чём проблема.

Хорошо:

• Ошибка появляется после блюра или сабмита.
• Текст объясняет: «Введите email в формате name@example.com».

Успешное поле (success input) — использовать или забыть

Некоторые любят подсвечивать поле зелёным, если всё правильно. Такой инпут подтверждает, что пользователь ввёл всё верно.

Если используешь success-состояние — делай его ненавязчивым. Можно ограничиться галочкой или лейблом «Всё верно».

Загрузка инпута (loading) — когда поле становится спиннером

Иногда поле зависит от внешнего запроса. Например:

• Вводишь ИНН — система проверяет в налоговой.
• Вводишь адрес — идёт запрос к картам.

Пока идёт проверка:

• Покажи спиннер.
• Заблокируй кнопку «Далее».
• Уведомь пользователя, что идёт проверка.

Главное — не оставляй поле в подвешенном состоянии. Нет ничего хуже, чем молчащий интерфейс.

Прелоад / автозаполнение инпута — как обработать корректно

Когда браузер или система вставляет данные за пользователя — это не фокус и не заполнение. Это автозаполнение.

• Не удаляй лейблы.
• Не считай, что пользователь видел плейсхолдер.
• Подстраивай поведение под это событие.

Например, Safari может вставить email и считать, что поле заполнено. Если при этом исчез лейбл — человек не поймёт, что там за данные. Будь умнее браузера.

Состояния поля — это язык интерфейса. Если ты умеешь на нём говорить, пользователь не ошибётся, не психанёт и не закроет вкладку. А значит — уже победа. Почитайте также про виды и типы ui-кнопок.

Как спроектировать удобное поле ввода

Большинство дизайнеров рисует поле по инерции. Прямоугольник, лейбл сверху, плейсхолдер внутри, два пикселя скругления — поехали. Но поле ввода — это не UI-украшение, а инструмент диалога между человеком и машиной. Если спроектировать его бездумно — этот диалог быстро превращается в немой конфликт.

Сначала думаем, потом рисуем инпуты

Проектирование начинается не с Figma. Оно начинается с вопроса: зачем здесь инпут. Что именно пользователь должен ввести? Что он ожидает? Есть ли у него шаблон поведения или ты будешь учить его с нуля?

Когда ты понял, зачем поле нужно — начинаешь думать, как оно должно работать. А уже потом — как оно будет выглядеть.

От цели — к типу поля

Если задача — собрать адрес, это не значит, что тебе нужно одно поле “Адрес”. Возможно, нужно четыре: улица, дом, корпус, квартира. Или наоборот — одно с автокомплитом.

Хочешь имя? А может быть, только имя и не нужно — человек уже в системе, и ты просто просишь псевдоним. Цель определяет структуру.

Плохой дизайн начинается с шаблона. Хороший — с понимания.

Как собрать требования для UI-инпутов и не забыть важное

Самый надёжный способ запороть поле — это не учесть, что с ним будет делать система. Требования — это не только «что пользователь вводит», но и «что backend с этим делает».

Например, система может:

• требовать определённый формат (ИНН, карта);
• не поддерживать определённые символы;
• автоматически очищать пробелы;
• сохранять только первые 50 символов.

А дизайнер об этом не знает. И рисует всё красиво — до первой продакшн-ошибки. Поэтому всегда вытаскивай требования заранее. Не стесняйся просить у аналитика, разработчика или PM-а: «А что именно здесь можно вводить?»

Исследование реальных сценариев работы с инпутами (не из головы)

Дизайнеры любят придумывать, как будет удобно. Но иногда лучше посмотреть, как реально вводят данные. Например, номера телефонов в России часто копируют из мессенджеров и вставляют в input. Там могут быть пробелы, скобки, +7 и даже текст.

Сценарии важно протестировать. Попроси коллег ввести данные в прототип. Понаблюдай, как они ошибаются. UX не живёт в теории. Он рождается в реальности.

Форматирование данных и UX-маски полей ввода в формах

Поля, в которых данные должны быть красиво отформатированы — отдельная тема. Карты, даты, паспортные номера, суммы — всё это требует маски или автоформатирования. Но у них разная роль.

Маска — это как ограничитель: пользователь не может ввести ничего лишнего. Поле ведёт его по формату, как по рельсам. Например, номер телефона с автоматическими скобками и пробелами.

Автоформат — это когда ты вводишь как хочешь, а поле потом само приводит всё в порядок. Например, ты ввёл «1234567812345678», а поле красиво разбивает на группы по 4 цифры. Такое часто используют на карточках оплаты.

Когда использовать маску, когда форматировать постфактум

Маска хороша там, где:

• формат один и тот же для всех;
• данные чувствительны к ошибке (телефон, ИНН);
• пользователь часто вводит вручную, а не копипастом.

Плохая маска — это ад. Она мешает вставить номер из буфера. Не даёт стереть один символ. И вообще — ломает UX, если сделана в лоб.

Автоформатирование подходит, когда:

• нужно поддерживать разные форматы;
• пользователь копирует данные;
• важнее удобство, чем строгость.

Всегда тестируй, как поле ведёт себя при вставке текста, при стирании, при быстром вводе. Это три разных сценария, и в каждом могут быть сюрпризы.

Адаптивность и мобильные нюансы инпутов

На десктопе всё относительно просто. Курсор, клавиатура, табы, мышка. А вот на мобилке — каждый пиксель на вес золота. Здесь поле должно быть:

• достаточно высоким (хотя бы 44px);
• с правильным типом клавиатуры (tel, email, number);
• с крупным текстом внутри;
• без микрокнопок, в которые не попасть пальцем.

Также не забывай про «следующее поле» — на мобильных люди ждут, что Enter или Next перекинет их дальше. Если этого нет, флоу рвётся.

И ещё: не забывай про баги с автозаполнением, автокоррекцией, зумом. У Safari, Chrome и Android — у всех свои приколы. Проверяй не в одной Figma, а на трёх живых телефонах.

Когда ты проектируешь поле — ты не рисуешь прямоугольник. Ты создаёшь сценарий поведения. Продумываешь диалог. Настраиваешь доверие. А если хочешь просто «чтобы было красиво» — тогда, прости, тебе лучше делать обложки для плейлистов.

Размеры, отступы, сетка инпутов ввода

Если ты хоть раз пытался сделать «просто аккуратное поле», то знаешь: размеры решают всё. Можно нарисовать гениальный ui инпут с идеальными шрифтами и цветами, а потом уткнуться в то, что он выпирает из сетки, давит на лейбл и проваливается в ад при адаптиве.

Вот почему дизайн инпута — это не про эстетику, а про математику, ритм и здравый смысл.

Как определить нужную ширину поля

Хочешь ошибиться — поставь ширину на глаз. Ширина поля должна определяться по:

• содержимому (например, поле «Индекс» не должно быть шириной в 500px);
• сетке (лучше, если ширина кратна колонке);
• адаптиву (на мобилке инпут тянется на 100%).

Если поле используется в таблице — ориентируйся на контент. Если в форме — на структуру макета. Никогда не делай поля разной ширины в одной форме без причины. Это визуальный хаос.

Высота поля: по тексту или иконке?

Высота поля — вечный спор между дизайнером и разработчиком. Одни хотят 40px, другие — 48. Кто прав? Ответ: пользователь.

Высота должна обеспечивать:

• комфортный клик/тап;
• читаемый текст;
• иконку с достаточным воздухом вокруг, если она есть.

Минимум — 44px для мобильных. Лучше — 48. Не бойся «воздуха». Удобство важнее плотности. Если иконка выше текста — не обрезай её, просто дай больше паддингов.

Отступы между элементами поля: лейбл, подсказка, поле, ошибка

Интерфейс — это не только «что», но и «где». Расстояния между элементами вокруг поля помогают понять структуру:

• лейбл имеет отступ над инпутом 8px или 12px;
• подсказка (хелпер) — на 4px ниже поля;
• ошибка — ниже хелпера, с тем же отступом.

Важно: все поля в форме должны иметь одинаковую вертикальную структуру. Это и есть читаемость. Если одни ошибки ближе к полю, другие — дальше, пользователь будет теряться глазами.

Сетка для полей в форме

Сетка — это основа хорошего дизайна input-ов. Без неё инпуты начинают жить своей жизнью: один длинный, другой короткий, третий улетел за контейнер.

Обычно в вебе используется 12-колоночная сетка. Поля выравниваются по колонкам, особенно если форма многоступенчатая. Внутри одной строки:

• поля одинаковой высоты;
• выравнивание по baseline текста (а не по нижней границе);
• одинаковые отступы между колонками.

Если делать без сетки — получаешь фрагментированный интерфейс, где каждый элемент живёт отдельно.

Автоматическое расширение поля при вводе

Иногда нужно, чтобы поле росло по мере ввода. Например:

• тег-инпуты;
• многострочные комментарии;
• поля с переменной длиной (например, название компании).

Такое поведение нужно проектировать с умом. Если поле растёт — значит, рядом с ним ничего не должно стоять. Анимация расширения должна быть плавной, чтобы не рвало верстку.

Также не забывай про лимит: даже если поле растёт, пользователь должен понимать, сколько ему можно ввести. Добавь счётчик, если нужно.

Кейсы с 100% шириной vs фиксированной

Здесь работает простое правило: если форма занимает всю ширину экрана — поля тоже должны тянуться. Если форма в колонке — ширина зависит от контекста.

100% ширины хорошо работает:

• на мобильных;
• в лендингах с одной формой;
• когда нужно упростить восприятие.

Фиксированная ширина нужна:

• для коротких данных (дата, индекс);
• в сложных UI с несколькими колонками;
• чтобы подчеркнуть структуру формы.

Главное — не мешать оба подхода без необходимости. Если одно поле длинное, другое короткое, третий с отступом в 40px — интерфейс выглядит неряшливо.

Хочешь, чтобы пользователь не путался в форме? Уважай размеры. Уважай систему отступов. И уважай сетку. В дизайне инпутов нет мелочей — только последовательность.

Текст внутри полей: плейсхолдеры, лейблы, хелперы

Если ui инпут — это дверь, то текст внутри и вокруг него — это таблички, вывески и указатели. Без них человек может открыть не ту дверь, не понять, зачем она нужна, или просто пройти мимо. Вот почему дизайн текста для input-ов важен не меньше, чем их внешний вид.

Почему плейсхолдер — это не лейбл

Плейсхолдер — это временная подсказка внутри поля. Лейбл — это название поля. Они не взаимозаменяемы. Почему? Потому что плейсхолдер исчезает, когда ты начинаешь ввод. Всё. Его больше нет. А человек уже забыл, что там надо было писать.

Ошибку, когда вместо лейбла используют плейсхолдер, делает половина лендингов в интернете. Открываешь форму — всё красиво, вводишь имя — и поле становится безымянным. UX умер.

Когда лейбл должен быть снаружи, а когда — внутри

Лучше всего — лейбл снаружи. Сверху, слева, неважно — главное, чтобы он был постоянным и читался.

Но иногда допустим и лейбл внутри поля, если он уезжает при фокусе — например, как в Material Design. Такой вариант экономит место, особенно на мобилке. Но требует:

• хорошей читаемости в обоих состояниях;
• плавной анимации;
• достаточного контраста.

Если не можешь сделать это чисто — оставь лейбл снаружи. Минимализм ради минимализма — плохой советчик в интерфейсах.

Ошибки в подписи поля

Вот топовая тройка грехов:

• Общее название. «Информация» вместо «Имя». Что за информация? Кому?
• Слишком формально. «Введите адрес электронной почты пользователя системы». А можно просто «Email»?
• Лейбл дублирует плейсхолдер. Если два текста говорят одно и то же — один из них лишний.

Хороший лейбл отвечает на вопрос: что именно здесь нужно ввести. И делает это на языке пользователя.

Инструкция под полем: формат или объяснение

Если ты просишь ввести номер карты, дату рождения, промокод — поясни формат. Причём не в плейсхолдере, а под полем. Там, где человек будет искать подсказку, когда что-то пойдёт не так.

Хорошая инструкция короткая и точная:

• «Формат: дд.мм.гггг».
• «Только латинские буквы и цифры».
• «Не более 20 символов».

Если ошибок будет много — подними подсказку повыше, чтобы она была видна до отправки.

Хинты и хелперы — как писать понятно

Хинты — это дружелюбные подсказки под полем. Они:

• помогают понять контекст;
• предупреждают о частых ошибках;
• направляют пользователя, не раздражая.

Плохо:

• «Введите корректные данные» — а какие именно?
• «Поле обязательно к заполнению» — это и так понятно по звёздочке.

Хорошо:

• «Указывайте рабочий email — на него придёт доступ».
• «Промокод действует один раз».

Пиши не как робот, а как человек. Это улучшает UX быстрее, чем редизайн всех кнопок.

Юзер-тесты на читаемость и понимание

Ты можешь быть гением microcopy, но пока ты не дал живым людям заполнить форму — всё это теория. Самый простой тест:

• показываешь форму;
• просишь заполнить вслепую;
• наблюдаешь, где они стопорятся.

Если 3 из 5 не поняли, что за поле «Код» — значит, лейбл плохой. Если кто-то указал дату рождения в формате «2003/06/25», хотя ты ждал «25.06.2003» — подсказка не работает.

Интерфейс должен объяснять себя сам. Тексты — это твои слова. Скажи их внятно.

Валидация и проверка инпутов на ошибки

Если ui инпут — это вход, то валидация — это охранник у двери. Он либо улыбается и пропускает, либо просит предъявить документы, а иногда просто молча закрывает дверь перед носом. Дизайн input-полей без продуманной валидации — это UX-рулетка. Кому-то повезёт, остальным — перезаполняй.

Когда валидировать инпут: по блюру, по сабмиту или сразу

Здесь важно соблюдать грань между заботой и назойливостью. Валидировать можно:

• по блюру — пользователь ушёл с поля, но ещё не отправил форму;
• по сабмиту — после нажатия кнопки «Отправить»;
• в режиме live — сразу при вводе.

Самый комфортный для большинства сценариев — блюр. Он не мешает во время ввода, но сразу сообщает об ошибке, как только пользователь уходит дальше. Live-валидация подходит для коротких полей, где легко отследить паттерн (например, пароль). Сабмит — последний шанс, когда все остальные способы промолчали.

Как подсвечивать ошибку инпута — цвет, текст, вибрация

Пользователь должен сразу понять: что не так, где и почему. Не через три клика, не по догадке, а сразу и явно.

• Цвет: красная рамка — стандарт. Но не кислотная. Лучше использовать оттенок, согласованный с дизайн-системой.
• Текст: простыми словами, без разработческого жаргона. Не «Ошибка 422», а «Неверный формат email».
• Анимация: лёгкая вибрация или шейк поля может усилить эффект, но не должна пугать.

Важно: визуальная ошибка не должна заменять текстовую. Цвета воспринимаются по-разному, особенно людьми с нарушениями зрения.

Где размещать сообщение об ошибке инпута

Всегда — под полем. Никогда не сбоку, не сверху, не в тултипе при наведении. Пользователь смотрит туда, куда только что вводил текст. Туда и нужно дать ответ.

Если рядом с полем уже есть хелпер, ошибка должна быть:

• либо вместо него (динамически);
• либо чуть ниже, но явно отделена.

Не забывай про отступ — ошибка не должна слипаться с полем или соседними элементами.

Иконки ошибок в полях ввода

Иконка ошибки (красный восклицательный знак или крестик) может быть полезной, если:

• она поддерживает текст ошибки, а не заменяет его;
• её можно кликнуть, чтобы узнать больше;
• она не мешает вводу (особенно на мобилке).

Плохо, если иконка просто существует и ничего не объясняет. Ещё хуже — если её можно случайно закрыть и больше не вернуть. Дизайн инпута не должен превращаться в квест с пасхалками.

Примеры хорошей и плохой валидации

Плохо:

• Ошибка появляется после первого символа.
• Нет текста, только красная рамка.
• Поле сбрасывается полностью при неверном вводе.

Хорошо:

• Ошибка появляется после блюра или сабмита.
• Текст объясняет, что не так и как исправить.
• Введённые данные сохраняются — пользователь может их поправить.

Посмотри, как реализована валидация на Tinkoff: внятный текст, логика по блюру, ничего не сбрасывается, пользователь всегда знает, что делать дальше.

UX-антипаттерны: убирается весь текст, неясное сообщение

Один из самых раздражающих UX-косяков — когда поле просто очищается после ошибки. Ты вводил номер карты, не попал в формат — бах, всё исчезло. Повтори. Заново. Лучше бы кликер поставили.

Ещё один антипаттерн — непонятные ошибки. «Что-то пошло не так». А что именно? Где? Почему?

Пользователь не должен гадать. Он не в игре. Он в интерфейсе, где каждый шаг — это потраченные нервы и секунды. Сделай так, чтобы ошибки помогали, а не карали.

Клавиатура и тип ввода при работе с инпутами

Мобильная клавиатура — это тот случай, когда дизайн инпута выходит за пределы экрана. Ты вроде нарисовал всё красиво, пиксель в пиксель. Но открываешь на телефоне — и начинается трэш: текст уезжает, поле обрезается, клавиатура перекрывает половину экрана.

Чтобы этого не случилось, надо понимать, как работает input в мобильной среде и проектировать с учётом этих сценариев.

Выбор типа клавиатуры: email, tel, numeric

Одна из самых простых и часто забываемых вещей — подобрать правильный тип клавиатуры под поле. Когда ты проектируешь дизайн input-а, ты влияешь на то, какая клавиатура откроется у пользователя.

• Для email — клавиатура с @ и точкой.
• Для телефона — цифровая.
• Для промокодов — обычная текстовая, но без автозамены.

Если тип клавиатуры не совпадает с содержанием поля, пользователь будет страдать: переключать раскладку, стирать автозамену, злиться. А нам это не надо.

Автозаполнение и автокоррекция

Сценарий простой: пользователь жмёт на поле, а браузер сам подставляет данные. Но из-за автозаполнения легко запороть лейблы, контекст и UX.

Например, если лейбл исчезает, а поле заполнено системой — человек видит данные, но не понимает, что это за поле. Или если поле с логином вдруг получает первую заглавную букву.

Проектируя поля, нужно оставлять постоянный лейбл, даже если поле автозаполнено. А в полях, где важна точность, лучше отключить автозамену и капитализацию.

Что делать с переходом между полями

Когда человек заполняет форму, он хочет «плыть» по ней. В идеале — нажимает «далее» и перескакивает в следующее поле. Это создаёт ощущение ритма и контроля.

Если переход не работает, пользователю приходится вручную тапать в каждый input. А на мобилке это превращается в UX-провал.

Когда проектируешь форму, сразу подумай: где логичный порядок фокусировки? Можно ли двигаться по ней вслепую? Где будет финиш?

Инпут на 100% экрана или нет

Иногда кажется, что поле должно быть шириной в весь экран. Особенно на мобилке. Но всё зависит от контекста.

• Для поиска — да, пусть занимает всё.
• Для ввода коротких данных (дата, индекс) — нет смысла.
• В многоступенчатых формах лучше сохранять структуру и пропорции.

Если поле визуально «утопает» в ширине или, наоборот, обрезается в мобилке — это сигнал, что его стоит адаптировать.

Подсказки на мобильной клавиатуре

На мобильных клавиатурах есть свои приколы: они могут подсказывать слова, адреса, предыдущие вводы. Иногда это удобно, иногда — мешает.

Поле должно быть «немолчащим»: если автозамена потенциально испортит ввод, об этом стоит предупредить. Например, в полях с кодами, логинами, промо — лучше отключать автоматические исправления.

Фиксация фокуса на инпуте, чтобы не уехал весь экран

Классическая боль: ты тапнул в поле, открылась клавиатура — и весь интерфейс уехал наверх. Или поле скрылось за клавиатурой. Пользователь начинает скроллить, искать, терять контекст.

При проектировании инпутов важно понимать: поле должно оставаться в зоне видимости, даже когда экран сжался. Это можно учесть в макете, проверить на прототипе и заранее продумать, как будет вести себя форма при активации.

UX-правила хорошего тона при работе с полями

Если ты делаешь интерфейс, то невольно становишься вежливым (или не очень) собеседником. Поле — это форма общения. И как в жизни, тут работают простые правила приличия. Дизайн инпута — это не только рамка и цвет ошибки, но и тон, интонация, уважение к человеку по ту сторону экрана.

Не проси больше, чем нужно

Чем больше ты просишь от пользователя, тем меньше шансов, что он дойдёт до конца. Особенно если инпут не очевиден.

• Не надо спрашивать «Отчество», если ты его не используешь.
• Не проси ввести номер телефона, если ты не собираешься звонить.
• Не вываливай 15 полей там, где хватит двух.

Каждое поле — это фрикция. Хочешь высокую конверсию — снижай её, не поднимая планку лишними вопросами.

Подскажи формат, но не командуй

Никто не любит, когда им указывают, как писать. Но если ты не дашь ориентир — пользователь ошибётся, и ты же будешь его наказывать.

Решение — тактичная подсказка. Не caps lock, не «ОБЯЗАТЕЛЬНО ВВЕДИТЕ В ФОРМАТЕ», а нормальным человеческим тоном:

• «Формат: дд.мм.гггг».
• «Только латинские буквы».

Подсказка работает, если её видно. Лучше разместить её под полем, чем спрятать в тултип или заставить догадываться по placeholder’у.

Всегда указывай ошибку поля, не кидайся на пользователя

Ошибка — не повод для драмы. Она должна быть понятной, доброжелательной и полезной. Поле не должно «орать» на пользователя, если он сделал что-то не так. Оно должно объяснить.

Плохой пример: красная рамка и надпись «Ошибка».

Хороший пример: «Введите email в формате name@example.com».

Идеально — если ошибка появляется после завершения ввода, а не при первом нажатии клавиши. Не заставляй человека чувствовать себя тупым.

Одна строка — один вопрос

Инпут должен спрашивать что-то одно. Не два вопроса в одном. Не «Имя и фамилия» — раздели. Не «Ваш город или регион проживания» — выбери одно.

Когда ты даёшь одно поле на несколько смыслов, ты получаешь мусор на выходе. Пользователь гадает, как правильно, и вводит что попало.

В интерфейсе, как в анкете: один вопрос — один ответ.

Оставляй свободу: возможность очистить, отменить

Хороший UX инпутов — это не только путь вперёд, но и возможность сделать шаг назад. У поля должен быть механизм отмены:

• крестик внутри поля для очистки;
• кнопка «отменить» или «сбросить форму»;
• возможность править уже введённое.

Пользователь должен чувствовать, что он в безопасности. Что он контролирует процесс, а не система.

Поддерживай accessibility инпутов

Твой интерфейс может быть идеальным снаружи, но недоступным внутри. Поля ввода должны быть читаемы, контрастны, логичны по фокусу. Особенно важно:

• не использовать текст как единственный способ передачи ошибки (цвет дублируем текстом);
• делать лейблы постоянными, а не исчезающими;
• избегать анимированных исчезающих подсказок.

Accessibility — это не опция, а базовая вежливость. Поле должно быть удобным для всех.

Используй таб-логику и визуальную последовательность

Пользователь должен иметь возможность пройти форму по табу — без мышки, без лишнего клика. Проектируя форму, представляй, как человек будет по ней двигаться:

• сверху вниз;
• слева направо (если поля в одной строке);
• последовательно, без скачков и зигзагов.

Проверяй порядок полей. Он должен соответствовать визуальной структуре. Не путай пользователя в пространстве, даже если ты сам всё понимаешь.

UX — это этика. Если ты не заставляешь, не пугаешь, не сбиваешь с толку — ты уже молодец.

UI-дизайн Text Input в Figma

Figma — это не только про пиксели. Это про мышление. Если ты хочешь сделать по-настоящему работающий компонент поля ввода, тебе придётся думать не как художник, а как инженер. Иначе в итоге получишь макет, который красиво выглядит, но не живёт.

Как структурировать компонент поля

Хороший компонент input’а должен быть как сэндвич: слои чётко лежат друг на друге, ничего не разваливается. Структура может быть такой:

• Контейнер поля (Frame или Auto Layout).
• Лейбл (если он внешний).
• Само поле (background + текст).
• Плейсхолдер (если есть).
• Иконка (если нужна).
• Хелпер или ошибка (в отдельном фрейме под полем).

Всё должно быть в одном компоненте — не надо выносить ошибки отдельно, это потом аукнется в разработке. Как сделать компонент в Figma >

Варианты и состояния через Variants

Figma Variants — твой лучший друг, если ты хочешь передать не просто картинку, а поведение. Делай разные состояния компонента:

• Default
• Hover
• Focused
• Disabled
• Error
• Success

Удобно объединить всё в один компонент через Variants с параметрами state, size, withIcon. Это поможет тебе и команде не плодить копии и держать дизайн инпутов в порядке.

Не забывай называть варианты понятно: State=Focused, Icon=True — это не только дизайнеру приятно, но и разработчику потом легче ориентироваться.

Использование Auto Layout

Auto Layout — не опция, а обязанность. Поле должно вести себя как живой организм: расширяться, сжиматься, подстраиваться.

• Задай паддинги по бокам и по вертикали.
• Размести текст по центру или по базовой линии — не на глаз.
• Иконки внутри поля должны быть частью Auto Layout, а не наложены сверху.

Auto Layout помогает сохранить визуальное равновесие и избежать «поехавших» полей в разных ситуациях.

Подключение иконок

Если в поле нужна иконка — используй компонент или Instance. Не рисуй иконку вручную, не вставляй SVG просто так, не пеки на месте.

Иконка должна быть:

• выровнена по центру вертикали;
• с фиксированным отступом от текста;
• скрываема, если она не всегда используется (например, «показать пароль»).

Проверь, чтобы при удалении иконки поле не ломалось визуально. И помни: иконка — это часть поведения, а не просто декор.

Работа с текстом и плейсхолдерами

Для текста внутри поля используй отдельный текстовый слой. У него должны быть:

• базовый стиль для текста;
• альфа-версия стиля для плейсхолдера (более светлый);
• явное различие по цвету, чтобы не путать с введённым текстом.

Если делаешь smart-поле с лейблом внутри (в духе Material), следи, чтобы при фокусе лейбл поднимался вверх — это можно анимировать через интерактивные компоненты или показать как два состояния.

Советы по передаче компонента разработчику

Передача компонента — это тоже часть дизайна. Не кидай разработчику инпут с подписью «ну, тут понятно». Вот что стоит сделать:

• Назови все слои осмысленно: не «Rectangle 203», а «Field Container».
• Пропиши в описании, какие есть состояния.
• Объясни, где появляется ошибка, где плейсхолдер, где лейбл.
• Если используешь Variants — покажи, как переключать.

Компонент в Figma — это не просто визуальный блок. Это инструкция по поведению. Сделай её понятной — и команда скажет тебе спасибо.

Input Field в дизайн-системе

В одном экране поле — просто элемент. В дизайн-системе — оно становится существом с биографией. У него есть свойства, поведение, ограничения и родственники. И чем лучше ты это опишешь, тем стабильнее будет весь интерфейс. Посмотрите примеры мировых дизайн систем здесь.

Как описать поле в документации

Описание поля должно отвечать на три вопроса:

• Что это за поле.
• Где и когда его использовать.
• Как оно себя ведёт в разных состояниях.

В документации достаточно одной таблицы, пары примеров и скриншотов. Но они должны быть точными. Не «Пример инпута», а «Поле с маской телефона, с иконкой и подсказкой в состоянии focus».

Добавь интерактивный пример или ссылку на Figma-компонент — так человек быстрее поймёт механику.

Перечень состояний, параметров, масок

Пользовательский input — штука многоликая. В дизайн-системе он должен быть описан с указанием всех состояний:

• default;
• hover;
• focused;
• filled;
• disabled;
• error;
• success;
• loading.

А также параметров:

• с иконкой / без иконки;
• с маской / без маски;
• с плейсхолдером / без;
• тип данных: текст, email, пароль и т.д.

Если у поля есть маска — покажи, как она работает. Желательно не просто словами, а интерактивным примером или gif-анимацией. Чем нагляднее, тем меньше шансов, что его будут использовать неправильно.

Компоненты в библиотеке

Input в библиотеке — это не один компонент, а целая семейка:

• базовый текстовый input;
• многострочное поле (textarea);
• поле с маской (например, телефон);
• поле с иконкой (поиск, крестик);
• поле с label inside (в стиле Material);
• специальные поля: поиск, промокод, фильтр.

Они могут быть объединены в один Variants-компонент или лежать рядом как самостоятельные. Главное — чтобы у них была единая визуальная и поведенческая логика.

Как сделать универсальное поле

Универсальный input — это не поле, которое делает всё, а поле, которое масштабируется без боли. Его легко адаптировать под задачу, и он не ломается, когда нужно добавить новый статус или тип ввода.

Принципы универсальности:

• чёткая структура (лейбл, плейсхолдер, текст, иконка);
• управляемые параметры (например, через свойства Variants);
• предсказуемое поведение во всех состояниях.

Если поле начинает «сыпаться», когда к нему добавляют ошибку, — оно не универсальное. Оно уязвимое.

Взаимодействие с другими компонентами формы

Поля редко живут одни. Они всегда в окружении:

• UI-кнопки, например «Отправить»;
• чекбоксы (согласие на обработку);
• дропдауны (страна, город);
• радиокнопки (пол);
• пояснения и ссылки.

Дизайн-система должна предусматривать, как компоненты будут работать вместе:

• отступы между ними;
• выравнивание по вертикали;
• логика валидации сразу нескольких полей.

Если ты просто делаешь поле красивым, оно будет конфликтовать с соседями. Если думаешь о форме как о целостной структуре — всё начнёт работать как ансамбль.

Контроль качества и проверка на баги

Инпут — это как лифт: ты не думаешь о нём, пока он не застрянет. Поэтому в дизайн-системе должно быть предусмотрено:

• тестирование всех состояний (можно чеклистом);
• визуальная проверка на адаптивах (мобилка, десктоп);
• наличие описания для edge-кейсов (маска + ошибка, фокус + disable).

Идеально — когда ты сам можешь открыть компонент в Storybook или Playground и потыкать в него в реальном времени. Но даже в Figma достаточно включить все вариации в один фрейм — и внимательно пройтись глазами.

Хорошая дизайн-система — это не библиотека компонентов, а система договорённостей. Поле ввода в ней должно быть не просто нарисовано, а описано, протестировано и понятно любому, кто с ним столкнётся.

Итог по работе над UI/UX-дизайном инпутов

Поле ввода — это не просто технический элемент. Это точка входа, голос интерфейса, мост между намерением пользователя и действием, которое совершит система. Через поле человек отдает тебе свои данные, делится контактами, вводит пароль, оставляет комментарий, пишет свой адрес. Это акт доверия. И то, как ты оформишь это взаимодействие, определяет — останется ли он с тобой или уйдёт.

Поля могут быть незаметными, но именно в них рождается удобство. Когда пользователь понимает, что от него хотят, когда всё работает как ожидалось, когда ошибки объяснены, а формат помогает, а не мешает — это и есть тот самый хороший UX, о котором мечтают команды и пишут в кейсах.

Если ты только начинаешь путь в интерфейсном дизайне — запомни одну вещь. Не с карточки товара начинается удобство. И не с красивого хедера. Всё начинается с input’а. Потому что именно в этот момент пользователь начинает говорить с продуктом. Сделай этот момент понятным, добрым, надёжным. Сначала поле. Потом космос.