UX Notes

Лена Нексман написала об ошибках в анимации сайтов и приложений.

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

Оксана Киселёва написала о чекбоксах и радиокнопках.

— Радиокнопки используют для списков из двух и более взаимоисключающих вариантов, когда можно выбрать только один;
— Чекбоксы — когда можно выбрать несколько вариантов или не выбрать ни одного;
— Списки вариантов располагайте вертикально, так их легче просматривать;
— Текстовую подпись размещайте рядом с селектором (квадратным у чекбокса, круглым у радиокнопки), так понятнее, к чему она относится;
— Избегайте отрицания в подписи (если вы, конечно, не адепт тёмных паттернов): «Не присылать оповещения» → «Присылать оповещения». Иногда группа из 2 радиокнопок может быть понятнее одного чекбокса;
— В группе радиокнопок один из вариантов должен быть выбран по умолчанию;
— Нажатие и на селектор и на подпись должно приводить к выбору варианта;
— Нажатие на чекбокс или радиокнопку должно приводить к выбору варианта, а не выполнению действия (для действий используют кнопки);
— Сделанный с помощью чекбоксов и радиокнопок выбор сохраняйте не автоматически, а после подтверждения пользователем (нажатие на кнопку «Сохранить» или «Применить»).

#checkbox #radio_button

В Markswebb написали, как научить держателей кредиток правильно ими пользоваться и мотивировать к покупкам.

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

Илья Бирман посоветовал, как интернет-магазин может рассказать о скором расширении ассортимента.

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

Майкл Виллар написал о контекстных меню.

— Они открываются нажатием на правую кнопку мыши (чаще всего) или кнопку контекстного меню;
— Если есть место, левый верхний угол меню располагается под курсором или кнопкой контекстного меню. Если места снизу нет, меню можно отобразить над ними или сместить;
— При отображении меню полезно выделять объект, с которым оно связано. Будет понятно, в отношении чего будет выполнено то или иное действие;
— Добавьте возможность перейти к пункту меню, напечатав начало или часть его названия. Обычно в этом случае выделяется первый подходящий пункт;
— Добавьте навигацию по пунктам с помощью клавиш «Вверх», «Вниз», «Влево» (закрыть подменю), «Вправо» (открыть подменю), «Ввод» (выбрать пункт), Esc (закрыть меню);
— Можно закольцевать переход между пунктами, чтобы нажатие «Вниз» позволяло переходить от последнего пункта к первому;
— Если пользователь выбрал пункт, перед закрытием меню полезно показывать обратную связь о том, что пункт был выбран, а не просто меню закрылось. В macOS выбранный пункт мигает;
— Группируйте похожие или связанные друг с другом пункты;
— Отключайте недоступные пункты. Так меню будут выглядеть одинаково, и пользователи будут знать, что действие возможно в другом контексте;
— Отображайте сочетания клавиш для пунктов;
— Добавляйте «…» к названию пункта, если после его выбора пользователю придётся вводить данные;
— Анимация появления и скрытия контекстного меню и его подменю может снизить скорость работы с ним;
— Используйте «безопасный треугольник», чтобы подменю не скрывалось, пока пользователь ведёт к нему курсор от связанного пункта меню.

Егор Красноперов рассказал о роли дизайн-менеджера.

— После появления в компании отдельных продуктовых команд дизайн-решения становились всё более неконсистентными, а их качество — нестабильным. Снизилась скорость доставки фич;
— Поняли, что нужно дизайн-комьюнити с ментором, чтобы договориться, как принимать решения, оценивать качество дизайна и так далее. Быть ментором может любой инициативный дизайнер;
— Решить проблемы с качеством помогли: выстроенный процесс дизайн-ревью, дизайн-принципы, формализованные критерии оценки дизайна (чеклист), дизайн-система, разделение продуктового и брендингового дизайна;
— С ростом дизайн-команды появились вопросы: куда расти, как развиваться, как оценивать рост. Выделили дизайн-менеджера, создали карту навыков;
— Задачи дизайн-менеджера: найм дизайнеров, распределение по командам, оценка, повышение и увольнение, развитие дизайн-комьюнити, ответственность за результат работы дизайнеров, верхнеуровневый поиск проблем с UX, помощь в формировании видения продукта и в качестве эксперта при обсуждении, декомпозиции и реализации задач;
— Для дизайн-менеджера любая победа — победа команды, поражение команды — его неудача;
— Ему важно прокачивать продуктовое мышление, мыслить как владелец продукта (какую проблему решаем, как поймём, что решили её, как решение повлияет на бизнес-метрики, приоритет), а также находить слабые места в продукте (начать пользоваться продуктом, общаться с поддержкой, отслеживать метрики);
— Также важно научиться давать и принимать обратную связь (особенно неприятную), играть в долгую (не ждать быстрых результатов и распределять свои силы, чтобы не выгореть), не становиться бутылочным горлышком (не замыкать на себе все решения).

Саша Окунев написал о проведении первичной встречи по продуктовой задаче.

— Вопросы брифа помогают структурировать разговор, расставить в нём акценты и с минимальными усилиями получить от заказчика (ПМ или представителя бизнеса) информацию для принятия дизайн-решений;
— Для мелких задач такой бриф будет излишним;
— Цель первичной встречи — выяснить проблему, которую может решить дизайн;
— Как заказчик видит проблему или задачу в общих чертах? Это должно быть именно описание проблемы, а не набор конкретных решений;
— Как проблема влияет на бизнес в целом, как она приводит к потере денег? Сумма потерь поможет в дальнейшем приоритизировать задачу;
— Чью проблему вы решаете и кто кроме них вовлечён в процесс? Так вы будете знать, где их найти, и видеть полную картину взаимодействия;
— Какие проекты решили похожие задачи? Использование лучших практик с рынка облегчает жизнь пользователей, которые уже знакомы с другими продуктами и их решениями;
— Какие сущности вовлечены в процесс? Зная их, можно выстроить схему взаимодействия, а на более позднем этапе аналитики — структуру каждой;
— Как проблему решали в компании ранее? Для оценки приоритетов важно знать последствия: что будет, если проблему не решать;
— Усугубится ли проблема в будущем? У задачи может быть естественный дедлайн, повышающий её важность;
— Какие метрики могут быть у задачи? Исследуя, как работает система по метрикам, можно найти интересные гипотезы. Аналитика даёт аргументы в спорах и уменьшает их количество;
— Как определить, что проблема решена? Можно сравнить новое решение со старым по метрикам или провести исследование. Идеальный ответ затрагивает изменение бизнес-процесса, а не само наличие новой функции.

Данил Ковчий рассказал о своём подходе к дизайну, создании логотипа Яндекс Еды, работах для Яндекс Такси и Таксометра, логистического продукта DMS, Emex.

— Образ — клей формы и содержания, чувственно воздействующий объект;
— Образ воздействует на зрителя и направляет автора (или авторов), становится системой координат;
— С образной системой координат проще принимать и объяснять решения (что сокращает споры и душевные терзания), а также сохранять контроль, эти решения делегируя;
— Найти образ с помощью логики нельзя по определению, но анализ найденных (и созданных) образов позволяет перенести их в инженерию и построить модель;
— Исследуя найденный образ, применяя его в разном контексте, можно находить новые образы, складывать образные концепции;
— Образная концепция важнее и полезнее гайдлайна (особенно на первое время), так как указывает на возможные следующие шаги;
— Экран интерфейса оживает, когда начинает разговаривать. Словами можно и уничтожить впечатление от проделанной работы, и возвести его в квадрат;
— Если соединить образ с функцией и убрать всё лишнее, своим видом предмет будет вызывать интерес к своей функции;
— Образы рождают модели, модели формируют технологию. В стерильных инструментах для бизнеса сразу хочется перейти к моделям, но для дизайнера работа над моделями — самый трудоёмкий процесс, а образы его упрощают;
— Когда предпосылок для образа нет, их надо создавать, замешивая родительский бренд (если есть), отличительные черты и уникальные термины, внутренние ценности компании;
— Модель — описание чего-либо на формальном языке (с точными правилами построения выражений и их понимания);
— Конечный результат дизайна — модель, передаваемая технологии для реализации. Качество дизайна = качество этой модели;
— Основные причины плохого дизайна: 1. Бессвязные формальные конструкции (дизайнеры не могут их объяснить, образы случайны); 2. Противоречивые описания на естественном языке;
— Элемент интерфейса «Кнопка» становится сложноподчинённым воплощением компонента кнопки, у которого есть состояния, поведение, стиль, тип (обычная, акцентная, цветная, парящая), тема (день, ночь), платформа (десктоп, телефон, телевизор), код, документация, тесты и так далее;
— Абстрактные компоненты (у которых есть состояния и поведение, но нет свойств, связанных с брендом) одинаковы в разных продуктах. Интерфейс нового продукта не надо собирать с чистого листа;
— Сразу раскладывайте новый компонент на состояния, чтобы найти сочетания, которые могут понадобиться в будущем, и увидеть крайние случаи. Вы первыми должны пытаться сломать свой дизайн;
— Компоненты вкладываются друг в друга, одни компоненты можно преобразовывать в другие, например, список → всплывающая подсказка, вложенное меню, частный случай таблицы, календарь. Подобная паттернизация ускоряет дизайн, создаёт приятную графическую рифму между экранами, на большой дистанции ускоряет и упрощает разработку.

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

— Сложные конструкции с нанизыванием слов. В английском этот приём позволяет творить чудеса, но злоупотреблять им не стоит. Например, выражение Nginx error log path (Путь к логу ошибок Nginx) лучше заменить на более понятное Path to Nginx error log. И ещё пример: Port scanner check interval → Port scannning frequency;
— Кальки с родного языка. Например, столбец со временем создания на английском обычно называют Created, а не Time of creation. И ещё пример: Login name (Имя пользователя) → Login;
— Лишние слова. Если страница настроек разделена на секции (Nginx section, Monitoring section, Logs section и так далее), слово section в заголовках секций будет лишним;
— Ещё авторы интерфейсных текстов бывают невнимательны к грамматике и пишут непонятные широкой аудитории описания, но так ошибаться они могут и на родном языке.

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

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

Дмитрий Капаев написал, почему готовые рецепты исследований не работают.

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

Стас Мельников поделился тремя советами, как сделать интерфейс удобнее. Тематически они не связаны, просто сформулированы в марте — такой уж у автора формат.

— Если пользователь ввёл адрес электронной почты, но не смог авторизоваться (ввёл неверный пароль), подставляйте введённый ранее адрес в форму восстановления пароля. Например, так делает Booking;
— Если в мобильной версии сайта в поле надо вводить только цифры (например, код подтверждения), укажите для этого поля свойство inputmode=numeric, чтобы пользователю отображалась цифровая клавиатура;
— В тултипе к иконке пишите, что пользователь может сделать, нажав на неё. Например, на Booking у колокольчика тултип «View your notifications», у помощи — «Contact Customer Service», у флага — «Choose your language». А вот на Etsy у колокольчика тултип просто «Updates».

Леонид Межевых, Полина Адрианова и Анастасия Батпаева поделились советами начинающим UX-исследователям.

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

Ребекка Картер поделилась рекомендациями по созданию страницы «О компании».

— Задача страницы — раскрыть суть бренда, подчеркнуть ценности компании и её индивидуальность, укрепить доверие;
— Все компании уникальны, поэтому нет универсальной стратегии, как этого добиться;
— Страница не должна быть большой, у покупателей мало времени;
— Разделите информацию на короткие ценные фрагменты;
— Выделите миссию компании. Если её не описать в одном предложении и не вынести в подзаголовок, посвятите ей отдельный сегмент в начале страницы;
— Разместите социальные доказательства: оценки компании и отзывы из агрегаторов, цитаты клиентов и их логотипы, фрагменты кейсов, отметки о том, что важные игроки рынка и регулирующие органы одобряют работу компании;
— Проверьте, что бренд проявляется в тоне голоса, цветах, шрифтах и прочих элементах страницы (а то вдруг забыли подключить к работе над ней UX-редактора, например);
— Расскажите историю компании. Иногда люди не готовы покупать у новичков. Важные этапы можно описать текстом или, чтобы не грузить читателей, просто показать на временной шкале. Полную историю можно разместить на отдельной странице;
— Покажите фото сотрудников. Если их тысячи, покажите руководство и значимых специалистов. В Tunnel Bear вместо фото показывают аватарки с медведями, отражающими личности сотрудников (позволяет не думать о единообразии фотографий);
— Расскажите о ценностях компании, но рассказ не обязан быть текстовым, используйте иллюстрации и видео.

In English.

Салли Коллинз написала о популярных ошибках на главных страницах интернет-магазинов.

— Показана лишь малая часть из категорий товаров, предлагаемых магазином (менее 40%). Пользователи неверно понимают его специализацию и недооценивают широту ассортимента;
— Агрессивная и отвлекающая реклама. Вызывает негативную реакцию, затрудняет переход к оценке ассортимента (особенно на мобильных), пользователи могут решить, что попали не туда;
— Карусель работает неправильно. Например, меняет слайд за мгновение до того, как пользователь на него нажимает. Есть статья Baymard Institute о том, как правильно. Хорошая альтернатива — распределить по странице секции со статичным содержимым и избранными категориями;
— Не представлены популярные категории и подкатегории. Пользователи не могут быстро перейти к релевантной подборке товаров или переходят в нерелевантные и не находят нужных товаров. Хороший инструмент для магазина игрушек или подарков — визард;
— Скучные фото товаров без контекста, например, без демонстрирующих одежду моделей или играющих с игрушками детей;
— Поле поиска не отображается или малозаметно;
— Всплывающее окно выбора языка малозаметно или похоже на рекламу, предложение пройти опрос или подписаться на рассылку. Хороший вариант — автоматически определять страны пользователей по IP-адресам.

Перевод местами странный, лучше читать in English.

Илона Саркисова завершила серию статей о Customer Journey Map рассказом о том, что делать, если пользователь не является покупателем.

— Пользователями могут быть сотрудники организации. Им не нужно узнавать о продукте и покупать его, так как его навязывает работодатель;
— Классическая CJM им не подходит, но чтобы создать удобный продукт, полезно хоть как-то картировать их опыт;
— Полезен сам процесс создания карты — помогает активировать эмпатию;
— Сначала сформулируйте, для чего нужна карта и что она будет иллюстрировать;
— Для b2b-продуктов может быть непросто определить, чей опыт картировать, так как в работу могут быть вовлечены разные роли, действия которых взаимозависимы;
— Рамки, когда начинается и заканчивается картируемый опыт, зависят от цели проекта. Найдите очевидные моменты начала и окончания и немного отступите от них, чтобы проверить, нет ли ещё важных шагов;
— Состав информации на карте (слои) тоже зависит от целей проекта и должен помогать фокусироваться на главном;
— Процесс картирования: Инициирование → Исследование → Визуализация → Синхронизация (ключевой этап);
— Процесс несколько сместился от создания документа отчётности к созданию практического инструмента. Главным стал не итог, а путь к нему. Авторы карты превращаются в своего рода координаторов, а карта — в трамплин для коллективного осмысления пользовательского опыта (Джим Калбах);
— Поэтому важно правильно инициировать: определить участников, продать им эту активность, спланировать работу до, во время и после воркшопа;
— При визуализации не сковывайте себя типовыми шаблонами, при необходимости меняйте их под себя, а также упрощайте (избегайте больших текстов, визуального шума), выделяйте важное, устраняйте двусмысленность, группируйте всё, что связано;
— Ещё Илона рассмотрела разные виды карт: Service Blueprint, User Experience Map, User Stories Map, Empathy Map.

Смотрите также: первая статья серии, вторая, статья Андрея Шапиро о CJM и SB.

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

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

Эмилия Городовых и Анна Серова написали, как уменьшить когнитивные искажения при проведении пользовательских исследований.

— Когнитивные искажения — ошибки в восприятии информации. Они появляются непроизвольно, чтобы «помочь» нам справиться с неопределённостью или быстро понять, что делать дальше;
— Если знать, когда и как они проявляются, намного проще их отследить и скорректировать своё поведение;
— При формировании гипотез и планировании исследования часто встречаются: 1. Иллюзия асимметричной проницательности (отвергаем картины мира других людей, не слышим критику); 2. Искажение изобретателя (слишком любим свою идею, идём подтверждать гипотезу, а не проверять её);
— Это защитная реакция на неопределённость и наличие противоречий. И это нормально в начале исследования, которое призвано найти ответы и снять неопределённость. Чтобы избежать искажений, фокусируйтесь на процессе, а не результате в виде подтверждённой гипотезы;
— При проверке гипотез: 3. Эффект ожидания наблюдателя (ожидая определённого результата, бессознательно влияем на ход эксперимента, например, задаём наводящие и узкие вопросы); 4. Эффект обратного действия (сомневаемся в качестве выборки и корректности исследования, если гипотеза не подтверждена);
— Чтобы этого избежать, вовлекайте команду в процесс исследования, вместе изучайте скрипты интервью и так далее;
— При анализе результатов исследования: 5. Ошибка базового процента (слишком много внимания уделяем специфичным редким ситуациям); 6. Информационное искажение (ищем новую информацию, когда она уже ни на что не влияет);
— Чтобы этого избежать, подводите итоги исследования или интервью спустя время, уложив мысли в голове и отойдя от эмоций.

Чем отличаются униширинные и моноширинные шрифты?

Униширинный (Uniwidth) — пропорциональный шрифт, в котором ширина символов не меняется при изменении их насыщенности. Текст в начертании Bold занимает столько же места, сколько такой же текст в начертании Regular. Полезное свойство для элементов интерфейса: если болдом выделять текущий пункт горизонтального меню, соседние пункты не будут смещаться. Пример такого шрифта: Golos UI.

Моноширинный (Monospaced) — непропорциональный шрифт, в котором ширина всех символов одинакова. Пример: Courier.

Об униширинных шрифтах in English.

В «Собаке Павловой» написали о решении дизайнерами бизнес-задач.

— Заказчики платят дизайнерам, так как те решают задачи бизнеса. Но дизайнеры часто не могут объяснить, как они это делают;
— Бизнес-задачи всегда комплексные, дизайнеры не решают их целиком;
— Примеры типовых задач: 1. Вывести свои наработки на рынок; 2. Привести интерфейс в соответствие отраслевым стандартам; 3. Создать продукт с нуля по высокоуровневой постановке; 4. Усилить свою экспертизу в UX; 5. Точечно улучшить интерфейс;
— Дизайнеры используют небольшой набор методов: интервью, тестирование, концептуальное и детальное проектирование, создание дизайн-системы и так далее. Это инструменты, они не определяют, что получится в итоге;
— Важно явно фиксировать бизнес-задачу и вместе с заказчиком формулировать дизайн-задачу, закладывая в неё краткое содержание будущих работ;
— Фокус на дизайн-задаче и понимание её связи с бизнес-задачей не гарантирует, но повышает шансы сделать то, что нужно;
— Например, чтобы заказчик вывел на рынок свой продукт, отличающийся от конкурентов хорошим интерфейсом (бизнес-задача 1-го типа), задачей дизайнера будет «Создать интерфейс, который будет выгодно отличаться от аналогов удобством, скоростью работы и эстетикой»;
— Чтобы заказчик прошёл согласование у государственного заказчика, который не принимал промежуточные результаты из-за чрезмерной сложности и недостаточной эстетичности интерфейса (бизнес-задача 2-го типа), дизайнер должен «Перепроектировать интерфейс, существенно не затрагивая логику системы, чтобы он отвечал отраслевым стандартам».

Смотрите также примеры бизнес-задач и диалога для их выявления из лекции Ильи Бирмана «Понимание задачи».