В 2005 году, я только начал как следует работать дизайнером интерфейсов. Один клиент доверил мне свой новый проект — фотохостинг, который должен был подавить Фликр (угадайте, с каким результатом).
Конечно, я тогда с энтузиазмом взялся за работу, создал (не слишком вдумчиво) кое-какие макеты, и когда дело дошло ко второй презентации, в ответ на замечание клиента касательно внешнего вида текстовых буллетов, выдал абсурдный аргумент, приписав его гуру типографики. Соврал, что вычитал об этом в его книге, о чем сейчас жалею.
Клиент же не поленился обратиться к тому человеку напрямую и спросил — правда ли он такое говорил. Конечно, тот впервые услушал подобную ерунду, о чем не замедлил сообщить клиенту.
После тяжелого разговора, мы разошлись, я вернул предоплату и с тех пор принял для себя простые аксиомы:
- Профессиональный опыт, интуиция, ощущения и «знания» могут оказаться полной херней в любой момент времени.
- Важно проверять гипотезы и полагаться только на результаты грамотно проведённых экспериментов.
- Выдавать свои непроверенные аргументы как истину — зло.
Тогда мне было плохо от этого понимания, однако, в конечном счете, благодарен за урок.
Этот случай вынудил вплотную заняться инвентаризацией и проверкой собственных знаний о том, как создать элегантный и эффективный цифровой интерфейс.
Мысли ниже справедливы для любого интерфейса на экране — мобильных приложений, сайтов, десктопных программ, умных часов и даже банкоматов.
Кое-какие из них актуальны для любых интерфейсов вообще, не только цифровых.
Для начала — несколько аксиом и максим, принятых мной и актуальных для любых обстоятельств и контекстов:
Любое убеждение — гипотеза
Пока идея не подтверждена экспериментальным путём в боевых условиях — это не факт, даже если об этом говорит кто-то авторитетный. Критичность решает.
Полагаться на гипотезы опасно
Это как игра в русскую рулетку. Порой можно сорвать куш, а можно и отхватить люлей. Вероятность второго зависит от степени абсурдности идеи.
Нельзя посчитать = нельзя проверить
Если непонятно, как измерить эффект при проверке гипотезы, значит её нельзя проверить, а значит см. пункт выше. Не говоря уже о случаях, когда не понятно, какой эффект измерять — тогда и гипотезы-то нет.
Интуиция ненадёжна
Даже ваша и моя. Даже десятков коллег в офисе. Помедитируйте на первую максиму, она не раз выручала меня, когда хотелось внедрить в проект что-то радикальное. И слава богу — это не раз уберегало меня от тяжелых последствий.
Любая информация субьективна, пока не проверена на практике.
Измеримые факты уделывают эмоции
Здравомыслящий дизайнер полагается на числа, а не ощущения, если он, конечно, не графический оформитель, а дизайнер здорового человека. Порой числа показывают несостоятельность гипотезы и в этот моент многие уходят в отрицание вроде «это не мой интерфейс плохой, просто программисты налажали». Думаю, это знакомо каждому опытному дизайнеру интерфейсов.
Контекст — король
Слишком многое зависит от обстоятельств. Проверять гипотезы следует в привязке с конкретным проектом, который существует в конкретных обстоятельствах и реализован конкретными людьми.
В других случаях могут быть совершенно обратные результаты.
Стараюсь быть осторожнее с гипотезами, проверенными на других проектах, уверенность в их универсальности опасна.
Начать проверку не сложно
Гипотеза — это любое ваше предположение, которые потенциально может принести положительный или отрицательный эффект.
Проверять пессимистичные идеи формата «Если не сделаем это, тогда будет плохо» можно, однако не слишком продуктивно, потому ниже расскажу о том, как мы проверяем оптимистивные.
1. Инициируем и формализируем
У любой гипотезы есть хозяин — тот, кто её предложил. Он должен получить лавры, или по шапке. Даже если гипотезу выдвинули в процессе командного брейншторма — всегда есть тот один, который предложил идею.
По возможности стараемся сразу записать новую гипотезу в учетную таблицу. Если останется на словах — значит идеи не существует, про неё забудут или потеряют результаты.
Может показаться, что это бюрократия, однако иначе каждый сможет понять гипотезу как ему вздумается.
- В чем состоит идея?
Вывел для себя простую формулу: Если [предложение], тогда [результат]. Например: если сократить количество полей ввода данных в чекауте, тогда увеличится конверсия в покупки. - Зачем нам её проверять?
В чем потенциальные выгоды для бизнеса и пользователя. В случае с чекаутом всё просто — для бизнеса больше денег, а для пользователя меньше мороки. - Как узнать, подтверждена ли гипотеза?
KPI. Если нет четких измеримых показателей, на которые реализация идеи повлияет в ту или иную сторону — нет гипотезы.
Возвращаясь к примеру с чекаутом — ключевым показаталем эффективности была конверсия в покупки. - Какой способ быстро проверить её?
Всегда можно определить минимально необходимое решение. А после — сократить и его. Главная задача — проверить гипотезу как можно скорее, не углублясь в дебри разработки. - Существуют готовые решения?
Ресурс разработчиков дорог. Всегда следует поискать готовые решения, которые помогут быстро проверить гипотезу: сервисы, движки, скрипты и прочее. - Как будем внедрять?
Следует относится к проверке гипотез как к проекту. У любого проекта есть план действий, обьем работы, этапы реализации и требуемые ресурсы. В общем «что делаем, в каком порядке и что для этого нужно». - Кто уже делал?
Кейсы, конкуренты, аналоги, лучшие практики.
Важно: в случае, если гипотеза проверяется в большой компании, крайне важно не убить своим продуктовым решением чьи-то показатели.
2. Определяем приоритеты
В идеальном мире с радугами и единорогами у каждого из нас бесконечное время и за плечами безграничные ресурсы.
В суровом реальном мире это не так. Тут как у Алисы в Стране Чудес: если просто бежать изо всех сил —останешься на месте. А чтобы двигаться вперед нужно бежать вдвое быстрее.
В общем, после определения списка гипотез, следует расставить приоритеты, исходя из того, какая из них потенциально принесет больше счастья и добра (перечеркнуто) денег вам и проекту.
Тема обширная, заслуживающая отдельной статьи. Постараюсь здесь покороче описать принцип, которым руководствуюсь:
Лучшая гипотеза — та, которая затрагивает как можно больше пользователей и потенциально принесет больше денег, при этом проверка не займет много времени.
Звучит просто, однако что делать, если все гипотезы очень вкусно выглядят? В таких случаях я пользуюсь такой матрицей, которую устроил себе с помощью сервиса бесконечных онлайн-досок RealtimeBoard:
- По горизонтальной оси располагаю гипотезы по уровню их сложности (скорости) реализации разработчиками
- По вертикальной — потенциальную выгоду для проекта.
- Зеленый сектор следует немедленно брать в работу.
- Гипотезы из желтого ставлю в долгосрочный план.
- На серый следует тратить время только если нет гипотез из зеленого и желтого.
- А идеи из красной области просто удаляю, чтобы не отвлекали.
Выглядит просто, работает магически, прочищает мозг, хотя и не rocket science, конечно.
3. Проектируем и внедряем
Вначале думал расписать этот раздел очень подробно, однако после решил не углубляться, поскольку процесс создания нового интерфейса и его внедрения в проект в разных командах проходит очень различно.
- Ищем лучшее интерфейсное решение в заданных условиях.
Брейнштормы, скетчи, быстрые прототипы, вот это всё. Ничего такого, о чём нельзя прочитать в «Психбольнице в руках пациентов» Алана Купера. - Опредялем все кейсы.
Часто дизайнеры останавливаются на концептах, которые красиво выглядят на макетах, но в реальных боевых условиях всё идет по пизде, простите за французский. Следует предусмотреть все 95% случаев, которые могут произойти во время использования интерфейса, и продумать соответствующие решения. В таких случаях наш лучший друг — тестировщик (QC или AQC), они всегда озабочены тем, что мы не все предусмотрели.
Про дизайн с реальными данными не сказал в интернетах только ленивый или некомпетентный дизайнер. - Описываем спецификацию разработчикам и аналитикам.
Да, это следует делать дизайнеру нового интерфейса, если он здорового человека, конечно. Нет, не бизнес-аналитику. Не техническому писателю. Не менеджеру проекта. Не копирайтеру. Не уборщице.
Да, это менее интересно, чем графический редактор или среда прототипирования, однако глубоко убежден, только дизайнер сможет описать свою идею максимально подробно и по человечески. - Результат работы дизайнера — не макеты, а запущенное решение.
Именно по нему будут судить о качестве работы.
Если дизайнер пропустил сырое и непроработанное решние на продакшн — сам виноват, нефиг перекладывать ответственность.
4. Собираем и анализируем данные
В качестве платформы для проверки онлайн-гипотез мы используем Google Analytics.
Не смотря на страшный интерфейс и некоторые другие недостатки — данные он собирает хорошо. А учитывая, что вся веб-аналитика у нас настроена именно на нём, то другие варианты даже не рассматриваем.
Надеюсь только, в один прекрасный день мы перейдём на корпоративную 360 версию, она повеселее для анализа больших обьемов данных.
В 95% случаев проверяем гипотезы с помощью A/B или мультивариантного тестирования, где исходный интерфейс соревнуется с гипотетически более хорошим.
В качестве KPI, в нашем случае, чаще всего, выступает валовая доходность + конверсия. Порой бывает что-то более специфическое, но редко.
О сегментации
Тестировать гипотезы лучше на небольшом сегменте пользователей, так потенциальный негатив затронет только небольшую часть людей и вероятность облажаться по крупному радикально снижается.
Например, мы часто устраиваем эксперименты только для посетителей из определенных стран, или вовсе только на одной локализации сайта. Порой проверяем эксперимент только для специально созданного сегмента посетителей «Потенциальные покупатели», чтобы не засорять результаты мусорным трафиком.
О семплировании
Пользуясь Аналитикой Гугла следует всегда быть настороже — если у вас много статистики, сервис начинает семплировать данные, что может исказить вам результаты.
Если коротко, Google берёт, скажем, 1% от всех сессий, подбивает точную статистику и экстраполирует результаты на оставшиеся 99%.
В общем, не круто. Насколько понимаю, корпоративная версия за вагоны денег лишена этого недостатка.
Что дальше?
Когда эксперимент успешно завершен, есть несколько дальнейших путей развития событий:
- Гипотеза подтверждена.
Поднимем бокалы! Однако не расслабляемся: следует подумать, как усилить положительный эффект в будущем. Так появляется волшебная Идея 2.0. - Гипотеза опровергнута.
Сигнал задуматься о причинах. Исправляем их и запускаем новый эксперимент. Если всё совсем плохо — забываем как страшный сон и радуемся, что это был лишь эксперимент. - Нихрена не понятно.
Такое бывает, если влияние новинки не так существенно, как ожидалось, однако и хуже не стало. В такие моменты остается надеятся, что мы не потратили кучу денег на проведение эксперимента. В любом случае, ничего не мешает оставить новое решение в качестве нового основного.
Выводы
- Полагаться на интуицию — опасно.
- Важно правильно инициировать гипотезы и формализировать их.
- Сосредоточиться следует на тех идеях, которые легко проверить и потенциальный эффект от которых максимален.
- Любая гипотеза актуальна только в конкретном контексте. В другом проекте, например, полученные ранее данные могут быть не актуальны.
- Проведённый эксперимент — это не конец, а новое начало бесконечного Кайдзен-процесса улучшений.
Вышеописанное может показаться сложным и страшным, если вы ещё не ставили экспериментов. Надеюсь, вас это не отпугнёт: ставить эксперименты — круто и не слишком сложно, когда обкатаешь процесс как следует. Надеюсь, эта вводная статья поможет.
Мало что сравнится по уровню удовольствия с кайфом в тот момент, когда эксперимент завершается с разгромным счётом в пользу нового интерфейсного решения.
Если же текст выше показался вам само собой разумеющимся, продиктованым здравым смыслом — значит вы молодец.
Однако никогда не лишне повторить пройденное :)
