Автомобильный дизайнер Артём Степанов рассказал об интерфейсах систем автомобиля.

Мы сейчас на этапе развития автомобильных технологий «Это ужасно, но все привыкли» и тихонечко его перескакиваем. 80% автомобилистов пользуются 10% функций автомобиля.

Из-за унификации в пределах больших концернов (например, Volkswagen-Audi Group) владельцы дорогих машин садятся на кожаные сидения, но видят те же панели (например, управления кондиционером), что и владельцы машин в 2 раза дешевле.

Маркетологи тоже думают, как сделать круто, ведь нельзя же покупателям новых моделей предлагать старые добрые крутилки. Так в БМВ 7-й серии мультимедиа можно управлять 5 способами:
— Крутилка на передней консоли;
— Касание экрана;
— Тач-панель на крутилке (вместо использования экранной клавиатуры можно рисовать буквы);
— Жесты рукой в воздухе (изменение громкости, переключение каналов);
— Голос.

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

https://www.youtube.com/watch?v=DR9a9t-cGug

Николай Бабич написал, как сообщить пользователю о состоянии системы.

— Выделить в меню раздел, в котором пользователь сейчас находится;
— Показать количество шагов, которое необходимо для завершения процедуры;
— Обратная связь на действия пользователя — нажатия на кнопки и переключатели;
— Показать индикатор загрузки; с прогресс-баром, если операция занимает больше 10 секунд;
— Анимированные экраны-заставки для мобильных приложений;
— Отобразить скелет страницы, пока загружается её содержимое (паттерн skeleton page/screen);
— Уведомления об изменениях в системе;
— Моментальная обратная связь о неправильно заполненном поле.

https://ux.pub/4-metoda-vizualnogo-fidbeka-v-interfeysah/

Матвей Правосудов написал, зачем дизайнеру уметь кодить.

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

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

Так вот, понимание принципов работы технологий (HTML/CSS/JS/API для веба, Swift для iOS и Kotlin/Java для Android) помогает сразу делать макеты более жизнеспособными, а иногда, при возникающих сложностях у разработчиков, ухищряться и выдавать оптимизированное решение, которое достигает того же эффекта, но заметно дешевле».

https://designpub.ru/f728cb8c1e39

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

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

Недовольные клиенты делятся своими эмоциями: отзывы остаются в интернете навсегда, а отдельные истории становятся вирусными (Хасан Сайед и British Airways).

Обманутые клиенты могут создавать группы для защиты своих интересов. Иногда их аргументы доходят до государства, и оно включает регулирование (Великобритания и рынок онлайн-бронирования отелей).

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

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

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

https://ux.pub/kak-ubedit-drugih-ne-ispolzovat-temnye-patterny/

Павел Шерер написал о создании концепции — предварительном этапе перед проектированием.

Концепция предполагает базовые исследования и аналитику уже на самом старте проектного процесса. Её задачи:

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

2. Очертить первоначальные границы проекта: из каких частей будет состоять продукт, какие типы ресурсов потребуются для его создания, каким образом будет проходить коммуникация с клиентами, партнёрами и так далее.

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

Сколько усилий уйдёт на создание внутренней арбитражной системы? При этом она не является функциональным ядром сервиса, и стартап спокойно запустится без неё. Умный проектировщик кратко опишет арбитраж как „следующие этапы развития“, предложит ввести рейтинг, а спорные вопросы первое время решать через поддержку».

3. Предусмотреть базовые риски, описать векторы развития, примерно представить, что может воспрепятствовать развитию продукта, — и подумать, как обойти такие препятствия.

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

— Задачи концепции: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed3f26b709fb133f9734d4a
— Состав и структура: https://zen.yandex.ru/media/id/5a8249f94826772d3da82e8c/5ed67a182cf6c679060463e3

Константин Солодянников законспектировал книгу «Спроси маму».

«Ненужная информация бывает такой:
— Комплименты;
— Болтовня (общие фразы, гипотетические рассуждения, разговоры о будущем);
— Идеи.

Любой из пунктов — признак того, что мы получаем социально-желаемые ответы».

«Важные вопросы — неудобные. Типа, когда думаешь, да как я это вообще спрошу. Вдруг там что-то такое страшное скажут, и всё пропало, паника. Лучше не спрошу.

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

https://www.it-agency.ru/academy/summary-the-mom-test/

Тарас Бакусевич написал о дизайне текстовых полей и форм. Вот некоторые из его рекомендаций (не самые распространённые):

— Подчёркнутое поле ввода — не лучший стиль для текстового поля. Он распространился с появлением Material Design, но потом Гугл от него отказался;
— Длина поля должна быть пропорциональна вводимой информации. Формы с такими полями будут менее аккуратными, но более удобными;
— Заполняйте поля адекватными значениями по умолчанию, но только не при выборе размера или цвета товара;
— Отображайте полезные подсказки, которые помогут принять правильное решение или избежать ошибки. Например, показывайте баланс при совершении платежа;
— Не отображайте сообщение о некорректном заполнении поля, пока пользователь не закончил ввод;
— Иногда можно добавить индикатор корректного заполнения поля. Пользователь будет видеть прогресс и радоваться позитивной обратной связи;
— Если форма разделена на несколько шагов, показывайте пользователю ключевую информацию с уже пройденных шагов;
— Не отображайте такие формы в маленьких всплывающих окнах.

https://ux.pub/podrobnoe-rukovodstvo-po-dizaynu-tekstovyh-poley-i-form/

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

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

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

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

Уровень подготовки пользователя на эффект особо не влияет.

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

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

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

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

https://medium.com/slavetski/e18ff53bace5

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

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

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

Чем больше специальных терминов вы используете, тем меньше вам придётся обосновывать своё собственное дизайнерское мышление.

Запишите несколько жаргонизмов:
— Аффорданс;
— Карта эмпатии;
— Карточная сортировка — как ни странно, означает именно сортировку карт;
— MVP — это используют менеджеры проектов, чтобы уничтожить ваш дизайн;
— Карта пользовательского пути…

Почему мы так повернулись на этих картах, может быть, мы потерялись?»

https://www.youtube.com/watch?v=CT1PE5FruNM

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

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

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

«Необходимо перестать считать всех, кто работает в ИТ-отрасли, „программистами“. Это всё равно, что считать всех, кто занимается возведением зданий, „строителями“. Также необходимо отказаться от мысли, что программисты отличаются друг от друга „сообразительностью“ и при её достаточном уровне способны решить любые задачи. И наконец, не стоит рассчитывать, что программистам можно поставить задачу, просто „объяснив на пальцах“».

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

https://mityakin.ru/paranoid-method-book-03

Некоторые тезисы и цитаты из 3-й главы книги Вадима Митякина, о которой написал ранее:

— Причины провала цифрового проекта не всегда очевидны.
— Бизнес уверен, что привлёк плохих разработчиков, а они уверены, что бизнес нечётко поставил задачи, выделил мало времени и денег. Все они отчасти правы.
— В начале, когда о проекте известно меньше всего, проблематично спланировать работы и рассчитать бюджет.
— Создание цифровых продуктов отличается от традиционных услуг степенью неопределённости.
— В начале есть только ожидание того, как проект повлияет на бизнес, и иногда смутные образы интерфейса.
— Техническое задание не вносит ясности, так как обычно оно таковым не является.
— Всё, что произойдёт в проекте, зависит от его участников и их способности разобраться, что же нужно получить в итоге.
— Создание нового продукта — создание одновременно и карты (представление о будущем продукте, проектная документация, дизайн, программный код), и территории (готовый продукт).
— Ключевой вопрос — кто платит за риск.
— Закон Галла: «Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все эти связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».
— Популярный приём переноса риска на бизнес — продавать процесс, а не результат.
— Гибкие методологии в основном не снижают неопределённость, а переносят риск на бизнес.
— В проектах надо снижать или локализовывать неопределённость.
— Она исходит из содержания задач (например, исследовательские задачи, не гарантирующие решения) и организационной стороны проекта (от получения требований до поиска подходящих исполнителей).
— Хорошо, если компании подходит типовой продукт. Плохо, если её бизнес-модель отличается. Тип проекта меняется с «Седины» на «Мозги», и процесс становится непредсказуемым.
— Иногда на вопрос о стоимости нельзя ответить из-за природы процесса создания сложных систем.
— Компания не может постоянно менять модель работы и радикально обновлять используемые инструменты. Проект типа «Мозги» или «Седина» должен завершиться и уступить место проектам типа «Процедуры».
— Ложные цели приводят к запуску проекта неподходящего типа: прорывной продукт вместо доработки существующих инструментов и наоборот.
— Чтобы запустить онлайн-продажи, надо пересмотреть почти все составляющие существующей бизнес-модели. Разработчики веб-сайта не могут решить эти вопросы.
— Для проектов разного типа процедура выбора исполнителей должна отличаться принципиально.
— Если это проект типа «Мозги», бизнес должен заинтересовать им потенциальных исполнителей.
— Если это «Процедуры», обязательно наличие подробного технического задания.
— Надо не только привлекать правильных специалистов, но и задавать правила и строить работу так, чтобы у каждого участника был мотив и возможность реализовать свой потенциал.
— Руководители должны участвовать в принятии важных решений на протяжении всего проекта, чтобы неопределённость не накапливалась скрытно.
— Опасный источник неопределённости — отсутствие сильного лидера проекта.
— При переходе незримой границы сложности невозможно создать продукт без предварительного проектирования.
— Начинающие разработчики и просто дилетанты, современная модель обучения, готовящая узких специалистов, непонимание, чем является проектирование, — всё это подпитывает скептическое отношение к проектной документации.
— В результате современные методы создания продуктов больше напоминают модные диеты, основанные на предрассудках, чем полноценные системы питания.
— Чем тщательнее к своей работе подходят проектировщики интерфейсов, тем чаще сталкиваются с тем, что реализовать всё задуманное не получается.
— Для кого-то это может показаться странным, но проектирование сокращает бюджет и сроки проекта.

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

Usethics написали о частых ошибках при проектировании интерфейса терминала. Вот часть из них:

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

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

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

6. Сценарий прерывается. Например, в торговом центре пользователь построил маршрут до магазина, но не может сбросить его себе на телефон и поэтому фотографирует. Продумывайте такие моменты. Можно показать QR-код со ссылкой на страницу с этим маршрутом.

7. Нет приглашения к взаимодействию. Люди воспринимают тач-панель как рекламный стенд. Напишите, что можно с её помощью сделать, покажите строку поиска.

https://medium.com/usethics-doc/6ae5f09169d6

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

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

Будьте готовы предоставить поддержку на местном языке. При выходе на новый рынок важна скорость получения обратной связи.

Обратите внимание на культурные различия. Могут отличаться термины, шутки, цветовая гамма, числа, меры и целые изображения.

Перед началом перевода создайте глоссарий — список терминов и имён, которые должны остаться неизменными в процессе локализации.

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

При создании элементов интерфейса имеет смысл закладывать минимум 30% дополнительного пространства для других языков. Особенно актуально для коротких строк: пунктов меню, форм и так далее.

Например, немецкая версия текста в среднем на 30% длиннее английской, а русская — на 10%. То же самое обычно справедливо для арабской локализации. Традиционные китайские иероглифы требуют на 30% меньше места, чем латинский алфавит.

https://habr.com/ru/company/alconost/blog/507734/

Александр Всехвальнов написал, как устроен отбор дизайнеров в Ситимобиле. Несколько интересных моментов:

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

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

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

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

https://habr.com/ru/company/citymobil/blog/499882/

Ирина Красильникова написала о дизайне для детей.

— Для ребёнка неочевидна связь между иконкой-гамбургером и меню. Если иконка необходима, тестируйте её понятность;
— Говорите на одном языке: «Придумайте имя пользователя» → «Как тебя зовут?»;
— У детей нет баннерной слепоты. Часто они не отличают рекламу от содержимого продукта и отвлекаются. Если у вас образовательный продукт, откажитесь от баннеров в учебном интерфейсе;
— Дети ожидают немедленной реакции на любое своё действие. Хвалите после каждого правильного ответа;
— Ребёнок не понимает абстракций, используйте в дизайне узнаваемые предметы из реальной жизни. Чем реалистичнее картинка, тем лучше;
— Несколько однотипных заданий подряд могут демотивировать. Чередуйте типы активности, закладывайте время на отдых;
— Восприятие в 6 и 10 лет сильно отличается. Для 6-летних контент более мультяшный и игровой, с озвучкой для тех, кто не умеет читать. Для 10-летних — более сдержанный;
— Лучше сделать проще, но быстрее и надёжнее. Подростков сильно раздражают любые баги и зависания;
— Не забывайте об экстремальных пользователях: детях не читающих, с недостаточным опытом взаимодействия с компьютером, с низкой концентрацией внимания, с нарушениями зрения.

#young

Сделал конспект книги Нира Эяля «Покупатель на крючке» — о том, как создавать продукты, вызывающие привыкание.

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

Триггер → Действие → Вознаграждение → Инвестиция → Внутренний триггер.

https://vandergrav.ru/hooked-book-big-summary/

Дарья Дундукова написала ёмкую вводную статью о UX-писателях.

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

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

https://netology.ru/blog/07-2020-ux-copywriter

Кирилл Беляев предложил способ уплотнения столбцов в таблице.

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

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

https://kirillbelyaev.com/ru/blog/all/sealing-columns-in-table/

Эндрю Койл написал о дизайне карточек.

Карточка — компонент интерфейса с краткой информацией и точкой перехода к дополнительной информации.

— Сокращайте содержимое карточки. Его должно быть столько, чтобы понять, стоит переходить к дополнительной информации или нет;
— Если с карточкой связано несколько действий, выделяйте главное;
— У содержимого должна быть визуальная иерархия;
— Не увлекайтесь разделением содержимого линиями;
— Связывайте с карточкой одно действие или их ограниченный набор. Не добавляйте в неё произвольные ссылки;
— Контролы переключения между карточками и индикатор их количества располагайте вне карточки;
— Карточки можно заменить списком, если содержимое однородно и не занимает несколько строк. Это ускорит их сканирование;
— Или таблицей, если в содержимом много переменных одного типа.

https://ux.pub/8-pravil-kotorye-pomogut-vam-sproektirovat-luchshiy-dizayn-kartochki/