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

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

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

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

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

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

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

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

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

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

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

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

Я понимаю, что пароли не совпадают, я ж ещё не допечатал второй! Выводить сообщение об ошибке надо при расфокусе поля или попытке отправить уже всю форму, а не под руку.

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

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

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

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

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

Примеры с сайта easings.net

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

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

Однажды Эплы на ВВДЦ сформулировали простой принцип: анимация должна плавно замедляться ровно к нужной точке, если её инициировал компьютер, но может пружинить, если её инициировал человек! То есть если я сам пальцем швыряю панельку, она может уехать чуть дальше, чем надо, и потом вернуться. Это логично: я ж не рассчитывал силы как в бильярде, чтобы попасть ровно — просто толкнул, как вышло. Но если панелька выехала сама и пружинит, то это воспринимается как баг. Типа, чё она сразу-то не приехала куда надо? Почему программа не смогла рассчитать нужную скорость? Когда я услышал этот эпловский принцип, я почувствовал себя глупым, потому что это очень простое объяснение, но сам я его сформулировать не мог.

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

Но зато теперь хотя бы вы знаете и не будете делать такое говно в своих продуктах.

Интернет ликует, что из Эпла уходит главный дизайнер Алан Дай.

Алан — лицо деградации интерфейса в Эпле, происходившей последние годы. Если раньше ключевые принципы хорошего интерфейса было удобно объяснять на примере Эпла, то сейчас на примере Эпла остаётся показывать только, как делать нельзя. Алан получил огромную власть при минимальной компетентности: он просто не понимает, что делает интерфейс хорошим; он необразован и даже не осознаёт этого. Внешний вид и поверхностные эффекты полностью победили глубокую продуманность, и всё продолжает работать только благодаря величайшему фундаменту, построенному в далёком прошлом. Дай не понимал и не уважал этот фундамент.

На место Дая приходит Стив Лемей. Я не слышал это имя, но он работал в Эпле дизайнером интерфейса с 1999 года, так что нет сомнений, что он хотя бы понимает, в чём заключается эта работа. Кроме того, похоже, сами дизайнеры в Эпле не верят своему счастью и связывают надежды с этим изменением. Возможно, это человек, для которого design is how it works — не просто красивые слова. А ведь пару недель назад был ещё слух, что в этом году Эпл сфокусируется не на новых функциях, а на полировке и доработке.

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

Отдельно я надеюсь, что Эпл вспомнит, как много он сделал для удобства перетаскивания как жеста в своё время. В Виндоусе перетаскиванием пользоваться было невозможно, потому что если тащить файл, то всё остальное работать переставало до завершения этого жеста. На Маке, пока «держишь» файл в мышке, раньше можно было прокручивать окно колесом, чтобы бросить файл в нужное место, а ещё можно было нажать пробел, чтобы активировать элемент под курсором, пока кнопка мыши занята. Сейчас эти вещи работают через раз: где-то успели доломать, где-то не успели. А вдруг Эпл теперь вспомнит следствия из закона Фиттса и файлы в Док можно будет снова перетаскивать до самого края экрана, а не целиться в иконку?

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

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

См. также:

• Уход из Эпла вникуда

Обещал рассказать, как я фотографирую, чтобы получалось клёво. Во-первых, я уже как-то писал о неприятных пересечениях на фотках. Также выкладывал видео о том, что телефон нужно держать ровно. Сегодня просто поделюсь ходом мысли в момент съёмки. Покажу, какие кадры мне показались неудачными и как я сделал их лучше.

Если в кадре суждено быть человеку, то пусть он будет колоритным или наоборот незаметным, но не просто случайным. Именно в этом случае он и будет казаться случайным! Ведь он впишется в кадр идеально, а не будет торчать из него занозой. Аналогично с транспортом. Ну и плюс, если в кадре много людей или машин, то хорошо, чтобы они его как-то более-менее равномерно заполняли, а не все в одном месте столпились.

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

Сначала получилось мимо из-за въехавшей в кадр машины, потом она проехала и стало нормально:

Разница между кадрами — 4 секунды

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

Разница между кадрами — 7 секунд

С автобусом нормально, но не супер; с двумя тук-туками намного аутентичнее:

Разница между кадрами — 3 секунды

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

Разница между кадрами — 3 секунды

Ну при чём тут белый мерседес? Вот мусоровоз — другое дело:

Разница между кадрами — 7 секунд

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

Разница между кадрами — меньше секунды

Чел слева ваще не вписывается в картину. Подождём пока он свалит... О, какой автобус! Берём:

Разница между кадрами — 4 секунды

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

Последняя фотка даже удостоилась публикации, вот в таком виде:

Исходные кадры я бы удалил в обычном случае, но тут они стали материалом для заметки.

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

Разберём экстремально плохой пример из аэропорта Гонконга. Сейчас 13:22, но мне показывают примерно часовую порцию рейсов начиная с 17:30 (как видим в углу, это страница 5):

Раз в десять секунд экран переключается на следующий, но там не следующая порция рейсов, а те же на китайском:

И только ещё через десять секунд включается следующая порция.

Листание продолжается вплоть до рейсов, отправляющихся глубокой ночью. Последний экран имеет номер 16, то есть на полный цикл уходит больше пяти минут! Я ждал своего экрана почти три минуты. Это недопустимо долго для аэропорта, где каждая минута может быть решающей. При этом на большей части экранов о рейсах нет вообще никакой информации, даже гейт не назначен; они просто перечислены. Даже на нашем пятом экране уже осталось только две рейса с гейтом.

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

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

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

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


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

С удовольствием переделаю навигацию и все табло в вашем аэропорту.

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

Просто ааааа, ну как же так, вы же взрослые люди, как можно так пудрить друг другу мозги? Зачем это исследование было? Инсайт в том, что именно пользователи животноводческого портала ценят время и не любят сложности, а, скажем, для записи на ноготочки или управления инвестпортфелем наоборот нужен интерфейс подольше и посложнее?

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

Начну с примера:

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

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

В нашем примере неясно даже, что «это». Новая этика не про удобные шрифты? Дизайн не про удобные шрифты? Политическое заявление? Или именно вот этот дизайн, превратившийся в политическое заявление (а не вообще любой), не про шрифты? А может даже сам тот факт, что этика превращает дизайн во что-то там, не про удобные шрифты?..

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

Кстати, такие конструкции обожает выдавать ЧатГПТ — возможно, в этом причина того, что за последнее время они страшно расплодились.

Читаю исследование:

Наибольшую долю среди посетителей сайта составляют люди в возрасте от 21 до 34 лет — 33,64% всех сессий с оформлением заказа. На втором месте — пользователи 35—45 лет (28,36%). Вместе эти группы формируют более 60% трафика.

Я не понимаю, как взрослые люди могут на голубом глазу такое писать и обсуждать. Что такого драматического и судьбоносного происходит с человеком при наступлении 35 лет, что с этого момента его нужно отнести к другой группе? Почему именно такое деление на возрастные группы столь фундаментально, что количество посетителей в каждой из них считают до сотых долей процента? Разбейте пользователей на группы 21—33 и 34—45, и получатся другие цифры. А можно разбить этих же пользователей на три или четыре группы.

Эти группы 21—34 и 35—45 ещё и неравные по количеству возрастов: в первой 14 лет, во второй 11. Даже будучи равными они бы не имели смысла, разумеется, но этот факт просто добавляет комического эффекта.

А может, просто на сайте трети пользователей 34 года, а ещё трети — 35, а сотые доли возникают из-за редких исключений. Если бы разбили на 21—33 и 34—45, то в первой группе было бы два процента, а во второй — шестьдесят.

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