Сегодня задача очень простая: надо в карточке контрагента добавить флаг «Работает с НДС». Ну, тут всё просто. Открываю Axure, иду на страницу редактирования контрагента и вставляю там чек-бокс между полями «ИНН» и «Заметки».
Опытные разработчики сразу по картинке увидят, в чём косяк такого решения. А я вот что-то зазевался. И пошёл дальше, в карточку контрагента…
Прикинул, как это выглядит в карточке. Получилось вот так.
Задался вопросом — а что, если пользователь галочку не поставил? Мы просто не показываем этот параметр, потому что он пустой? Или пользователь осознанно хотел сказать, что контрагент с НДС не работает? Блин! Решение с чек-боксом не очевидно для пользователя и не подходит для системы для системы.
Я использовал элемент, который умеет работать только с двумя состояниями («вкл», «выкл») там, где нужен элемент, умеющий работать минимум с тремя состояниями («вкл», «выкл», «ни вкл, ни выкл»).
Возвращаюсь к странице редактирования контрагента. Меняю чек-бокс на выпадающий список.
Теперь пользователь может осознанно не заполнять этот параметр (например, если не знает, работает или нет контрагент с НДС) и так же осознанно выбрать из предложенных вариантов.
Формулирую задачу для Codex (это нейросеть, предназначенная для программирования):
Отдельный контрагент. Форма создания-редактирования. Нужно добавить новое поле для контрагентов с типами «Юридическое лицо» и «ИП» (для физлиц не нужно). Размещаем это поле под полем «ИНН» (и над полем «Заметки»).
Работа с НДС — выпадающий список с тремя вариантами: «Выберите вариант» (выбран по умолчанию), «Работает с НДС», «Работает без НДС».
Отдельный контрагент. Карточка контрагента (вкладка «О контрагенте»). Показываем блок «Работа с НДС» только в том случае, если был выбран какой-то вариант, кроме «Выберите вариант».
Вместо резюме. Какие вопросы проектировщика уберегли от плохого интерфейса?
Какое значение параметра формы по умолчанию?
Как отображается результат, если пользователь не изменял этого значения?
Нужно ли в результате отображать параметр, если его значение было пустым?
На самом деле вопросов больше, но для этого конкретного примера хватит и трёх. И да, Codex справился бы и с задачей «Добавь чек-бокс, с помощью которого можно указать, работает ли контрагент с НДС». Но справился бы по какой-то своей логике.
Пост коротковат для статьи, но в посты нельзя вставлять больше одной картинки.
Комментарии (7)
RieSet
03.02.2026 13:30Я конечно не знаю ЦА, задачи и контекста, но это сложно назвать интерфейсом
Прототип - да, наверно
Если детальнее, то интерфейс неразрывно связан с ЦА для которой делается и задачами перед интерфейсом. Это какой-то очень грубый подход к интерфейсамТеперь пользователь может осознанно не заполнять этот параметр (например, если не знает, работает или нет контрагент с НДС) и так же осознанно выбрать из предложенных вариантов.Это предположение может исходить только при знании ЦА и задач интерфейса. Иногда, при знании особенностей реализации БД в системе и требований к полноте данных сохраняемых в системе
При отображении:
- Для профи (сотни карточек в день) важнее структурная целостность, чтобы ничего не скакало, а значит лучше отображать какое-то значение всегда или его отсутсвие
- Если одни пользователи создают записи а другие смотрят - логика будет немного иная
- Если пользователи обычно просматривают только одну запись и больше не возвращаться к интерфейсу, они должны знать, что у данного контрагента значение не было указано, но поле существует
Ivnika
03.02.2026 13:30Что мешает на итоговой форме выводить просто фразу "Работает с НДС" и наоборот? Зачем прямо обязательно наименование поля?
MrShnaider
03.02.2026 13:30Этот пример подтверждает мою теорию о моделях в интерфейсах. Я пытался понять, какой минимальный набор моделей (элементов) достаточен, чтобы создать интерфейс любой сложности. И пришёл к выводу, что чек-бокс как модель не является необходимой.
Если мы даём пользователю сделать выбор, то его можно отобразить как select "1-из-многих" или "много-из-многих". Как следствие в коде и БД вместо Boolean будет Enum. Так мы не только сокращаем количество моделей (уйдут чекбоксы, радио-кнопки, переключатели), но и позволим себе расширять список вариантов, когда это потребуется
killyself
03.02.2026 13:30Да ни один элемент не является "необходимым". Можно ввод информации организовать на кнопках. Можно кнопки организовать на любом поле ввода через ввод оп-кода. Вопрос удобства, эргономики, скорости работы. Чекбокс быстро считывается, особенно в колонке чекбоксов, быстро кликается и легко обрабатывается дальше в коде. Главное - трижды подумать, а действительно ли значений ровно два и иначе быть в мире не может.
sweetgrandma
03.02.2026 13:30По-моему как раз чекбокс идеально задачу решал, селект подразумевает обязательный выбор
vadimk91
Я конечно мимокрокодил, но вместе с вариантами "работает с", "работает без" я бы добавил третий "неизвестно" или "нет данных", а не "выберите". Это как приказ что-то выбрать другое, imho