Как в Uplab разрабатывают сайты. Этап аналитики и проектирования

Многие компании боятся рассказывать о том, как они выстраивают работу над проектами, какие инструменты используют и как ведут диалог с клиентами. Мы другие — максимально открыты перед заказчиками и готовы щедро делиться опытом с коллегами из других агентств. Сегодня решили раскрыть все карты — запускаем цикл статей «Разработка сайтов в Uplab», в котором подробно рассмотрим процесс создания и выпуска продуктов для бизнеса. Первый материал посвящен этапу аналитики и проектирования.

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

Процесс реализации digital-проектов начинается с проведения аналитики и проектирования, без которых невозможно разработать сайт, который будет эффективно решать задачи заказчика. В этапе участвует сразу несколько специалистов агентства: frontend- и backend-разработчики, специалисты по поисковому продвижению, веб- и бизнес-аналитики. Ведущая роль — у системного аналитика.

Системный аналитик выполняет основной объем работ по аналитике и проектированию: совмещает в себе функции UX-исследователя, отчасти продуктового менеджера, бизнес-аналитика, проектировщика интерфейсов и, конечно, UX-дизайнера.

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

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

Необходимый состав работ по аналитике определяется в самом начале и зависит от разных факторов: типа проекта, предметной области, аудитории, специфики деятельности компании и т.п. В процессе аналитики, он может быть дополнен с появлением новых вводных данных.

Изучение предметной области

Как правило, направления деятельности наших заказчиков имеют узкую специализацию. Если с ней системные аналитики Uplab еще не знакомы, они предварительно изучают предметную область, отраслевые отчеты, статьи и новости в медиа, маркетинговые исследования (если есть), тематические форумы, сообщения в группах социальных сетей, материалы от клиента (внутренние документы с планами отдела маркетинга и продвижения продукции, технологические спецификации, каталоги продукции и др.). Выявляют особенности позиционирования компании на рынке, ее положение, репутацию и т.п.

Интервьюирование экспертов в предметной области

Проводится в основном для проектов со сложной, узкоотраслевой специализацией. Цель — разобраться с предметной областью, узнать, какие проблемы отмечают эксперты и какие они видят решения, получить понимание процессов и особенностей предметной области, пояснение характеристик и спецификаций.

Интервьюирование заказчика

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

Интервьюирование технических специалистов

Для проектов, где требуется интеграция с внутренними системами клиента, дополнительно проводятся интервью с техническими специалистами компании заказчика совместно с разработчиками Uplab. Цель — определить технические возможности и ограничения, особенности архитектуры и настроек внутренних систем клиента, требования к обмену данными и их формату.

Интервьюирование сотрудников отдела продаж

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

Анализ конкурентов. Бенчмаркинг

Подразумевает изучение и анализ сайтов, приложений или сервисов конкурентов в отрасли заказчика, отраслях, близких по тематике, или кросс-категориях, а также поиск лучших решений по реализации конкретной функции. Дополнительно могут применяться такие методы, как сравнительный анализ, SWOT-анализ и конкурентный UX-анализ.

Анализ текущего состояния проекта

Не проводится при разработке нового продукта. Используется в случае полного редизайна и переосмысления проекта. Предназначен для определения и изучения положительных и отрицательных решений текущей версии продукта, сбора и анализа веб-статистики, анализа поведения пользователя на сайте. Возможные методы — эвристическая оценка и анализ систем веб-аналитики.

Анализ аудитории

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

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

Работы, которые проводятся по желанию заказчика, либо необходимы для решения поставленной задачив дополнение к основным. Виды этих работ определяются типом проекта, его сложностью, целями и задачами, бюджетом.

Исследование пользователей

Помогает выявить шаблоны, мотивы и логику поведения пользователей (текущих и потенциальных), понять проблематику предметной области и потребностей пользователей, принять обоснованное решение по вопросам проектирования цифрового продукта.

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

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

Анализ обратной связи

Такой анализ возможен, если заказчик производил сбор обратной связи. Аналитик изучает обращения клиентов заказчика, записи телефонных разговоров из колл-центра и сообщения из техподдержки, чтобы проанализировать жалобы, узнать текущие сложности взаимодействия с интерфейсом и понять, как их можно устранить или минимизировать в случае, если их устранение невыгодно бизнесу.

Метод персон

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

User Story

Краткая формулировка намерения описывает что-то, что система должна делать для пользователя. Структура user story: <роль/персонаж>, я <что-то хочу получить>, <с такой-то целью>. Данный метод мы чаще всего используем на сервисных проектах или в тех случаях, когда вводные данные от клиента не дают четкого понимания, какой функционал необходим и зачем.

Эффективнее составлять User Story вместе с клиентом, поскольку совместная работа позволяет находиться в одном информационном поле и максимально точно понять ожидания от продукта. Историям присваивается приоритет по реализации, если необходимо разбить выпуск продукта на релизы.

Как прораб я хочу знать актуальное наличие требуемого товара в магазине и забронировать его, чтобы сэкономить время и не ездить в магазин зря.

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

JTBD

Метод Job to be Done применяется на сервисных проектах, когда сложно определить целевую аудиторию. Выполняется аналитиком в паре с представителем заказчика или команде. Направлен на определение результата, который пытается получить пользователь в текущих условиях.

Структура JTBD: Когда <описание ситуации>, я хочу <мотивация>, чтобы <результат>.

Когда появляются мелкие поломки, я хочу подкопить поломки и вызвать одного мастера, чтобы починить все за один раз, не тратить время и деньги при вызове разных мастеров.

JTBD позволяет понять мотивацию пользователя, выявить направления развития, определить необходимый функционал.

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

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

Если условий много, то сценарии начинают разветвляться (в зависимости от предыдущих действий). Составляется user flow, который помогает в дальнейшем учесть все сценарии и отработать данные.

Карта путей пользователей (Customer Journey Map)

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

Customer Journey Map

После сбора данных и их обработки аналитик приступает к построению информационной архитектуры. Она включает в себя:

01

Инвентаризация контента (важно определить, какие данные должны быть размещены на страницах и как их можно связать друг с другом).

Группировка информации по ожиданиям пользователей.

03

Аудит контента (оценка его полезности и общей эффективности для решения поставленных задач и достижения целей проекта).

02

Разработка таксономии проекта (определение терминологии для классификации и систематизации содержимого ресурса).

04

06

Разработка структуры проекта.

07

Разработка требований к контенту.

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

08

Пример структуры сайта

Дополнительно могут проводиться карточная сортировка и подготовка фактуры для копирайтеров.

Карточная сортировка

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

Подготовка фактуры для копирайтеров

Выполняется в случае, если разработкой контента полностью занимается Uplab.

В зависимости от типа работ системный аналитик готовит следующие отчетные документы:

Анализ конкурентов (Google Документ).

•

Бенчмаркинг (Google Документ).

•

Сбор требований (Google Документ).

•

•

Структура сайта (Изображение или схема в Xmind).

•

Требования к контенту (Google Таблица и/ или Google Документ).

•

Отчет c результатами проведения интервью пользователей или юзабилити-тестирования.

•

CJM (Google Таблица или карта в сервисе MIRO (Realtimeboard)).

•

Пользовательские сценарии (Google Документ или сценарии в сервисе MIRO (Realtimeboard)).

•

User Story (стикеры, Google Документ или истории в сервисе MIRO (Realtimeboard)).

•

User Flow (карта в сервисе MIRO (Realtimeboard) и/ или схема в MS Visio).

•

Отчет веб-аналитики (Google Документ).

Если сотрудничество с заказчиком не предполагает разработку прототипов и последующие стадии разработки, то отдельно составляется функциональное задание, где описывается основной функционал проекта клиента.

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

Прототип — схематическое изображение веб-страниц, приложений или сервиса, которое показывает, из каких блоков и сущностей они состоят. Его также разрабатывает системный аналитик при тесном взаимодействии с frontend- и backend-разработчиками, которые выступают консультантами по техническим вопросам. В процессе создания прототипа могут также принимать участие дизайнеры и копирайтеры.

Прототип позволяет:

Правильно организовать систему навигации на сайте.

•

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

•

Продумать расположение нужных блоков и элементов дизайна.

•

•

Продумать возможности взаимодействия посетителей с сайтом.

•

Сфокусироваться на поставленных целях и задачах.

•

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

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

Динамический (интерактивный) прототип

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

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

Статический прототип

Прототип, выполненный в виде статичных изображений. Элементы на нем некликабельны, содержат комментарии с подсказками, как должен функционировать тот или иной элемент. Могут иметь разную степень детализации: низкую (грубый набросок состава страницы), среднюю и высокую. В основном используются для промо-проектов.

Изначально прототип презентуется команде. Аналитик показывает и рассказывает, что и как сделано, почему были приняты определенные решения, какой ключевой функционал в них заложен, на что стоит обратить внимание. Затем он отправляется на утверждение заказчику.

Завершающей стадией этапа аналитики и проектирования выступает разработка технического задания по проекту, в которой участвуют системный аналитик и технический специалист. Прототип не заменяет и не исключает техническое задание, поскольку не может передать часть взаимодействия пользователей с интерфейсом в силу ограниченности функционала инструментов создания прототипов (мы используем прогрессивные Axure, Sketch и Invision).

Техническое задание составляется по ГОСТ 34 и согласовывается техническим специалистом, дизайнерами и заказчиком.

Аналитики-проектировщики Uplab

После этапа аналитики и проектирования следует дизайн продукта, но об этом подробно поговорим уже в следующей статье.