Это такой принцип в интерфейсе — называется «дай нажать».

Приведу три примера.

Группа чекбоксов с одним обязательным

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

То есть нужно, чтобы человек выбрал уведомление хотя бы одним каким-то способом, но может накликать и несколько.

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

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

Лучше так: при отключении последнего чекбокса, сразу включать какой-то дефолтный, скажем, «письмом». А если я его отключил последним, то включать второй по предпочтительности, скажем, «по телефону». Так интерфейс не будет мне мешать нажимать куда я хочу, но и не даст оставить недопустимое состояние.

Чекбокс и поле

В настройке комментариев в Эгее есть чекбокс «присылать по почте», которому подчинено поле адреса:

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

Можно было бы блокировать поле пока чекбокс выключен — всё равно заполнять его нет смысла. Но это бесит. Может, я хочу заполнить адрес, а потом включить чекбокс? Ещё хуже было бы не давать выключить чекбокс, если адрес заполнен. Я же хочу выключить, дай нажать!

Лучше так: давать заполнить поле, даже если чекбокс выключен; включать чекбокс автоматически, как только в поле что-то вписали. В обратную сторону — аккуратнее: если чекбокс сняли, стирать адрес из поля не надо, мало ли. Пользовательские данные обладают бесконечной ценностью.

Выбор даты

Вот возможный вариант реализации выбора даты рождения в интерфейсе:

Как вы знаете, некоторых дней не существует в природе, например не бывает 31 июня. А 29 февраля в некоторые годы бывает, а в некоторые — нет.

Чтобы не дать пользователю ввести несуществующую дату, некоторые разработчики убирают из поля дня несуществующие дни. То есть если выбран месяц июнь, то дня «31» просто не будет в выпадайке. Но что, если у меня день рождения 31 августа? Я хочу ткнуть в 31, а потом выбрать август. Дай нажать!

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

Лучше так: при вводе дня, несовместимого с текущим выбранным месяцем, развыбирать месяц —

Если я выбрал 29 февраля, а выбранном году такого нет, развыбирать год.

Отчасти похожая мысль — кнопка «Купить» всегда доступна.

Вы уже знаете, что список — это однородные члены. Сегодня — о том, когда ставить список, а когда нет.

Иногда списками на сайтах и в рекламе оформляют разные хорошие свойства товаров:

Но когда человек видит список, он читает два-три пункта и мысленно продолжает «и так далее». Если самое важное находится в пятом элементе списка, об этом уже никто не узнает.

Поэтому если нам важно донести до человека преимущества продукта, стоит внести разнообразие в подачу:

Справа — то, как гавайский автопрокат Энви показывает разные особенности сдаваемых машин.

Представьте, что вы пришли в магазин и вас встретил продавец. Он не станет перечислять монологом все преимущества товаров и самого магазина; он будет упоминать о них по мере ответа на ваши вопросы или «заодно» с показыванием товаров. Вот так и тут.

Когда вы как дизайнер предлагаете такую «журнальную» подачу, клиент может иногда засопротивляться: «Тут всё перемешано, наши преимущества не видны, давайте покажем их в одном месте списком!» Надо объяснить клиенту, что если показать списком, то тем более не будут видны.

Но это если нам важно донести до человека.

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

Справа снизу с галочками перечислены все «плюшки». Здесь человек близок к расставанию с деньгами, и он захочет убедиться, что ничего не забыл. Поэтому оформлять такую штуку «нелинейно» было бы негуманно.

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

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

А вот Айфон показывает, что нового в обновлении:

Это скучный экран, но он тут и не пытается продать это обновление. Он просто информирует человека. Мне может быть самому важно убедиться, что определённый баг исправлен.

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

Сначала написал это в своём телеканале, потом решил перенести сюда.

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

Я спрашиваю, что надо сделать, чтобы подключиться. Прошу не подсказывать тех, кто говорит по-венгерски. Все говорят: «нужно поставить галочку и нажать на кнопку!».

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

Это иллюстрирует важность привычек. Мы обычно даже не читаем, что написано, если интерфейс выглядит привычно, а просто действуем по аналогии с тем, как действовали бы в другом интерфейсе.

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

Вот, например, экран покупки билетов на метро одной из участниц. Здесь можно выбрать один или несколько билетов и тут же начать вносить купюры. Как только денег хватит, автомат выдаст билет и сдачу:

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

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

Есть такая засада, когда вёрстка пытается использовать прямоугольность фоток, а фотки этому сопротивляются, потому что пересвеченые:

Конечно, лучше всего такие фотки заменить нормальными. Но предположим, что это почему-то невозможно. Фотограф в отпуске, открываться нужно через 15 минут.

Можно попробовать взять такие фотки в рамки:

Но это выглядит фигово. Особенно, если соседствуют и такие и такие:

Намного лучше немного подтемнить фотку с нужной стороны. Я тут ещё и подсинил чуток, так как это снег:

Можно ещё попытаться вытянуть хоть какую-то текстуру снега, чтобы он не выглядел таким плоским, но это уже не касается вёрстки, а касается обработки фото.

Это копипейст из канала в телеграме. Это бы попало в стенограмму за 5—11 февраля, но я выкусил и делаю отдельной заметкой. Заметку помог подготовить Вениамин Векк.

Звёзды не надо делать пухлыми. Они выглядят дебильно:

Вот эта штука должна быть прямой линией:

Звезда здорового человека, короче, такая:

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

Сергей Чикин пишет: «Если ты Энгрибердс, то пухленькие — норм».

Это копипейст из канала в телеграме. Это бы попало в стенограмму за 5—11 февраля, но я выкусил и делаю отдельной заметкой. Заметку помог подготовить Вениамин Векк.

На курсе и в книге я рассказываю о повышении информативности. Большинство интерфейсов, которые мы видим вокруг, низкоинформативны: не показывают то, что нужно для принятия решения. Например, знаки вопроса в сложных формах, по которым открываются попапчики с объяснениями полей — что за тупизм? Объяснения должны быть прямо в форме.

Вот завалялась картинка:

Я сначала случайно прочитал day light вместо day flight и подумал: ого, они показывают, с какой стороны будет солнце! Вот вам пример повышения информативности. Это полезно, это влияет на выбор места (обычно я в уме представляю, как полетит самолёт и где будет солнце, чтобы ни дай бог не попасть под него).

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

Что мне толку с того, что вариантов именно 26? Как это повлияет на моё желание перейти по ссылке? Меня-то интересует, есть ли там что-то подходящее. Лучше написать, что за варианты: со шнурками и без, с прорезиненной подошвой. Или показать превьюшечки.

Количество имеет смысл, например, тут:

Число позволяет мне оценить, сколько работы меня ждёт (а окружающим — умею ли я пользоваться почтой; это, конечно, не мой скриншот). Если я недавно видел 2, а теперь вижу 5, я понимаю, что пришла новая почта.

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

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

Замкнутость — это что-то вроде математически полной продуманности интерфейса, когда все случаи рассмотрены и противоречия разрулены. Может, не очень удачное слово, но пока такое. Я имею в виду, все пути в интерфейсе ведут в какие-то имеющиеся состояния внутри интерфейса.

Разумеется, когда интерфейс уже реализован, он неизбежно замкнутый — так уж работает компьютер, что всё к чему-то да приведёт. Но меня волнует именно процесс проектирования. У начинающих дизайнеров постоянно такая фигня, когда не продумываются даже самые очевидные случаи.

Давайте вот разберём пример.

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

А потом где-нибудь в описании пишет:

В поле работает автодополнение. Оно помогает ввести значение, которое ранее уже вводили. Если подходящих значений несколько, подставляет в самом поле самое часто используемое, а снизу рисует выпадайку, в которой можно выбрать из них. Достаточно, чтобы совпало хотя бы одно слово, например если уже вводили «ремонт часов», предлагает этот вариант по «ча».

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

На самом деле их несколько, но разберём главный. Что конкретно будет в поле, когда я введу «ча»? Если автодополнение просто дописывает кусок в конце, то «ремонт часов» в поле никак не может появиться.

Дизайнер уходит думать и возвращается с уточнением в описании:

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

А сейчас видите дыру?

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

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

То есть выпадайки должны как-то по-разному себя вести, что ли, в зависимости от того, в первом ли слове нашлось совпадение? Или в первой выпадайке тоже можно как-то развыбрать?

Вот, например, в первом случае я могу нажать бекспейс, и тогда у меня останется просто «а».

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

Так ведь? А что тогда во втором случае, если нажать на стрелку вниз, будет?

Так что ли?

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

Тут дизайнер перестаёт писать описание и начинает латать дыры на лету. Говорит, «давай в этом случае сделаем, чтобы бекспейс стирал всё дописанное и возвращал исходное „ча“, и стрелка вверх тоже».

Но такой патч ничего не замыкает, а только сильнее размыкает. Теперь у нас появляется какое-то особое состояние интерфейса, когда бекспейс работает не как обычно. И надолго ли это состояние сохраняется? Например, если я введу „с“, будет ведь вот так:

И это согласно исходному описанию, безо всяких поправок — ведь сейчас уже начало введённой строки совпадает с началом единственного подходящего варианта, и выпадайка не нужна. Но посмотрите ещё раз на предыдущую картинку. Какого хрена там делала выпадайка в точно такой же на вид ситуации? И почему выпадайка пропала при вводе буквы „с“? Уже совсем трудно предсказать, что сделает бекспейс. Помнит ли он ещё, что слово «ремонт» тут «ненастоящее»?

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

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

Я на этом возьму паузу, а вам всем домашка: замкнуть этот интерфейс.

И ещё почитайте про автодополнение через выделение.

Сим постом хочу призвать вас внимательнее относиться к иконкам человечка в ваших приложениях.

Вот что находит «Наун-проджект» по запросу user:

Самый правый в средней строке хоть на что-то похож.

Такая жесть повсюду вокруг нас. Яндекс-музыка:

Исполнитель имеет признаки человека, но пользователь — это почему-то круг с полукругом.

Виндоус:

Гайдлайны Андроида предписывают ставить жуткую иконку. Звучат слова human и best:

Ну не знаю. По-моему, не хьюман и не бест.

Любое упрощение имеет свои пределы. У Эпла головы людей похожи на головы — есть уши, причёска (слева):

Голова превращается в круг (справа) только в масштабе всего человеческого тела. В этом случае для человеческого облика хватает остальных деталей.

Для «Секьюриджа» я нарисовал клёвых ребят с причёсками (посередине):

Даже на пропуске (справа снизу) у головы и плечей человеческая форма.

Иногда хочется, чтобы человек на иконке не имел пола. Но даже в этом случае можно найти нейтральную причёску. Вариант Серёги Чикина:

Читаются мальчик и девочка, но если оставить только одного персонажа, вполне можно и использовать независимо от пола.

Ещё в программах часто пол можно угадать по имени и подсунуть подходящую иконку.

Для «Бёрдвью» мы когда-то придумывали генератор юзерпиков для тех, кто не загрузил фотографию:

Получались всякие такие:

А вот иконка «Иконверка»:

Вот ещё. Хоть какая-то форма:

Правда, он даже если просто круг рисует, получается хорошо:

Но тут снова масштаб почти всего тела. И прекрасно подобраны пропорции и форма остального тела.

Симпатичный чувак с Иконфайндера:

А у «Вконтактика» — фигня:

Короче. На иконке человека должен быть человек, а не снеговик.