Что анализировать перед проектированием интерфейса

Давно прошли времена, когда можно было просто начать рисовать сайт или приложение. Даже самому простому интерфейсу требуется хотя бы примитивный этап анализа. У многих дизайнеров есть свои методы анализа, а кто-то оставляет это на аналитиках и сам не лезет в процесс. У меня давно сформировался свой шаблон этого этапа, по которому я делаю предварительную работу для любого Нового проекта. Этот этап не панацея и в ходе работы всплывают не учтённые моменты, но меня ужасает одна мысль сколько их могло бы быть без анализа вообще. Делюсь своим шаблоном и рассчитываю увидеть ваши дополнения в комментах.

Сразу оговорюсь, что это статья не про бизнес или системный анализ, а именно про «дизайн-анализ».

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

Кому лень читать, то вот тут пример презентации моего этапа анализа.

Спроси клиента

Самый логичный пункт — спросить клиента, что вообще уже есть и что конкретно не нравится и главное почему не нравится. Даже если видно сразу, что текущий интерфейс ужасен, обязательно стоит спросить почему клиент затеял редизайн. Могут всплыть не очевидные моменты.

Список моих стандартных вопросов:

• Есть ли у вас логотип / фирменный стиль, которых стоит придерживаться? Иногда стиль и лого есть, но клиент разрешает ими пренебречь. Особо полезная инфа если лого — отстой.
• Что вы хотите изменить в интерфейсе и почему? Определяемся с основным фронтом работ.
• Кого вы считаете своим основным конкурентом? Пригодится на следующих этапах анализа.
• Есть ли у вас выгодное отличие от конкурентов? Пусть редко, но иногда оказывается, что действительно есть.
• Приведите пример интерфейсов, которые вам нравятся и опишите почему. Очень важно именно почему. Может оказаться, что клиенту нравится сайт не в общем, а какая-то часть, например белый фон, который у него вызывает ассоциации с «лёгкостью дизайна».
• Требуется ли вам мобильное приложение / сайт? Задел на развитие проекта.
• Требуется ли версия сайта адаптированная под телефон? Мы то с вами понимаем, что сейчас выходить в интернет без адаптивной вёрстки нет смысла, но и надо рисовать под телефон тоже. Но клиент может иметь другую точку зрения. К тому же адаптировать интерфейс под телефон это уже отдельная работа.
• Можете ли вы предоставить Гостевой доступ к Яндекс.Метрике или Гугл Аналитике для этапа анализа? Главное сразу пояснить, что это именно гостевой доступ и вы никак не можете ничего сломать и не будете никому передавать супер-секретные данные. Клиенты, часто не разбираются в этом и им кажется, что дать доступ к Я.Метрике это как отдать ключи от квартиры, где деньги лежат.

Анализ Я.Метрики / Google Analytics

Я, как истинный патриот и старовер, предпочитаю Я.Метрику. В основном, потому что интерфейс Гугл Аналитики — отстой и там нет Вебвизора.

Что я смотрю в Метрике:

• Конверсию. Если были установлены цели. Если не было, то посоветовать клиенту установить их чтоб набиралась какая-то статистика пока вы делаете остальные этапы.
• Карты. Все карты, включая Аналитику форм.
• Отказы. Общее количество. Сам по себе этот показатель, на мой взгляд, мало о чём говорит и он нужен только для понимания его доли в следующем параметре.
• Отказы по целевым запросам. Вот если много отказов по целевым запросам, то это уже плохо и при редизайне стоит этот параметр снижать. Поясню: «отказ по целевому запросу» значит, что я пришёл на сайт, торгующий вакцинами от Covid19, по запросу «Вакцина от Covid19. Купить недорого», но по какой-то причине не понял, что попал куда нужно и моментально ушёл с сайта. Это явно говорит, что сайт не понятен с первых секунд и клиент теряет покупателей.
• Поисковые запросы. Важно потому что редизайном можно запросто убить кучу текста и заголовков, по которым находят сайт, что не очень хорошо, мягко говоря.
• Статистику по устройствам входа. Пригодится для доказательства клиенту, что ему нужна моб. версия если он вдруг отказался от неё на этапе Опросника. Также даст понимание под какое разрешение её рисовать.
• Пол и возраст основных посетителей. Пригодится на следующем этапе анализа.

Пользовательские сценарии

Один из моих любимых пунктов анализа. Довольно креативный этап в отличает от предыдущих и чертовски полезный. Ставя себя на место пользователя я нахожу массу не очевидных инсайтов, что часто вытекает в новые полезные функции или упрощение существующих.

Для создания сценария я создаю Карточку пользователя.

Вот из чего она состоит:

• ФИО и возраст. На основе данных из предыдущего шага про Метрику.
• Проблема/цель. Описание того зачем юзер открыл наш интерфейс.
• Как пришёл на сайт. Например вбил в Гугле «Купить вакцину от Covid19». Запросы беру не с потолка, а из Метрики.
• Страница входа. От того на какую страницу попал юзер во многом зависит его дальнейший путь. Далеко не всегда юзер попадает на главную страницу.
• Устройство. Берём на основе метрики. От устройства с которого юзер работает с интерфейсом зависит многое в дизайне.
• Желаемое целевое действие. То что уже мы хотим получить от юзера. Например, мы хотим чтобы он заполнил какую-то форму или нажал кнопку.

На основе этой карточки я пишу сценарий.

Из чего состоит сценарий:

• Из целей посетителя, описанных в Карточке
• Из оценки текущего Интерфейса (Редизайн). Смотрим на текущий интерфейс и пытаемся получить от него то, что написано в Карте пользователя. Отмечаем главные затыки.
• Из «насмотренности» удачных реализаций. Дописываем в сценарий какие-то фишки, которые знаем благодаря использованию других сайтов.

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

Конкуренты

Есть два классических ответа на вопрос о конкурентах: «У нас нет конкурентов»; «Мы конкурируем со всеми». Ни то, ни другое, естественно, не является правдой, поэтому надо копать глубже. Для этого вопрос и есть в Опроснике. При анализе конкурентов я выписываю только то, что можно у них почерпнуть. Нет смысла выписывать слабые стороны. Это нам ничего полезного не даст. Я открываю интерфейсы конкурентов и пытаюсь использовать их опираясь на Сценарии пользователей. Ведь если это реально конкурент, то и целевая аудитория у него примерно та же. Мне пару раз клиенты с небольшой иронией в голосе говорили что-то вроде: "А, ну нормально. Просто взял, что увидел у кого-то там и к нам применяешь". Сначала это раздражало, ведь в анализе разбор конкурентов это лишь один шаг из многих и далеко не основной, но впечатление у клиентов может складываться именно «украл, что можно и всё». К счастью это случалось не часто. После этого я специально в презентацию анализа добавил фразу "Можно почерпнуть у конкурентов" сходу говоря, что если надо, то да, именно это я и возьму не стесняясь, что там кто-то это уже делает.

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

Карта интерфейса

Карту интерфейса многие называют по-разному. Можно это назвать структурой, информационной архитектурой, иерархией, картой сайта / приложения или близкими по ходу терминами. Суть одна — описание взаимосвязей страниц / экранов текущего интерфейса. Я это делаю для того чтобы понять текущую логику и на её основе сделать свою более простую, логичную и полезную для юзеров. На выходе получается две карты: «Как есть» и «Как надо».

Примеры стилистики

Примеры стиля будущего интерфейса можно делать в виде скриншотов интерфейсов, стиль которых вы считаете подходящим для текущей задачи. Желательно стараться находить примеры по той же или схожей тематике с темой клиента. Так клиенту будет проще въехать в суть этих картинок. У меня бывали случаи, когда в тематике просто нет достойных примеров и я брал что-то нейтральное. Но надо обязательно сказать клиенту, что это лишь пример стиля (воздушность интерфейса, цветовая схема, мягкость, технологичность и пр.), а не 1 в 1, то что он в итоге получит. И желательно нейтральные примеры находить не на русском языке чтоб клиент автоматически не считывал текст, а получал общее впечатление. На этом этапе обязательно надо добиться от клиента чтобы он именно «ткнул пальцем» в тот пример стиля, который нравится. Это нужно для того чтобы у него в голове чётко сложилось понимание какой стилистики ему ожидать в итоге. Это полезно и для клиента и для дизайнера, у которого уйдёт меньше времени на поиски и упростит этап утверждения готового дизайна.

Что в итоге

По окончанию всех этапов я собираю презентацию в Гугл презентациях и показываю клиенту. Этап анализа он именно должен утвердить, либо если есть какие-то нюансы, то утвердить с комментариями, которые я записываю и либо меняю в презентации если это не долго, либо высылаю письмо со ссылкой на презу и комментариями. Если презентация совершенно мимо, то надо понять, как это произошло и делать новую. Но у меня такого не случалось. А если бы и случилось, то лучше уж на этом этапе чем на более позднем.

Что мы получаем от этапа анализа

• Клиенту стало чуть-чуть понятнее чего ожидать в итоге;
• Дизайнеру стало понятнее, как делать и почему именно так;
• Дизайнеру проще оценить сложность проекта и выдать почти точные сроки;
• Дизайнеру и клиенту проще сдать / принять результат;
• Проект будет более продуманным и это хорошо.