Оценка интерфейсов, введение

За что продуктовым дизайнерам платят много денег:)

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

А ХОРОШИЙ продуктовый дизайнер с большим опытом и реальными УСПЕШНЫМИ кейсами в крупных зарабатывающих проектах — это зп в 200 000 - 300 000 р. на руки (в 2018 г.).

Где найти вакансий на такие деньги? Чаще всего на таких вакансиях не публикуют зп (чтобы избежать потока неправильных людей), а так же стараются найти по знакомству. Соответственно — смотрим, чтобы это был продукт, чтобы компания была богатая, и чтобы требования вакансии указывали на... Пожалуй, я не буду сейчас углубляться в эту сторону, статья о другом.

Но, метрики, тесты, статистика-аналитика... Зачем это? Почему владение ими увеличивает зп?

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

Я заметил одно интересное различие внутри дизайнерского "племени".

1. Есть ребята, которые хорошо знают «как правильно». Есть колористика, она велит делать так, типографика велит делать эдак, сетки, то-се. И в итоге работа над макетом заканчивается, когда дизайнер сделал все "по букве и собственному вкусу, и «продал» макет принимающей стороне.
2. Есть ребята, которые уверены, что в их концепте/дизайне есть косяки и узкие места, и что нужно их найти. Которые считают, что «любой интерфейс плох». И строят свои решения и выводы на изучении аудитории, тестах, и пр.

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

Я не про это. А про разницу подходов:

1. «Это правильно, потому что я профессионал и так положено по тирьямпампистике»
2. «Это правильно, потому что мы проверили и оно работает»

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

Почему неполезно обходиться только своим экспертным мнением и вкусом?

К посетителям сайта нельзя подойти и объяснит, что ты сделал классный и крутой дизайн, а они не шарят.

Они просто покупают/пользуются, или уходят.

Нужно объяснять, как это влияет на зарплату? :) Те дизайнеры, которые приносят бизнесу деньги (больше, прозрачнее и прогнозируемей), сжигая по пути меньше ресурсов (время, ресурсы разработки, трафик) — получают сильно больше.

Из чего складывается рост прибыли наших заказчиков/работодателей (и нашей зп)?

1. Прежде всего, бизнес-метрики. Выручка, прибыль, капитализация, стоимость привлечения пользователя и пр.
2. Дальше идут продуктовые метрики. Они напрямую влияют на бизнес-метрики. Например, конверсия обычных активных пользователей в платящих. Или MAU (уникальные пользователи приложения за месяц). Если любая из этих метрик вырастет — почти наверняка вырастет выручка.
3. Потом UX-метрики. Это какие-то конкретные показатели поведения пользователей. Они появляются, когда мы пытаемся выяснить, а ПОЧЕМУ продуктовая метрика именно такая? Из каких действий пользователя она складывается? Где «бутылочное горлышко?». И, например, мы находим... что MAU в нашем случае небольшое из-за вон той сложной формы, на которой пользователи бросают наш продукт.
4. Тесты. Перед сбором метрик ваше решение хорошо бы протестировать. На коллегах (коридорное тестирование), или на пользователях (полноценное юзабилити-тестирование). Почему — сбор метрик не бесплатен. Он требует времени (можно отстать от конкурентов) и денег (ваше время, разработка, трафик). Кроме того, некоторые узкие места легче найти на юзабилити-тесте.
5. Эвристики, экспертная оценка, тесты на себе. Совсем очевидные и легкие для обнаружения недостатки решения можно найти и убрать самому (если знать как).

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

Тут тонкий момент — важно не сваливаться в обсуждение «нравится/не нравится». Иначе все будет очень долго.

Кратко повторю схему:

1. Нарисовал
2. Проверил экспертно/на эвристиках, поправил.
3. Провел коридорку или потестил на пользователях, поправил, если надо — еще протестировал.
4. Разработали, вылили на продакшн
5. Померил показатели, нашел узкие места, доработал. Если надо — повторил.
6. Метрики выросли, профит :)

Перед рисованием может быть еще поиск проблемы, отрисовка CJM и прочие высокоуровневых артефактов, но я сейчас не хочу настолько вдаваться.

Можно ли обходиться без эвристик, не тестировать, и сдавать в разработку вещи в духе «я так вижу, PM тоже говорит, что ему нравится»?

А потом просто смотреть на метрики, смотреть на видеозаписи действий пользователей в вебвизоре или inspectlet?

Конечно можно, все можно :)

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

На сегодня все, спасибо!

Что будет дальше?

В будущих статьях мы поговорим подробнее про эвристики, тесты, и метрики.

В следующей статье:

1) Что дают эвристики

2) Какие бывают эвристики

3) Ограничения эвристик

📝 А пока — пишите мне!

Буду рад, если вы напишете мне в личку, и расскажете про свой опыт работы с эвристиками, аналитикой, придумывания и сбора метрик. А заодно — интересна критика статьи, канала, и пожелания на будущее :)

@Serebrennikov_i

И не забывайте подписываться на мой канал о UX!