Protraktor

Мелочи №3. Про видимость «хорошего» и рождественскую ёлку Начнешь писать мелкую заметку, а в результате возникает большой пост, а потом еще больше и больше, ибо столько нюансов. В общем, чтобы не молчать долго, кину пока простую, но важную мелочь про цветовые коды. Бывает, что нам нужно показать на мнемосхеме, на карте, или просто в таблице статусы объектов — где зеленый это «хорошее» состояние, желтый — «обратить внимание», а «красный» — плохое. Распространенная ошибка — это как раз переиспользование зеленого. Получается пестрая картинка (изображение №1 выше), которую часто в зарубежных источниках называют «christmas tree» — рождественской ёлкой. Я с коллегами периодически это называю «звездолётами», ибо так обычно киношники делают интерфейсы в фильмах — мигающие эффектно лампочки всеми цветами, полный треш с позиций восприятия и поддержания ситуационной осведомленности. Меж тем, часто оператору не нужно думать об объектах, у которых всё хорошо — ведь с ними всё в порядке, они не требуют контроля и каких-либо реакций. Поэтому в таких случаях правильнее снижать акцент с них, привлекая внимание только к тем, у которых могут быть или уже имеются проблемы (то есть «желтых» и «красных» соответственно). Тогда картинка становится чище (опять же, учитывая что проблемных объектов автоматизации обычно все же меньше, чем непроблемных) — мы просто вырубаем зеленые лампочки, делая их нейтральными, и желтые/красные начинают гореть куда «ярче» — см. вторую картинку. В общем, очередная история про дизайнерскую эвристику — привлекай внимание к тому, что требует реакции

(продолжение) В общем, выводы такие (на мой взгляд весьма примитивные, но как видим, примитивность ничего не значит): - Если есть место, делайте кнопки как можно больше. И, к слову, не важно, десктоп это под мышь или HMI под тач - Потребитель клюёт на дизайн только в первые разы. Дальше ему глубоко плевать на стилистику и white space, если это приводит к неудобству. - Ну и тут явная картина, когда безопасность (вся эта избыточная возьня отвлекает от дороги) жертвуется ради масс-маркетной стилистики, что является самым опасным, когда UX-дизайнеры, привыкшие к рисованию “безопасных” массовых продуктов переходят к системам, требующим несколько более глубокого подхода. P.S. Я понимаю, что тут я расписываю очень простой аспект, и само по себе это меня и возмущает — какого черта. У этого автомобиля — и конкретно он не является каким-то исключительным, всё в тренде — много других, тоже очень непродуманных и даже потенциально опасных вещей, которые закрываются юридически фразой в духе «вы несете ответственность за следование правилами дорожного движения». Если интересно, могу попробовать и про них рассказать, но будет еще больше букв.

Мелочи №2. Про закон Фиттса и рукожопныйApple Car. Ох, давно я не гундел на дизайнеров-рукожопов писал про HMI. Но вот накипело. Приехав в Черногорию, я сразу же, позабыв про «Правило четырех Ф», арендовал в аэропорту первый попавшийся автомобиль — и это оказался довольно свежий Renault Captur. С кучей стандартных современных цифровых наворотов — контроль полосы, считывание знаков, старт/стоп, стопятьсот парктроников по кругу, ну и, конечно же, поддержка Apple Car и Android Auto. Гундеть на сам Рено и эти навороты после недели эксплуатации я сейчас не буду — это отдельная история, более сложная, хотя и там есть уже что сказать (Например, почему при включении заднего хода он обязательно пищит звуком парктроника несколько раз, как будто у меня там сплошные опасности — а поскольку на этот звук вырабатывается рефлекс, ты ничего не можешь сделать с возникающим чувством настороженности/паники, хотя никаких опасностей нет. Но ладно, это сложные материи, о рефлекторных ЧМ-взаимодействиях кратко не напишешь). Обращу же внимание на куда более простую и распространенную историю — на Apple Car и закон Фиттса. Благо в моей домашней Kia Rio тоже имеется поддержка Apple Car и имеет те же самые проблемы. Итак. Есть микромоторика и макромоторика. Микромоторика, в нашем случае, задействована, когда мы делаем мелкие точные движения пальцами чтобы нажать что-то — физическую ли кнопку или кнопку, нарисованную на сенсорном экране. Обычно в этот момент наше запястье удобно лежит или касается какой-то поверхности — поэтому всё приятно и точно. Интерфейсы смартфонов — это интерфейсы под микромоторику, ибо мы держим телефон в руке, и как бы ни перемещалась она, телефон двигается с ней. Управление же сенсорным экраном инфотейнмент системы посередине автомобильной торпеды — это макромоторика. Рука на весу, движения намного менее точные, ибо суставы и мышцы наши — не серовприводы робота. Добавляем условия тряски на ходу — и все становится вообще швах, точность радикально ниже. При этом UX-дизайнеры Apple явно не в курсе ни про микро- и макромоторику, ни, по ходу, даже про закон Фиттса (который вообще не понятно как можно не знать). Они взяли те же принципы и стиль, что есть в iPhone — в частности, из Control Center, — и просто перенесли их на торпеду. Надо ж поддерживать унификацию и узнаваемость экосистемы. Как следствие, система сделана чудовищно плохо вот с позиций таких простых, базовых вещей — а ведь любая автомобильная инфотейнмент система это система с повышенными требованиями к безопасности — пользователь взаимодействует с ней в том числе за рулём, отвлекаясь от обстановки на дороге. Перейдем от общих эмоций к конкретным примерам. Почти все кнопки мелкие даже там, где куча места и можно было бы их просто увеличить (да, пожертвовав узнаваемой стилистикой — но разве это приоритетнее безопасности и юзабилити?). Далее смотрим на прикрепленные выше фотографии (на них я показал не только куда глядеть, но и штриховкой отметил незадействованное пустое пространство, которое можно было бы использовать, чтобы увеличить площадь элементов управления). Фото 1. Переключить с музыки/телефона на навигацию или обратно — нетривиальная задача. Попробуй попади в кнопку полтора на полтора сантиметра почти вытянутой качающейся рукой, еще и поглядывая на неё краем глаза (на дорогу надо смотреть, на дорогу!). Фото 2. Чтобы вызвать список локаций, нужно надавить еще более крохотную иконку лупы. Видимо, предполагалось, что это будет делаться не на ходу, но увы, ребята, такое бывает далеко не всегда. В итоге часто проще юзать телефон, чтобы хотя бы нажимать кнопки используя микромоторику. Фото 3 — отдельный шедевр. Экран большущий, но при этом кликабельны только кружки (ровно как в Control Center). Никто не убедит меня, что это нормально и стоит того. Разделить область разделителями (зеленые на фото), сделать шесть больших квадратных кнопок — не, плохо. Ну и последнее, фото 4 — закончив все мучения, нужно ещё попасть в кнопку “Старт”, размером почти с кнопку на десктопе (то есть мелкую). Что мешало поднять вверх чуток параметры и сделать её выше?

Добавочная стоимость дизайнера или удивление как экономэффект Эта заметка немного не укладывается ни в онбординг, ни в “хочу всё знать”, поэтому просто отмечу как есть. Один из ключевых факторов, на мой взгляд, ценности (в том числе финансовой) дизайнера заключается не в том, что он хорошо проектирует, рисует, думает и т.п., а в том насколько он возвращает траты на себя, или, можно перефразировать, насколько удивляет в хорошую сторону заказчика — и под заказчиком здесь подразумевается в общем-то любой коллега (если мы говорим об инхаусе). Низший уровень мастерства — это сделать так, как сказали. Дизайнер просто выполняет задачу. Есть, конечно, те, кто не способны и на это, но мы же не будем погружаться туда. Добавочная ценность тут минимальная — тупо оплачивается время, можно было бы и самому сделать, но так делегировал и забыл. Кстати, этот критерий важен когда берете околонулевых джуниоров в команду на вырост — если спустя два-три месяца время на объяснение и приёмку (поправь тут, поправь там) работы не становится меньше хотя бы в два-три раза, чем время работы дизайнера — стоит расставаться. Достаточный уровень мастерства — это когда дизайнер делает то, что сказали, но лучше чем заказчик. И заказчик это принимает (со всей аргументацией). То есть дизайнер понимает что от него хотят и выдает это. Причём усилия на постановку задачи уже значимо меньше рабочих усилий дизайнера. Следующий уровень мастерства — это когда дизайнеру ставят проблему (а это совсем другая история, не задача — я уже писал об этом еще в старом блоге), и он уже предлагает решение (желательно с опциями) к ней, которое попадает в проблематику. Понятно, что ценность такого сотрудника намного выше, а значит и его стоимость. Но и это не всё, вернемся к удивлениям. Неважно, на каком уровне мы находимся — начинающего или опытного. Чтобы выстраивать хорошие взаимоотношения, чтобы повышать свою стоимость, да и чтобы, наконец, расти — нужно делать больше, чем просится. Попросили нарисовать иконку — сделайте несколько вариантов. Попросили несколько вариантов формы — сделайте еще больше, или переверните задачу так (об этом я, вероятно, отдельно напишу), что вместо формы может быть совсем другой подход. Дали бизнес-требования или сценарии — сделайте и по ним, но потом и предложите вот тут и вот здесь более оптимальный с позиций разработки и ценности для потребителя подход, даже если это отходит от правил. Разумеется, основную задачу нужно решать — эти уровни никто не отменял. Иначе можно скатиться в фантазии, творчество и фрустрации. Но если стремиться к профессионализму, уметь удивлять — очень важный подход. В том числе для своего кошелька или прощения всяких недостатков (кои у нас всех есть). P.S. Конечно, это в принципе про любую профессию

Мелочи, №1 Почему-то не встречал в явном виде у других, но я давно пользуюсь достаточно важной, как мне кажется, эвристикой, которая полезна для оценки необходимости того или иного второстепенного (то бишь вспомогательного) функционала в системе: Если усилия пользователя по освоению и использованию интерфейса функционала превышают воспринимаемую им ценность от использования и/или негативные последствия от его игнорирования — этот функционал не будет использоваться. Полезна для отрезвления внутрикомандных генераторов идей во время корпоративных споров, когда такой товарищ предлагает нечто в духе «а давайте предумотрим ситуацию, когда пользователю нужно выбрать фильтр на основе заранее сохраненых предустановок, поменять его, исключив пару опций, и добавив другой альтернативный критерий» или иные муторные и частные ситуации, значимо усложняющие ПИ. Да никто так делать не будет, даже этот товарищ. И user research здесь не всегда нужен, чтобы валидировать потоки отсебятины. Вообще, эта эвристика вдохновлена старым, но вечным подходом В.Головача, а ля «степень проработки интерфейса должна быть пропорциональна частоте использования и критичности результата, и обратно пропорциональна усилиям по реализации интерфейса», но, конечно, немного про другое. #мелочи#эвристики

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

Хочу всё уметь. Необходимые знания и навыки UX-дизайнера профсистем. Часть 1. Пока у меня накапливаются мысли про онбординги и т.п., давайте ещё затронем такую тему, что должен уметь UX-дизайнер сложных систем. Помню, меня еще год назад мой друг и бывший коллега помучил и предложил написать пост. Пост я так и не написал, ибо как всегда замахнулся написать много и подробно, поэтому буду кусочками отписывать — тем более сегодня накидывал некоторые пункты в план развития коллеги. Начнём с «простых» вещей — у меня нет цели и возможности сейчас расскрывать подробно эти темы, но я хочу наметить опорные точки, вывести неосознанное незнание в осознанное. 1. Информационная архитектура — вроде бы, все представляют, что есть такое. Но на практике мы часто делаем решения по наитию, повторяя те или иные общие практики или подходы продуктов, которые мы хорошо знаем. Меж тем создать гибкую модель «здания» системы с дверями и окнами, которая подойдет для самых разных сценариев взаимодействия, а ещё будет гибкой, масштабируемой и расширяемой — это довольно серьезная работа, требующая глубокой концентрации и навыков абстрагирования. Условно говоря, если вы хотите в вашей системе сделать запись на приём врача, архитектура Ui должна позволять как начать с идентификации или регистрации пациента (если его еще не было), а потом выбрать доступный талон (слот) для конкретного врача, либо же вначале проверить наличие слотов у врача и перейти к идентификации/регистрации — и это не тривиальные моменты. Модели архитектуры от данных, модели от сценариев, умение сочетать их друг с другом, достигая необходимой и достаточной близости, вопросы работы поиска и поисковой выдачи — все это важные вопросы, которые часто проходят мимо. 2. Микровзаимодействия и микросостояния — есть сценарии работы, а есть мелкие колючки и шероховатости, которые могут приводить к серьезным последствиям (как ошибка в грошовом индикаторе скорости снижения однажды привела к авиакатастрофе). На мой взгляд, к сожалению, на это тоже стали подзабивать — но нужно разбираться, когда можно состояние нажатия на кнопку объединить с состоянием селекшна, а когда не стоит (ибо вносит путаницу и не дает возомжности исправить ошибку до триггера действия), почему стоит жертвовать красотой, чтобы недоступные поля не походили на доступные (или наоборот), либо же уметь расписать поведение от выбора инструмента и нажатия ЛКМ (левой кнопки мыши) до завершения работы со всеми ветвлениями на панорамирование, исправление ошибок и т.п. для какого-нибудь набора тулов на холсте (типа линейки измерения расстояний) с минимизацией действий/состояний выбора и т. п. 3. Визуальная иерархия и соответствие с логикой/содержимым — это отдельная большая тема, на которую завязываются задачи снижения визуального шума, подчеркивания акцентов на важном или новом, а также учёта того, что выводы о связах/важности мы часто делаем еще на бессознательном уровне при интерпретации пятен, а не после распознавания текста, иконок и иных “сознательных” процессах. Когда причины стоит держать перед следствиями (слева или выше), а когда можно пожертвовать, как и какими средствами (фоном, разделительными и соединительными линиями, пустотой и т.п.) правильно соединить или разделить блоки, чтобы была понятна смысловая вложенность/принадлежность или, наоборот, параллельность, или даже бессвязность семантических элементов — особенно в условиях профсистем, когда мы имеем дело с большой плотностью данных (и, кстати, почему часто мы не должны жертоввать ей ради красоты и пресловутого «white space»).

P.S. Следующее по онбордингу дизайна/дизайнера будет чуть конкретнее — а именно про процессы.

Впрочем, если идти путём изучения, можно испугаться и закопаться, и это другая крайность. Все таки системы (их реализации) плюс-минус конечны, а у страха глаза велики — и пытаясь осмыслить то что видишь, можно впасть в состояние «я тупой, я ничего не понимаю, мне это не по силам». Тут мне сложнее давать советы, но все же я считаю, что это состояние само по себе лишь симптом каких-то трудностей, но само по себе ничего не значит. Мы не умели ходить, мы не умели ездить на велосипеде, нам могло быть до жути страшно в первый раз садиться за руль автомобиля в одного — это совершенно нормальная реакция на нечто новое и трудно, а значит её можно при должном желании контейнировать и не позволять блокировать движение. Не страшно, что страшно. Страшно — если страх парализует. Хотя мы ушли далеко в сторону (хотя, повторюсь, я считаю это очень важными, фундаментальными вещами, которые влияют на очень многое в принципе по жизни, не только в карьере). Очень интересна ситуация, когда мы имели опыт с аналогичными продуктами и попали в компанию, где «всё понятно». Это еще один опасный блокер, особенно для более опытного специалиста. В последние годы ко мне периодически обращаются за советом люди 35+ (а были и 45+), которые имеют крутое — по меркам прошлого — портфолио, отличные навыки, но застряли в работе и их никто не берет — потому что в нужный момент не стали учиться новому и пересматривать свои подходы. Всё круто, вот только мир стал другим и дзыньк, ты на обочине, бумер. Вспомните историю про Nokia — всё это происходит как с компаниями, так и с отдельными человеками — только не так заметно. В общем, даже если вы идёте к конкуренту, нужно стараться идентифицировать, что из решений вы сделали не задумываясь, просто потому что вы делали так раньше — и ловить, опять же, свои собственные оценки. И отпускать, отталкиваться от них, как от причальной стенки. Впрочем, черт побери, бывает что после того как включаешь режим «попробую осмыслить с нуля», снова приходишь к тем же решениям — порой и выше себя не прыгнуть, да и не всегда нужно, но всё же это помогает находить ключевые опорные точки, сопоставлять с текущим статусом кво в других системах. Подозреваю, что слов тут больше, чем сути. Короче — любая новая работа немножко нас переделывает, а порой даже ломает. К этому этапу нужно отнестись ответственно, с любопытством — это отличная возможность разбавить свой опыт новым, неожиданным. Но для этого нужно контролировать свои блокировки, связанные с эмоциональными оценками на основе нашего предыдущего опыта и ожиданий. И главное тут — идентифицировать эти эмоции, и сразу же, немного изолировав их, переходить к аргументационной фазе. Конечно, если вас продолжает постоянно триггерить эмоциями — может стоит найти другую работу. Или вообще занятие. Например, копать нефть.

Черновик висел какое-то время, а известные события даже немного обесценивают мои попытки, но я всегда восхищался теми, кто продолжает своё дело несмотря ни на что. Мне до них далеко, но…. вот сыроватое, но все же продолжение истории сидя на лодке в Таллинне. Интересно, откуда следующее будет написано. Старт дизайна и дизайнера. №2. Ожидания/оценки/эмоции/блокировки Пора продолжить историю об онбординге дизайнера и дизайн-процессов в отдельно взятой компании. В первой части я отметил, что нужно как можно меньше выражать оценок, чтобы не испортить коммуникации. Пора развернуть эту тему скорее с внутренних психоэмоциональных позиций — нашего опыта и представлений. И хоть далее будет совсем не про интерфейсы, я считаю что это суперважно, особенно для начинающих, ибо всякий профессиональный путь идёт не только через разумное, но и через эмоциональное, иррациональное. Простите, много букв. К моменту старта у нас может быть несколько диспозиций, раскладов. Мы можем ничего не знать о компании и её продукте. Также мы можем иметь дело с продуктом как пользователи — представьте, что вы стали работать в Figma/Apple/Google. Или же мы уже работали с аналогичными продуктами — например, у конкурентов. И неважно, насколько мы опытны — глядя на продукты, мы, в зависимости от самооценки, можем испытывать эмоциональные реакции в духе «чё так стрёмно, не в трендах», либо «ааа, как я в этом разберусь, нихрена не понятно» или «ща я тут наведу порядок». В любом случае, мы предвзяты — и этот процесс нужно контролировать. Ибо эмоциональные оценки в духе «хорошо»/«плохо» часто на этапе погружения в продукт не столько связаны с продуктом, сколько с какими-то нашими ожиданиями и фантазиями из прошлого опыта. При этом оценки могут значимо влиять на наши решения и поведение — я много-много-много раз видел, как в одних случаях страхи блокировали развитие как дизайнеров, так и продуктов, в других — излишняя самоуверенность приводила к резким изменениям, не соответствующим реалиям контекста и, в дальнейшем, к откатам. Причём всё это рационализировалось, обосновывалось, в том числе даже «пользовательскими исследованиями» (ох, это вообще большая история, на когда-нибудь потом). В общем, тут всё скорее про психоанализ (если вы в него верите), чем про профессиональную работу. Позволю себе несколько непрошенных советов, в зависимости от начальной ситуации. Раз мы говорим о профинтерфейсах, то часто человек, приходящий в них из масс-маркета сталкивается с первой реакций — «чё так стрёмно». Я давно уже не морщусь над шутками про 1С-Бухгалтерию в чятиках (а недавно возик иной повод — начали чморить Adobe). Но ведь каждая система уникальна, имеет свои особенности (и одни и те же особенности могут быть одновременно и плюсами, и минусами — даже для одного и того же пользователя), а ещё, разумеется, эволюционные причины — и просто оценивать это категориями «хорошо/плохо» не просто рационально, но и вредно для создания стратегии развития продукта. Даже если мы на 100% уверены что наше решение лучше, а это правильное, у нас в кармане должны быть конкретные аргументы — много аргументов. Казалось бы, очевидно, но попробуйте объяснить рационально, почему пора отойти от закругленных градиентных кнопочек или иконок в духе нулевых в сторону последних. Ответы «так не принято, не модно», «все делают иначе» — на самом деле не аргументы. Есть ещё хак, развивающий объективность восприятия – попробуйте найти аргументы, почему то, что вам не нравится — правильно и имеет право на жизнь. Это прямо отличный навык, который позволяет проверить самого себя «на вшивость» — как только чувствуешь эмоциональное неприятие, говоришь себе «стоп» и пытаешься разобраться в его причинах рационально. Найдется очень много интересного, полезного для себя и проекта, да и скучно не будет. Но, конечно, это если вы стремитесь к взвешенным решениям и не боитесь энергозатрат. Жить по эмоциям — проще.