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

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

Вот формулировка, которая часто встречается во всяких пунктах про ответственность: «в таком-то случае Заказчик вправе требовать с Исполнителя возмещения того-то». Что это значит, зачем это писать? Я безо всякого договора вправе выйти на улицу и требовать, чтобы все прохожие сдали мне по тыще рублей. А прохожие вправе посылать меня с этим требованием подальше!

Удивительно, но большинство юристов не в состоянии написать: «В таком-то случае Исполнитель возмещает Заказчику то-то» безо всяких абстрактных прав требовать.

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

Это фрагмент № 115 онлайн-курса «Пользовательский интерфейс и представление информации». Записано на курсе 28 апреля 2023 года.

До 6 октября идёт запись на курс, который пройдёт с 7 октября по 5 ноября.

Почитать о курсе

Программа, отзывы, запись

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

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

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

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

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

Это черновик, который я решил опубликовать.

Поток данных — один из моих методов проектирования интерфейса. Он помогает избавиться от ненужных экранов и шагов.

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

Простой пример

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

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

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

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

Сложный пример

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

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

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

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

Ну и всё, исходя из этого и строим интерфейс:

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

Применимость

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

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

Недавно я показывал проект — информационное сопровождение Челябинской транспортной реформы. В мае рассказывал о нём на «Просмотре», и вот выложили видео:

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

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

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

Исходное положение. Сразу чувствуется, что много про что подумали:

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

Открываем верхнюю штуку:

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

Снизу — ещё один карман:

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

Прочитал в сентябре в Москве доклад-лекцию «Как эффективно презентовать работу»:

Это доклад для дизайнеров, менеджеров, программистов, маркетологов, редакторов — для всех, кто защищает свою работу.

Приходите на наш онлайн-курс о презентациях с семинарами и практикой. Завтра последний день записи.

Спасибо организаторам iSpring Days — конференции о корпоративном обучении — за приглашение и запись выступления.

См. также киевскую лекцию о понимании задачи.

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

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

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

Было — стало:

Из блога самого Дуолинго

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

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

В видосе они рассказывают, что это и было целью:

We’ve redesigned the home screen to better guide you through lessons.

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

Follow a path crafted by our learning experts to help you better reach your goals.

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

And don’t worry, we’ve kept all the progress you’ve made so far

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

В общем, очень жаль, хорошая была программа.

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

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

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

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

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

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

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

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

Делать так — плохая практика.

Утверждение может показаться вам абсурдным, ведь онбординги делают очень многие. К сожалению, вопросом «а не фигню ли мы делаем?» в основном даже не задаются. В моей практике бывало, что я спрашивал, зачем это, и слышал: «ну как, это ж онбординг!». Люди даже не замечали, что это не отвечает на мой вопрос — настолько сильно́ убеждение, что надо делать именно так.

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

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

Рассказ о приложении в целом

Сначала рассмотрим онбординг с рассказом о приложении в целом.

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

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

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

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

Рассказ об обновлении

Теперь рассмотрим онбординг с рассказом об обновлении.

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

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

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

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

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

Хороший интерфейс и хороший бизнес

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

Однако как и окна подтверждения и несмотря на похожие проблемы, такие экраны-онбординги очень распространены. Дело в том, что в продуктовой разработке редко стоит задача «сделать пользователя довольным». Как правило, ответственные за продукт смотрят на другие метрики. Допустим, онбординг смотрят 10% людей и в результате продажи растут на 1%. Кого тогда волнует, что онбординг бесит и мешает остальным? Выигрыш оказался больше, чем проигрыш, ну и отлично.

Как-то мне написал Егор, аналитик из Яндекса:

Считаешь ли ты, что а/б-тест может точно ответить на этот вопрос? Половине новых пользователей мы показываем онбординг, половине не показываем, после этого смотрим на две метрики: конверсия первой сессии в заказ и время от запуска приложения до заказа. Если конверсия с онбордингом выше, а время до заказа не вырастает (то есть время, которое пользователь тратит на чтение онбординга, он отыгрывает потом), то согласился бы ты с тем, что онбординги имеют право на жизнь? И как ты вообще относишься к валидации продуктовых гипотез при помощи а/б-тестов?

Я и без теста соглашусь. Но этот тест в лучшем случае докажет, что лучше рассказать о приложении онбордингом, чем никак. А я говорю, что можно рассказать лучше, чем онбордингом.

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

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

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

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

Да, сделать хорошо обычно сложнее, чем сделать как придётся, но и эффект может оказаться больше.

А можно ещё вопрос

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

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