Методологические принципы разработки и тестирования дизайна сайта

Как избежать основных ошибок при обновлении порталов

Современная мода нередко диктует свои условия – как следствие, бывает, что владельцы веб-сайтов начинают реализацию изменений на своих проектах без глубоких изучений ситуации и тестирования. Грубо говоря следуя зову «сайт устарел». Тем не менее6 поспешная разработка и внедрение нового дизайна портала может принести больше вреда, чем пользы. Для того, чтобы избежать подобных ошибок подготовлен следящий методологический материал.

Главное, ответим не вопрос, ради чего реализуются изменения. Основных точек принятие решений может быть две. Или «дизайн устарел, стыдно показывать клиентам». Либо – дизайн не удовлетворяет требуемым КПИ, конверсиям, он не продает, а запутывает и т. п. Во втором случае, решение об изменении визуального стиля проекта может быть принято немедленно. А вот в первом случае, стоит поглубже изучить тематику вопроса. Для начала, провести CustDEV – и на глубинных интервью понять, так ли это. Быть может, ваши посетители и клиенты, как раз видят сайт хорошим и не требующим изменений. А начав трансформацию вы нарушите пару из основных принципов медицины, легко применимых и в цифровой индустрии. «Лучшее – враг хорошего». И «не навреди»!

Окей, мы четко поняли, что необходимо менять дизайн проекта. Начать работу стоит не с прорисовки скетчей будущего дизайна. А с переработки структуры представления и подачи информации. Именно распознавания оптимальных путей потребления контента, предложение максимально эргономичного пути пользователя для достижения своей цели на сайте то, с чего стоит начать конструирования обновленного визуального стиля. Используйте подход Jobs to be Done (JTBD), поймите глубинные цели посетителей на проекте – и, посмотрев их глазами на сайт, предложите тот маршрут, который покажется оптимальным. Идеально при такой работе использовать «тепловые карты» движения посетителей на проекте - и усиливать именно те сценарии, которые дают низкое взаимодействие. А вот насыщенные зоны лучше не трогать - предварительно убедившись, что после взаимодействия с ними не происходит отказ, а именно переход и продолжение взаимодействия с нужной вам страницей.

Идеально будет, если в завершении этого процесса вы проведете несколько больших опросов аудитории: уточняя, действительно ли обновленные механизмы, предлагаемые вами сейчас, кажутся клиентам понятными. Для этого не надо никаких анкет на много страниц и прочего - ставьте всплывающие информеры на сайте в нужных местах и уточняйте, хочется (like) ли посетителю, чтобы этот элемент изменился.

И лишь тогда, когда созданы схемотехнические пути пользователя на новом сайте (это, повторимся, критически важный момент, так как простая перелицовка старой структуры сайта, скорее всего, ничего не даст), когда понят каркас нового дизайна, создана модель и макеты страниц, можно приступать к прорисовке. Для ориентира дизайнерской группе лучше давать комплекс информации, уточняющий вектор творчества - от проектов, которые вам очень нравятся сейчас и кажутся прорывными. До «образа цели» клиента, полученной методом JTBD. Как правило, вы получите 2-3 варианта для предварительной оценки и сможете рабочей группой выбрать один для шлифовки. Тут есть соблазн дать пользователям выбрать оптимальный вариант, или, как минимум, принять их мнение к сведению. И это – ловушка. В большинстве своем, клиенты сайта отлично и достоверно отвечают на краткие вопросы по механике взаимодействия с продуктом. На глубинных интервью во время CustDEV-процесса, опять же, вы можете узнать очень многое. А вот фокус-группы или массовые опросы по новому дизайну почти не работают. Посетители будут массово голосовать за более привычный - и, как следствие, консервативный вариант. Поэтому, как раз выбор итогового дизайна стоит проводить рабочей группой.

Наконец, мы получили тестовый сайт, сверстанный в новом виде, протестировали его, выловили баги. Запускаемся? Нет-нет. Переходим к A/B-тестированию, это важнейшее и минимальное правило для успешного запуска. Распределяйте входящий поток трафика между старой (скажем, 70% на нее) и новой (30%) версиями, это легко организуется на техническом уровне, а затраты на такой подход с лихвой окупаются его эффективностью. Теперь начинаем изучать все параметры взаимодействия с продуктами, прежде всего, анализируя количество отказов, глубину и время. Новый дизайн-проект обязан увеличить метрики взаимодействия с продуктом и снизить негативные моменты (число отказов) – не говоря уже о результирующих КПИ, как-то число покупок и прочее. И не всегда это все получится совместить с первого раза. В большинстве случаев новый дизайн покажет рост какой0то одной метрики при одновременно падении другой. 

Что же делать в этом случае? Продолжаем оптимизацию, процесс идет абсолютно нормально. Теперь нам надо понять общее влияние этих факторов на результирующий КПИ. Скажем, если во главе угла на вашем сайте стоит заполнение формы заявки, стоит оценить, какая из метрик влияет на нее больше или меньше. И если возросшая метрика влияет больше, новой дизайн однозначно подходит. Этот момент можно будет усиливать в последующей шлифовке продукта, а негативный сценарий увести на «второй круг» и решать в новом пользовательском пути. А вот если результирующая метрика на новом дизайне снижается, стоит сразу уйти на переработку дизайна. Значит, была допущена системная ошибка, либо где-то пользовательский путь оказался просто сломан. Как правило, если были пройден все вышеописанные шаги, расстраиваться не стоит – есть 90% вероятность того, что ошибка лежит на стороне тестирования, и просто какой-то из элементов не заработал так, как надо. И это легко исправить.

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

Стас Устенко

14 сентября 2022 года