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

. Нам следует обратить особое внимание на запускающие какой-то процесс (workflows) элементы продукта. Например, процесс регистрации, заполнения профиля пользователя, покупки какого-либо товара и т.п.

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

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

. В решении конфликтов с пользователями нам следует стараться избегать отсылок на правила использования сервиса, или какие-то другие условия, которые пользователь мог просто не заметить.

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

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

. Мы должны учитывать предрассудки нашей аудитории. Пример использования предрассудков: избегание использования чисел типа «13», «666» и им подобных. Другой пример: при отправке временного кода доступа к приложению (One-time password), мы можем использовать красивые, похожие числа символизирующие удачу (777555) и т.п.

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

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

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

. Мы можем периодически напоминать пользователю о том хорошем опыте, который он с нами получил. Простой пример: функция «Most liked photo» в Facebook, периодически показывающая самые популярные фото нашего профиля и т.п. Мы можем ссинхронизировать тайминг для подобных напоминаний с хорошими событиями для пользователя в продукте ().

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

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

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

. Механизм последовательного вспоминания является особенно важным в разработке рабочих процессов для пользователей (workflows).

. Нам следует избегать неоднозначных формулировок. Чтобы избежать разночтений и расплывчатости в любой части продукта нам следует снабжать пользователей инструкциями (tooltip-ы, hover-text-ы, и т.п.).

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

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

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

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

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

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

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

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