Вот вам пример улучшения из Ай-ОСа 17. Кадр из видоса Брендона Бутча:

Когда создаёшь автоматизацию, раньше спрашивало, хочешь ли ты «персональную» или «домашнюю». Я дальше этого экрана никогда не проходил, потому что хрен знает, что это значит. Эплы по одним им известному принципу разделили триггеры на две категории.

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

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

Вот пример из эпловского же доклада как раз на эту тему:

Пусть надо выбрать вид транспорта. Деление на первом шаге на воздушный и наземный — понятное. А вот с топливом — засада. Если я хочу поезд, очевидно ли мне, в какой из категорий искать? Не факт, так что такое деление лучше убрать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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