Про концепции. №5

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

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

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

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

* * *

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

UX Design Awards тут ведут трансляцию уже какое-то время, и вполне можно подоглядывать за едой, например — https://www.youtube.com/watch?v=93W9culsy9s&ab_channel=UXDesignAwards. Вроде не только про всякие масс-маркетные глупости — сейчас было про приложение для инженеров, устанавливающих кондиционерные установки Toshiba. А теперь про МРТ от Siemens (Сименз очень круты в HMI)

UPD: Реально полно профсистем от крутых команд, очень интересно поискать и поглядеть потом всё это в деталях

Старт дизайна и дизайнера в компании. Часть 1. Вводная

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

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

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

* * *

И пока самое простое. Вот вы поулчили доступы, пришли на работу, ничего не понятно. Впрочем, скорее всего вам скажут, что надо начать с такого-то продукта, ибо в нем более всего работы. Что делать?

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

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

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

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


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

UPD: Кстати, почему не надо лезть в один продукт? Да, хочется себя быстрее проявить, но если начать сразу все силы бросать в него, то велика вероятность, что через полгода-год, когда вы дойдете до других продуктов, все своё творчество придется отменить, ибо оно не консистентно другим решениям в других продуктах. Разумеется, никогда полностью не перестрахуешься, но очевидные вещи стоит предусматривать, особенно проектируя новый дизайн-подход, распространяющийся за рамки изначального решения. Прыгая с берега в воду, нужно также думать куда и какими силами вы поплывете, когда достигнете первого буйка.

Не моя поляна сообщать вести, но, если вы ещё не в курсе, случилась какая-то фигня — Эдоби покупают Фигму. Любимый монстр перед смертью таки поглотил своего убийцу —
https://www.figma.com/blog/a-new-collaboration-with-adobe/

Эксперименты. №3 (и отчасти Protraktor UI Kit)

Поскольку у меня на какое-то время пропала точка приложения моих «физических» интересов в DIY, а от новой работы мозги кипят (уже в черновике вторая часть про старт дизайна и дизайнера), решил побаловаться с подходом дизайн-систем к аппаратным органам управления — причём в срезе DIY. То есть сделать некий фреймворк из 3D-моделей и принципов для сборки более-менее эргономичных (насколько позволяют 3D-печать и прочие любительские ограничения) панелей управления для разных самоделок. Ибо то, что валяется на каком-нибудь Thingsverse — какой-то треш рукожопов, ибо антропометрию и базовые принципы унификации никто не отменял, а там о них никто не думает.

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

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

Не уверен, что это самое полезное направление творческих устремлений, но травмы требуют сублимации.

P.S. Осенний режим, ещё и без яхты, двигает больше обращать внимание на этот проект, опять буду его переделывать под новые реалии и мои возможности 🙈 Постараюсь быть более эджайлным — не ждать полировки и завершенности материалов, а выкладывать то что есть. Это я и про Protraktor UI Kit. Но надо кое-что переверстать. В конце концов, тот же openbridge.no не стесняется выкладывать полуготовые решения. И молодцы.

Черновик висел какое-то время, а известные события даже немного обесценивают мои попытки, но я всегда восхищался теми, кто продолжает своё дело несмотря ни на что. Мне до них далеко, но…. вот сыроватое, но все же продолжение истории сидя на лодке в Таллинне. Интересно, откуда следующее будет написано.


Старт дизайна и дизайнера. №2. Ожидания/оценки/эмоции/блокировки

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

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

К моменту старта у нас может быть несколько диспозиций, раскладов. Мы можем ничего не знать о компании и её продукте. Также мы можем иметь дело с продуктом как пользователи — представьте, что вы стали работать в Figma/Apple/Google. Или же мы уже работали с аналогичными продуктами — например, у конкурентов.

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

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

Позволю себе несколько непрошенных советов, в зависимости от начальной ситуации.

Раз мы говорим о профинтерфейсах, то часто человек, приходящий в них из масс-маркета сталкивается с первой реакций — «чё так стрёмно». Я давно уже не морщусь над шутками про 1С-Бухгалтерию в чятиках (а недавно возик иной повод — начали чморить Adobe).

Но ведь каждая система уникальна, имеет свои особенности (и одни и те же особенности могут быть одновременно и плюсами, и минусами — даже для одного и того же пользователя), а ещё, разумеется, эволюционные причины — и просто оценивать это категориями «хорошо/плохо» не просто рационально, но и вредно для создания стратегии развития продукта. Даже если мы на 100% уверены что наше решение лучше, а это правильное, у нас в кармане должны быть конкретные аргументы — много аргументов. Казалось бы, очевидно, но попробуйте объяснить рационально, почему пора отойти от закругленных градиентных кнопочек или иконок в духе нулевых в сторону последних. Ответы «так не принято, не модно», «все делают иначе» — на самом деле не аргументы.

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

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

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

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

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

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

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

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

Хочу всё уметь. Необходимые знания и навыки UX-дизайнера профсистем. Часть 1.

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

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

1. Информационная архитектура — вроде бы, все представляют, что есть такое. Но на практике мы часто делаем решения по наитию, повторяя те или иные общие практики или подходы продуктов, которые мы хорошо знаем. Меж тем создать гибкую модель «здания» системы с дверями и окнами, которая подойдет для самых разных сценариев взаимодействия, а ещё будет гибкой, масштабируемой и расширяемой — это довольно серьезная работа, требующая глубокой концентрации и навыков абстрагирования. Условно говоря, если вы хотите в вашей системе сделать запись на приём врача, архитектура Ui должна позволять как начать с идентификации или регистрации пациента (если его еще не было), а потом выбрать доступный талон (слот) для конкретного врача, либо же вначале проверить наличие слотов у врача и перейти к идентификации/регистрации — и это не тривиальные моменты. Модели архитектуры от данных, модели от сценариев, умение сочетать их друг с другом, достигая необходимой и достаточной близости, вопросы работы поиска и поисковой выдачи — все это важные вопросы, которые часто проходят мимо.

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

3. Визуальная иерархия и соответствие с логикой/содержимым — это отдельная большая тема, на которую завязываются задачи снижения визуального шума, подчеркивания акцентов на важном или новом, а также учёта того, что выводы о связах/важности мы часто делаем еще на бессознательном уровне при интерпретации пятен, а не после распознавания текста, иконок и иных “сознательных” процессах. Когда причины стоит держать перед следствиями (слева или выше), а когда можно пожертвовать, как и какими средствами (фоном, разделительными и соединительными линиями, пустотой и т.п.) правильно соединить или разделить блоки, чтобы была понятна смысловая вложенность/принадлежность или, наоборот, параллельность, или даже бессвязность семантических элементов — особенно в условиях профсистем, когда мы имеем дело с большой плотностью данных (и, кстати, почему часто мы не должны жертоввать ей ради красоты и пресловутого «white space»).

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

Как всегда, продолжение когда-нибудь следует.

Мелочи, №1

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

Если усилия пользователя по освоению и использованию интерфейса функционала превышают воспринимаемую им ценность от использования и/или негативные последствия от его игнорирования — этот функционал не будет использоваться.

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

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

#мелочи #эвристики

Добавочная стоимость дизайнера или удивление как экономэффект

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

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

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

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

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

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

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 — закончив все мучения, нужно ещё попасть в кнопку “Старт”, размером почти с кнопку на десктопе (то есть мелкую). Что мешало поднять вверх чуток параметры и сделать её выше?