До оформления заказа осталось выбрать доставку. Открываешь список, видишь «Самовывоз» и «Курьер», выбираешь второе. И только теперь узнаёшь стоимость. Возвращаешься к самовывозу, чтобы посмотреть его условия, затем снова к курьеру. Всего два варианта, а для сравнения приходится несколько раз менять ответ.
Такой список мог появиться по вполне понятной причине: он компактный, есть в библиотеке компонентов и подходит по стилю к остальной форме. Но человеку сейчас нужно увидеть условия рядом. Возьмём учебное оформление заказа и пройдём дальше: способ доставки, настройку числа записей и выбор населённого пункта. У этих действий разная логика, хотя каждое можно назвать словом «выбор».
Когда нужно увидеть оба варианта
Для самовывоза можно сразу показать «Сегодня, бесплатно», а для курьера «Завтра, 1 500 ₸». Если расположить варианты друг под другом и добавить радиокнопки, человек сравнит условия до выбора. Ему уже не придётся держать в голове то, что было написано в закрывшемся меню.
Радиокнопки подходят, когда ответ может быть только один. Если человек вправе отметить несколько услуг, понадобятся чекбоксы. При этом не обязательно выбирать первый вариант заранее только ради заполненного макета: в новом вопросе готовый ответ легко пропустить. В настройке уже работающего сервиса ситуация другая, потому что там полезно показать текущее значение. Так что начинать стоит с вопроса, выбираем мы новый ответ или меняем существующий.
Где компактный список к месту
Теперь представим кабинет с платежами. Под таблицей стоит настройка «Строк на странице»: 20, 50 или 100. Значения короткие, знакомые и не требуют пояснений о цене или сроке. Человек уже знает, чего хочет, поэтому раскрыть список и выбрать 50 вполне удобно. Держать три большие карточки под таблицей было бы странно: второстепенная настройка заняла бы слишком много внимания.
При выборе такого компонента остаётся проверить, как он работает с клавиатуры и на телефоне. Нарисованная стрелка ещё не делает список удобным для выбора. Если стандартный элемент браузера решает задачу, у него есть преимущество: многие привычные способы управления уже предусмотрены. Собственный компонент тоже возможен, но его поведение придётся сделать и проверить.
Когда название уже известно
Вернёмся к заказу и попробуем выбрать город. Листать сотни населённых пунктов неприятно именно потому, что ответ уже есть в голове. Человеку не нужно знакомиться со всем справочником, он хочет найти свою запись. Поэтому ввод начала названия здесь помогает больше, чем длинное раскрытое меню.
Но поиск приносит свои вопросы. По запросу «Алм» могут появиться Алматы и несколько населённых пунктов с названием Алмалы. Чтобы выбрать нужный, рядом потребуется область. Если ничего не нашлось, введённый текст должен остаться на месте, чтобы его можно было поправить. А когда сервис принимает только записи из справочника, поле должно объяснять это ограничение: свободно набранное название не стоит молча считать выбранным адресом.
Посмотреть, как выбор приходится исправлять
На хорошем примере любой компонент работает: короткие названия помещаются, нужный ответ находится, первый выбор сразу оказывается верным. Поэтому следующая проверка начинается с менее удобных данных. Возьми длинное название организации, две похожие записи и запрос без результатов. Затем выбери значение и попробуй убрать его, если поле необязательное.
Именно здесь становится видно, помогает ли элемент закончить задачу. Радиокнопки раскрывают условия для сравнения, короткий список экономит место у знакомой настройки, поиск сокращает путь к известному названию. Когда ясно, что делает человек, решение обычно находится быстрее, чем в споре о том, после какого количества вариантов пора менять компонент.
