Pull to refresh

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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


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

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

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


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

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

Конкуренты


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

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

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


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

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


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

Что в итоге


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

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


  • Клиенту стало чуть-чуть понятнее чего ожидать в итоге;
  • Дизайнеру стало понятнее, как делать и почему именно так;
  • Дизайнеру проще оценить сложность проекта и выдать почти точные сроки;
  • Дизайнеру и клиенту проще сдать / принять результат;
  • Проект будет более продуманным и это хорошо.
Tags:дизайн сайтовдизайн приложенийанализ сайтасценарии использования продукта
Hubs: System Analysis and Design Interfaces Design
Total votes 13: ↑12 and ↓1+11
Views6.7K

Popular right now