Проектирование интерфейсов как оно есть. Процесс, особенности и нюансы.
Уже больше года я работаю в команде Tele2, где занимаюсь интерфейсами. У меня есть свой продукт, программа лояльности “Больше”: web версия и теперь уже отдельный блок в приложении Мой Tele2. Основная работа связана с интеграциями и разработкой различного функционала: от системы управления контента (CMS, читай административная панель), до эксклюзивных партнерств и механик.
Довольно часто появляются задачи, связанные с проектированием интерфейса, с тем, что именно увидит пользователь и с чем потом будет взаимодействовать, решая свои задачи. Вот, решили поиск запустить, как он должен выглядеть и работать? А вот, фильтры обновить надо, почему?
Сегодня хочу поговорить о самой сути проектирования и поделиться опытом того, как это работает у нас.
Проектирование интерфейсов: это основа
Давайте представим себе скелет рыбы. Они все разные, ну пусть будет такой.
Скелет и кости устроены таким образом, чтобы держать мышцы рыб и обеспечивать движение плавников. Распределение нагрузки на костяной каркас рыбы позволяет ей плавать, как ни в чем не бывало, кушать водоросли и наслаждаться жизнью. За нее уже все продумала и спроектировала сама природа так, чтобы ее вид мог выживать и развиваться.
С проектированием веб интерфейсов дела обстоят немного сложнее, так как за нас никто не поработает и только нам решать конкретные задачи пользователей. Ключевое слово здесь “задачи”, так как именно они лежат в основе здорового проектирования. Попробую сформулировать, что такое проектирование интерфейсов в двух словах.
Проектирование интерфейсов – это процесс решения конкретных задач пользователя через взаимодействие с цифровыми продуктами с учетом возможностей, требований и ограничений (бизнеса, технологии).
Кто занимается проектированием
Есть соблазн сказать, что вот же, есть ux/ui дизайнеры, обратился к ним за помощью, а потом получай результат. Но тут не так все просто. Ключ в информации и понимании полного контекста задач. Ты, как продакт, видишь (должен видеть) всю картину в целом, от задач пользователей до бизнес требований, от ближайших фич до стратегии развития всего продукта. Чем плотнее ты работаешь с дизайнером, тем более полным будет решение при проектировании.
В крупных компаниях, где разные продукты тесно связаны друг с другом, необходимо учитывать полную картину взаимодействия. Для этих целей используются общие встречи по проектированию (у нас в Tele2 они называются дизайн-сессиями). На таких встречах присутствует вся команда: отряд продактов по разным направлениям и дизайнеры.
Продакт вместе с дизайнером готовит варианты решения задач и презентует их всей команде. На таких встречах можно собрать полезные комментарии от коллег и скорректировать свое решение. Зачастую ты просто можешь пропустить что-то важное (технические ограничения, элементы фирменного стиля, аналитика, необходимость доп.интеграции и прочее). Дизайн-сессия позволяет закрывать большую часть вопросов до выхода интерфейса в продуктив (когда уже увидят реальные пользователи) и является неотъемлемой частью проектирования.
Откуда начинается проектирование
Как вы могли уже догадаться, начинается оно с задач, которые должен решать интерфейс. На практике вытащить их из заказчиков не так то и просто.
Во-первых задач может быть несколько. То есть, один думает, что мы решаем эту задачу, другой думает про другую. Как тут быть? Приоритезировать задачи с учетом ценности, которую они принесут твоему продукту.
Во-вторых они могут быть неясно сформулированы. “Хотим, чтобы фильтры в каталоге были более понятные” или “Сделайте корзину более заметной”. Что с этим делать? Помогать заказчикам переформулировать задачи. Конкретизировать их до конкретных ценностей, а лучше метрик:
“Хотим, чтобы фильтры в каталоге были более понятные” – “Хотим увеличить CTR фильтров ”
“Сделайте корзину более заметной” – “Необходимо увеличить кол-во заказов с корзины”
Для фильтрации задач используйте бриф с основными вопросами, которые помогут заказчику сформулировать задачу более четко и понятно. Здесь вам и контекст, и смысл, и ожидания. Про бриф я рассказывал более подробно здесь и даже предложил свой пример, который можно брать в работу.
Задачи вытащили, идем дальше
Благо теперь у вас есть задача, а это, скажу я вам, уже 50% успеха (правда, просто поверьте). Переходим непосредственно к проектированию. Относительно недавно на работе с товарищем завязалась беседа, по-поводу того, как ставить задачи дизайнерам и оказалось, что существует принципиально два разных подхода:
- Ставятся задачи, которые должен решить интерфейс. Дизайнер предлагает решения. После идет обсуждение и развитие этих решений вместе с продактом.
- Сразу предлагаются решения в виде мокапов, набросков от продакта. Далее вместе с дизайнером предлагается их развитие.
Каждый подход по-своему хорош, но и не лишен недостатков.
Первый (решение дизайнера) дает в полной мере свободу творчества. Продакт менеджер не вовлекается в подбор решений, а работает с тем, что ему предложили. Классно, что можешь довериться дизайнеру и посмотреть его варианты. Не классно, что твои ожидания могут не оправдаться и придется потратить немало времени на обновление решения.
Второй подход (решение продакта) подразумевает, что сам продакт ищет решение, смотрит примеры интерфейсов на рынке и проектирует до уровня набросков, а дальше уже вместе с дизайнером занимается развитием. Классно, что твои ожидания уже сформированы и есть на что опираться для развития. Не классно, что своим решением ты можешь сразу ограничить дизайнера и не увидеть альтернатив.
Оба подхода имеют право на существование. У нас в команде, например, я топлю за второй подход, а мой коллега за первый, поэтому наши дизайн-сессии становятся еще ценнее из-за разных точек зрения.
Не забудь про сценарии
Проектирование интерефейсов, это про взаимодействие. Ты думаешь о том, как пользователь будет взаимодействовать с твоим продуктом и решать определенные задачи.
У тебя есть решение, но какие контекстные сценарии оно затрагивает? В каких ситуациях человек, например, возьмет телефон в руки, зайдет в приложение и начнет наполнять корзину товарами? Держать всю цепочку шагов в голове проблематично, да и не нужно, просто нарисуйте процесс.
Сфокусируйтесь на основном сценарии, в котором будет использоваться ваше решение. Подумайте, какие барьеры и на каких этапах могут возникать. Порой достаточно ограничиться только средой вашего продукта для того, чтобы набросать взаимодействия с конкретным решением.
Например для задачи с корзиной: пользователь просматривает каталог товаров и может накидать себе в корзину разных товаров.
Ориентируясь на сценарии пользователя, сделайте апгрейт своего решения, если необходимо. После этого презентуйте финальный вариант команде на дизайн-сессии.
–
Если вам жалко кота Тома в мультфильме “Том и Джери” и вы хотите знать, когда появятся материалы в блоге, то подписывайтесь на наш telegram канал! Кстати, в канале есть материалы, которые не выходят на сайте, так что заглянуть точно стоит 😉 Продолжаем читать…
–
Проверка решения
Наше решение прошло ревью всей команды, учтены комментарии и готовы эскизы, осталось только в спринт положить и вот оно! Не спешите тратить ресурс разработки. Кто как не пользователь скажет будет ли работать то, что вы предложите или нет.
Проектирование интерфейсов без пользовательского фидбека невозможно. Проверьте свое решение с помощью прототипов, mvp, опросов и прочего.
Чтобы не разрабатывать то, что никому не нужно, как можно раньше покажите пользователям решение и соберите данные о том, нужно ли оно вообще. Так вы обезопасите себя от потерь ресурсов и волос на голове, когда “пилили, пилили, а оно не нужно”. Про проверку гипотез и решений рекомендую почитать в этом материале.
Пользователь проголосовал, значит делаем
Провели эксперименты, проверили гипотезы и пользовательские метрики показывают, что решение себя оправдало. Значит берем в работу. Добиваем финальный дизайн, кладем в спринт и выкатываем на прод всем пользователям.
Теперь и пользователь счастлив и вы, потому что метрики, на которые вы закладывались с решением, растут. У фильтров повысился CTR, а через корзину кол-во заказов увеличилось на 10%. Проектирование интерфейсов выполнено на славу.
Принципы хорошего интерфейса
На последок хочу поделиться с вами основными, на мой взгляд, принципами хорошего интерфейса.
- Ясность и понятность. Пользователю не нужна инструкция, чтобы решить свою задачу через интерфейс.
- Ничего лишнего, только необходимые для решения задачи элементы интерфейса.
- Фокусировка. Есть основные элементы интерфейса, есть дополнительные, расставьте четкие визуальные акценты для решения задачи пользователя.
- Привычки против моды. Отдавайте предпочтение уже знакомым пользователю элементам интерфейса, нежели создавайте “шедевры”, которыми не будут пользоваться.
- Группировка. Объединяйте информацию в смысловые блоки, ну заставляйте пользователя вчитываться в каждую букву, чтобы понять суть.
- Единообразие. Если в одном разделе сайта кнопки выглядят определенным образом, то и в других частях, они должны выглядеть также.
- Эволюция. Интерфейсы не стоят на месте, они должны развиваться, иначе пользователь быстро потеряет к ним интерес. Следите за трендами и старайтесь идти в ногу со временем.
Используйте эти принципы как чек-лист при проектировании, спрашивайте себя, а правда ли это решение понятно пользователю? Или, не забыл ли я расставить акценты на важных элементах?
Итоги
Проектирование интерфейсов, это очень интересный процесс. Тебе приходится решать ряд задач и учитывать кучу ограничений, но вы только представьте себе какой кайф ты испытываешь, когда видишь, что твоими решениям пользуются люди. Проектируйте с чувством, проектируйте с удовольствием и делайте счастливыми своих пользователей.
Алексей А.
Читайте также:
Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.
Ахахаххаха, просто божественный ролик про фанатов футбола, которые пропускают ключевые моменты матча во время разных ситуаций. Эта игра актеров и сама идея просто великолепны, браво Heineken, браво режиссеры!
16 Дек 2018 в 22:30
Классный сайт!