Каждый заказчик желает сделать лучший и уникальный в своем роде продукт, который вызывал бы у пользователей восторг, покрывал их потребности и приносил прибыль. Желательно бы еще потратить на создание такого продукта поменьше ресурсов.
В достижении всего вышеупомянутого дизайн (UX/UI) играет не последнюю роль.
В этой статье я тезисно перечислила то, что, по моему мнению, лучше соблюдать при создании продукта (например, цифрового: какого-нибудь сайта, веб-приложения и тд), чтобы UX/UI как минимум соответствовал основным правилам дизайна, а в перспективе оказался бы успешным.
1. Исследуйте отрасль, рынок, конкурентов и, конечно же, пользователей
Всё большее количество заказчиков начинает понимать ценность исследований, но некоторые продолжают сопротивляться. И если исследование отрасли, рынка и конкурентов – это, вроде бы, более-менее вписалось в процесс разработки продукта, то о пользователях забывают.
Нечестно оставлять без внимания тех, кто приносит прибыль, не учитывать их предпочтения, не стараться улучшить их опыт взаимодействия с продуктом.
Даже если объяснить заказчику всю необходимость проведения исследования пользователей, затрачиваемые на это ресурсы могут склонить чашу весов не в сторону UX, потому что не всегда заказчик думает о будущем и о том, что на самом деле исследования сэкономят время и деньги, когда вдруг окажется, что пользователям, например, непонятна навигация, или они не смогут найти нужный товар, добавить его в корзину и всё в этом роде. Словом, исследования снижают риск того, что пользователи не смогут достичь той цели, ради которой они начали пользоваться продуктом. А ведь недовольный пользователь может расстроиться, уйти и не вернуться.
2. Accessibility (доступность)
Только ленивый не написал о том, как важно учитывать доступность при создании продукта.
Пользователи бывают разные – у всех свои особенности и ограничения. Хорошим продуктом может пользоваться и человек с особенностями восприятия цвета, и текста, и с двигательными особенностями, и тд.
Если целевая аудитория в основном состоит из людей с конкретными особенностями, учитывать доступность – святой долг. Если нет, стоит учесть хотя бы доступность цвета и текста. И при этом желательно, чтобы у пользователя не возникало чувство отвращения к продукту, а, наоборот, преобладало восхищение:
“ну каков же интерфейс! всё-то здесь accessibility”
а так вообще кто-нибудь говорит?
кажется, нет, но хотелось бы
Говоря об общей доступности, особое внимание можно обратить на следующие темы: контрастность цветовой схемы, читабельные шрифты (сюда же размер шрифта, межстрочный интервал), адаптивность к разным экранам, гаджетам. Эти темы – цветочки в плане доступности, но без цветочков нет смысла думать о ягодках.
3. Не создавайте велосипед
Если при создании продукта вы придумали нечто гениально новое – погуглите. Возможно, это уже было придумано ранее, а также протестировано на настоящих пользователях и оформлено в инструкцию по применению, библиотеку компонентов. Это также сэкономит время разработки.
Позвольте пользователю взаимодействовать с знакомыми элементами дизайна, попробуйте упростить интерфейс и путь пользователя вместе с ним.
Всё, что нужно пользователю для достижения его цели, должно быть очевидным, понятным и легко доступным.
4. Подсказки и обратная связь
Если продукт, интерфейс всё же оказался сложным, узкопрофильным, добавляйте подсказки, тултипы, проводите онбординг пользователя. Это увеличит шансы достичь цели, ради которой
Также хорошо дать пользователю возможность оставить обратную связь, написать в поддержку. Это поможет пользователю решить его вопрос, а заказчику понять, какие пробелы существуют в продукте, что пользователю осталось непонятным.
5. Ревью верстки
Возьмите за правило проводить ревью сверстанных макетов, реализованного дизайна. Очень-очень часто верстка сильно отличается от дизайна. Возможно, причинами тому служат творческий порыв верстальщика, недостаточно материалов от дизайнера, отсутствие или не особо хорошая коммуникация между дизайнером и верстальщиком.
Нельзя просто так взять, отрисовать макеты, создать прототип и скинуть на них ссылку команде разработки. Важно еще и объяснить что, как, почему отрисовано, какие состояния и анимация у элементов дизайна, где их можно (если можно) посмотреть с точки зрения кода (привет, Material Design, и все в этом роде).