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

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

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

Одна из главных особенностей города — мучительная рельефность.

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

В сочетании с плохо работающим такси и отсутствием нормальной системы оплаты транспорта это всё делает город очень недоступным.

Но, конечно, красиво, когда видно так далеко:

Трамвайчик:

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

Типа такого:

Ну или можно плавать на паромах туда-сюда с таким видом:

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

Ещё один красивый вид далеко:

Непонятное:

Тут слева видна уличная табличка — не трудно догадаться, что про них будет отдельный большой пост:

Тут тоже видна, но это какая-то нестандартная, про такие поста не будет:

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

Пока на этом всё.

Фотографии из поездок в сентябре и октябре 2022 года. Слетайте в Стамбул!

В отелях принято заселяться около 14 и выселяться около 12. На плюс-минус час может отличаться или можно договориться, но суть в том, что отели считают стоимость проживания количеством ночей.

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

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

Неужели в 2026 году нельзя сделать систему бронирования, которая будет динамически считать гибкие предпочтения всех гостей?

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

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

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

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

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

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

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

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

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

Для этого вводим стандартное обозначения прав сайтов и приложений. Допустим, это будет щит, но это не важно. Вставляем его рядом с названием сайта в адресную строку всех браузеров:

И куда-нибудь сюда во всех приложениях, но можно ещё дать способ показать внутри своего интерфейса тоже:

Даём АПИ, чтобы подписать в окне настройки разрешений каждое разрешение объяснением того, зачем оно нужно. Всё, теперь сайт или приложение могут и в своём интерфейсе сколько угодно говорить, мол, чтобы работали видеозвонки, мне нужно доступ к камере; и в самом интерфейсе настройки под разрешением уведомлений уверять, что спамить не будут. Но не могут сами ничего попросить!

В цифровых продуктах больше нет дизайна: ему на смену пришла эволюция.

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

А вот другой пример, уже не из Докинза: Инстаграм. Это была хронологическая лента фотографий интересных тебе авторов. Потом вдруг приделали мессенджер, а посты перемешали как попало с рекламой и видео. Потом слизали со Снепчата сторис. Они никак не вязались с лентой, поэтому их воткнули сверху в виде кружочков, которые живут своей жизнью и управляются другими жестами. Затем в разные места повставляли видеотрансляции (это не то же, что просто видео), какое-то IGTV (это тоже другое), и слизанные с Тиктока рилсы (и это тоже другое). Рилсы поселили в отдельной вкладке с собственной палитрой управляющих жестов.

Компания «Мета», которой принадлежит Инстаграм, признана экстремистской и её деятельность запрещена в России, причём не за плохой дизайн, а за какие-то другие грехи

Дизайн и эволюция

Когда-то продукты проектировали осмысленно: разделы организовывали в иерархию, функциям находили логичные места. Человек мог увидеть за продуктом систему: из каких частей он состоит, как организованы экраны, какие виды данных есть. Пользователи это не анализировали, но это помогало ориентироваться и давало чувство контроля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Через месяцок-другой все переучатся и верхний поиск можно будет совсем убрать.

Недавно на рабочем созвоне обсуждали одну задачу по шахматам Ворлд Чесса. Речь шла о продвинутом анализе партии с оценкой позиции, объяснением ошибки и связанных рисков, разыгрыванием альтернативных вариантов на доске и так далее. Это функция доступна при платной подписке, но пару раз можно попробовать бесплатно.

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

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

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

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

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

Интерком онбордингом называет не бесячие блокирующие экраны, а весь процесс того, как люди, узнавшие о продукте, под вашим чутким управлением становятся довольными клиентами и пользователями.

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

• Онбордингу редко уделяют внимание, сравнимое с уделяемым «основным» фичам продукта, что иронично, учитывая, что онбординг — единственная часть продукта, с которой столкнётся абсолютно каждый пользователь. Странно вкладывать силы в привлечение людей, но не в их удержание.
• Если даже человек прошёл все экраны онбординга, заполнил некий «прогрессбар знакомства» с продуктом, или ему просто показали, как воспользоваться определённой фичей, это не значит, что он будет всем эти пользоваться, тем более долгосрочно.
• Хороший онбординг меньше занят проведением человека через конкретные шаги, важные для бизнеса, и больше тем, как создать у человека приятные моменты, ощущаемые как «успех» с продуктом. Экраны с пошаговым объяснением могут в этом помочь, но обычно в их основе всё же желание бизнеса что-то показать, а не потребности человека.
• Онбординг — это проведение за ручку от фичи к фиче, сценария к сценарию, совмещённое с внимательным слушанием того, что нужно самому пользователю (то есть, какие именно фичи и сценарии нужно показывать). Хороший онбординг начинается с попытки понять, что ищет и чего пытается достичь человек, и создаёт у человека ощущение, что с вашим продуктом он как раз на верном пути.
• Когда человек пробует новый продукт, он на что-то надеется. Хорошо бы понять, на что, и построить онбординг вокруг реализации этой надежды. Если у вас, например, аналитическая система, то человек ей пользуется не ради отчётов, а чтобы получить повышение, доказать свою компетентность коллегам. Иногда можно просто спросить у человека, чего именно он хочет достичь. Когда вы узнаете ответ, удивитесь, сколько всего захотите поменять в своём онбординге. Текст, который написан во всяких онбординговых экранах, должен не описывать фичи, а помогать понять, как люди достигнут с их помощью своих целей.
• Очень полезно опрашивать человека, который только стал вовлечённым пользователем, о том, как именно он прошёл этот путь. Прямо буквально понять, что он делал, какие данные откуда импортировал, в каком формате.
• Онбординг не кончается, когда человек покупает продукт или переходит на платный тариф. Даже когда человек уже стал «платником», может оказаться, что он ещё не получает особой пользы от продукта. Пользователя ещё надо «активировать», то есть довести до конкретных действий, которые заставят его почувствовать пользу от продукта.
• Важно понимать, как принимают решения ответственные за бюджет и технологии, чтобы хотя бы в той части не было затыков.
• Иногда бывает, что в онбординге учат пользоваться какой-то функцией, потому что без этого объяснения она непонятна. А надо сделать понятной.
• Если у вас есть триальная версия, вам нужно убедиться, что за её время человек смог почувствовать пользу продукта. Вы должны понимать, какую проблему человек пытается решить, и помочь ему с этим уже во время триала. В идеале он должен получить то самое вдохновляющее чувство «успеха», что у него что-то там получилось.
• Иногда путь до этого момента длинный, например от идеи сдать комнату до получения первых денег. Но можно хотя бы намекнуть на будущую радость: Эйрбнб показывает «ожидаемый ежемесячный доход» сразу на основе расположения и типа жилья.
• Компьютерные игры — чемпионы в онбординге. Они сразу ведут человека за руку по всему веселью и дают почувствовать вкус успеха.
• Хорошие шаблоны и настройки по умолчанию помогают сократить путь до искомого радостного ощущения.
• На экранах с пользовательскими данными предусмотрите хорошие пустые состояния, которые подскажут, помогут человеку с заполнением.
• Если у вас предусмотрен какой-то «тур» по продукту, дайте человеку возможность начать его позже, когда он сам захочет.
• Когда человек решает переехать с какого-то продукта на ваш, на его решение влияют четыре силы: 1) желание избавиться от проблем, связанных со старым продуктом; 2) надежда на новые возможности с вашим продуктом; 3) инерция, нежелание переучиваться; 4) переживания из-за рисков, связанных с новым продуктом. Для успеха онбординга вы должны усиливать те из них, что работают на вас, и помогать преодолеть те, которые работают против вас.
• Делайте ясные обещания типа «Сэкономьте 15%, потратив 15 минут на работу».
• Люди не любят выглядеть дураками. Они могут переживать, что неумелое использование вашего продукта покажет их такими внешнему миру. Например, они через вашу систему случайно отправят рассылку не тем людям. Поэтому важно, чтобы люди ощущали, что их никто не видит, пока они только пробуют. Нужны всякие тестовые и деморежимы, где всё «понарошку».
• Думайте, как ваш онбординг видят разные люди, которые сталкиваются с продуктом, особенно по мере роста продукта. Если шаг вашего онбординга предлагает ввод данных корпоративной банковской карты, то на нём отвалятся все, кто не имеют к ней доступа (это большинство из тех людей, которые потенциально могли бы стать проводниками вашего продукта в этой компании). Аналогичная проблема может быть, если где-то нужно импортировать закрытые данные. В начале «Интеркома» было нормально предлагать мелким стартапам вставить код на Джаваскрипте на страницу, а сегодня большинство клиентов бы не справились с этим.
• Очень сложно заново получить внимание тех, кто отвалился вот так на полупути, особенно учитывая, что заманить их надо на самый скучный шаг типа ввода тех самых данных банковской карты или, скажем, создание АПИ-ключа. Частая ошибка — моделирование онбординга как строгой последовательности шагов. Всегда должен быть способ пропустить сложное. Всегда стоит предполагать, что прохождение какого-то шага — это работа другого человека; не того, кто сейчас смотрит на наш продукт.
• Элементы интерфейса, связанные с онбордингом, должны быть частью дизайн-системы, иначе все эти подсказки, попапы, велком-скрины и временные подписи выходят из под контроля.
• Не нужно вываливать на человека сразу всё, что вы хотите рассказать. Нет смысла учить пользователя хитрым сочетаниям клавиш в продукте, где он ещё не создал свой первый документ.
• Онбординг, связанный с новыми штуками, не должен мешать пользоваться существующими.
• Чем дольше вы ведёте кого-то за руку, тем меньше его мозг будет работать. Если кормить кормить ребёнка с ложечки постоянно, то она так и не научится держать вилку с ножом. (Видимо мысль тут в том, что избыточное разжёвывание всех фич приводит к тому, что люди ничем так и не научаются пользоваться).
• Думайте об удержании пользователей больше, чем о конверсии. Можно настроить могучую конверсию разными хитростями, но устойчивый бизнес получается, когда пользователи остаются с вами надолго.
• Вместо того, чтобы фокусироваться на запуске новых фич, думайте о том, как делать, чтобы люди начинали активно пользоваться новыми фичами.
• Постоянно регистрируйтесь сами как новые пользователи своего продукта. Хорошо бы, чтобы это было частью чьей-то работы — убеждаться, что всё хорошо и логично работает.

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

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

Я говорю: погоди, а зачем карта? «Ну, так попросили, хотят видеть на карте». Зачем? «Им удобно видеть на карте». Но с чего они взяли, что им удобно, если пока такого вида нет? Что они рассчитывают увидеть на карте? Какой важный аспект сбоя раскроется при отображении на карте? Какую роль там играет именно географическое расположение предприятий? Часовой пояс? Близость к столице региона? Климат? Непонятно. «Это хороший вопрос», — говорит дизайнер.

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

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

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