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

Разумеется, как всегда оказалось, что дело не в недостатке свежих идей. Дело в том, что никто не хочет делать обычную работу проектировщика: выделять сценарии, применять теорию близости и закон Фиттса, редактировать текст. Хороший интерфейс появляется не в результате озарения, а в результате вдумчивого проектирования. Но, похоже, большинству людей это кажется скучным и занудным, и они мечтают, чтобы у них хороший интерфейс появился как-нибудь чудом.

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

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

Нормальный архитектор-дизайнер смотрит на это и думает: почему он занимается всей этой ерундой вместо дела? Но архитектор-дизайнер с «продуктовым подходом» знает, что всё делает правильно!

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

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

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

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

Сортировка — это когда у вас есть массив данных, и вы выбираете в каком порядке показывать эти данные: по убыванию цены, по возрастанию рейтинга или по дате изменения.

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

Если у вас 1183 записи, то как их ни сортируй, их останется 1183, а при фильтрации будет показана только их часть.

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

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

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

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

Отсортировать по району можно: сначала показать записи из Аннина, потом из Бутова, потом из Внукова. Придётся ещё решить, как сортировать записи уже внутри района, ведь их явно будет много в каждом. Но вот отсортировать «по конкретному району» невозможно: это всё равно что отсортировать всех по конкретному росту 172 см.

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