Некоторые тезисы и цитаты из 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/

В КБ «Собака Павлова» написали о процессе и результате исследования, с помощью которого пытались понять:
— Зачем компании заводят несколько счетов в разных банках;
— Зачем отправляют деньги своим контрагентам в другие банки, когда у них есть счета в одном.

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

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

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

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

Это одно из главных преимуществ независимого исследования — возможность выстроить доверительное общение с респондентами и получить ценные инсайты».

https://vc.ru/finance/144855

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

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

Обращайте внимание на нюансы мотивации пользователя, так как это может вдохновить на новые решения. Например, Hulu перематывает видео вперёд на 30 секунд (удобнее пропускать ненужные сцены), а назад — всего на 10 (можно точнее находить нужные). Значения можно привязать к длине ролика.

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

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

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

[English] https://uxdesign.cc/6aa81a8f4d2b

Заметка подготовлена совместно с @vanillatime.

Дэнни Сапио поделился примечательными советами из Human Interface Guidelines.

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

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

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

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

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

Если действие пользователя ведёт к потере введённых им данных, сообщите об этом и объясните, как избежать потери.

Не включайте в пуш-уведомления чувствительную, личную или конфиденциальную информацию.

https://habr.com/ru/company/skillfactory/blog/510848/

Виктор Губанов рассказал, зачем и как дизайнерам-новичкам получать обратную связь о своей работе.

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

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

Сообщайте контекст: какая была задача, технические и временные ограничения и иные значимые детали проекта.

Уточняйте область, по которой хотите получить фидбек. Просите не просто посмотреть макет, а укажите, на что именно обратить внимание: типографика, сетка, цвета, динамика и так далее.

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

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

https://ux.pub/kak-dizayneru-novichku-rabotat-s-fidbekom-chtoby-stat-profi/

Люси Тодд рассказала о разных способах визуализации данных: гистограммах, линейных графиках, круговых и кольцевых диаграммах, квантограммах и типографике.

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

Круговыми и кольцевыми диаграммами нельзя показывать процент изменения показателя. Если просмотры брендированного видео на Ютубе увеличилось на 99%, нельзя показывать это круговой диаграммой, заполненной на 99%.

Квантограмма — повторение пиктограммы или иконки, показывающее количество. Отлично подходит для изображения небольших чисел. Например: на улице открылись 12 новых ресторанов; на улице 3 из 4 ресторанов подают пиццу.

https://vc.ru/design/145809

Евгений Игнашов написал о GOMS-анализе.

Стоит ли использовать его для оценки удобства интерфейса? Нет, если при работе с интерфейсом никто не умирает от задержки в 0,3 секунды.

The model of Goals, Objects, Methods, and Selection rules (GOMS) — метод исследования, позволяющий предсказать, сколько времени потребуется опытному пользователю на выполнение конкретной операции при использовании конкретного интерфейса.

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

Для примера Евгений проанализировал два разных интерфейса перевода градусов из Цельсия в Фаренгейт и наоборот.

https://habr.com/ru/post/512712/

Пейдж Лаубхаймер из Nielsen Norman Group написал о трёх типах персон.

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

Качественные персоны — создаются на основе качественного исследования пользователей. Самый универсальный вид персон, так как не требует больших трудозатрат и обладает достаточной точностью для принятия решений. Этакий перочинный нож или Фольксваген Гольф 2.

Статистические персоны — создаются аналогично качественным, но каждый инсайт дополнительно проверяется на количественных данных. То есть нужно не только провести серию полевых интервью, но ещё и настроить аналитику так, чтобы собирать необходимые данные с необходимых пользователей в необходимое время. Эту махину нужно постоянно обновлять и настраивать, чтобы сохранять актуальность данных. Вы получаете максимально точный инструмент… но стоит ли он того?

[English] https://www.nngroup.com/articles/persona-types/

Заметка подготовлена совместно с @vanillatime.

Михаил Озорнин написал о типе визуализации «Регулярные карты».

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

Самое сложное — сохранить узнаваемость. Для США таких карт полно, а Россия в карте из квадратов становится неузнаваемой, так как регионы очень разные по размеру.

В 2017 году прошёл конкурс регулярных карт для России, где победил вариант Ивана Дианова.

— Пост Михаила: http://mikeozornin.ru/blog/all/election-chart-redesign/
— Работы конкурсантов и итоги: https://telegra.ph/Uchastniki-i-ih-raboty-12-03
— О проекте Ивана [English]: https://medium.com/kompany/92190d14e41e

Сделал конспект книги Майка Монтейро «Дизайн — это работа».

Вот, например, маркеры плохого клиента:

— С порога диктует, что нужно, и объясняет, в какой цвет это покрасить. Это не дизайн, а производство;
— Даёт понять, что опускает свою планку, работая с вами. Хорошая работа получится только при взаимном уважении;
— Обратился к вам неохотно и не ценит дизайн. Если он не ценит вашу работу, он неохотно будет платить и сотрудничать. Штатные дизайнеры могут считать, что проект стоило поручить им. Стартаперы — что работа с подрядчиком затормозит работу. Они будут стремиться доказать, что ваши услуги не нужны, и пытаться абстрагироваться от процесса;
— Предлагает работать за долю в бизнесе;
— Говорит, что это хороший проект для портфолио, и хочет работать по ценам ниже рыночных. Если он с самого начала не уважает вас, результат вряд ли будет выдающимся;
— Это не ключевой для бизнеса проект. Не стоит участвовать в конъюнктурных попытках заполнить нишу на рынке. Пока вы работаете, кто-нибудь другой заполнит её, и клиент решит заняться чем-то другим.

https://vandergrav.ru/design-is-job-book-summary/

Тесс Гадд написала о радиокнопках и чекбоксах.

Что это такое, анатомия радиокнопки и чекбокса, разница между ними, встречающиеся стили отображения, возможные состояния.

Когда использовать радиокнопки:
— Пользователь может выбрать только один вариант;
— Вариантов меньше шести;
— У пользователя не должно быть возможности «не выбирать», если он уже выбрал один из вариантов. Нажатие на выбранный вариант в группе радиокнопок не приводит к отмене выбора этого варианта;
— Для сохранения выбора пользователь нажимает на специальный контрол (например, кнопку «Сохранить»).

Когда использовать чекбоксы:
— Пользователь может выбрать несколько вариантов или не выбрать ни одного;
— Один вариант, на который пользователь должен ответить «да» или «нет». Например: «[v] Я соглашаюсь с офертой».

https://ux.pub/radio-buttons-checkboxes-i-drugie-vidy-selektorov/

Джордж Кейв объяснил правила хорошего интерфейса на примере панелей управления из Лего.

Во время Второй мировой войне пилоты «Летающей крепости» при посадке часто выпускали закрылки вместо шасси. Ошибка происходила из-за одинаковой формы рычагов. Придумали обклеивать рычаги разными накладками — пример кодирования по форме.

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

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

https://vc.ru/design/148285