От цели до юзабилити-тестов: руководство по проектированию сайта27.12.2016 16:52

Почти четыре года назад мы написали одну из самых популярных статей в рунете про проектирование больших проектов. Только на «Хабрахабре» её прочитали более 170 тысяч человек, а вообще она публиковалась в самых разных изданиях мира.

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

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

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

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

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

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

Посмотрите на любую ИТ-компанию, применяющую Agile, и, в частности, Scrum. Кто из них применяет классический Scrum по всем правилам? Я думаю, почти никто. У всех подход оптимизирован под реалии компании. У нас, кстати, тоже не классический Scrum — есть элементы XP, а несколько проектов идут по Kanban. Проектирование не противоречит Agile, давайте отделять мух от котлет.

Подавляющее большинство больших проектов делаются по Agile, и это чуть ли не единственный путь к успеху. Если брать теорию, то нужно садиться и делать все одновременно. На практике, если мы начнем все одновременно, включая проектирование и программирование, то многое придется переделывать. Более эффективное решение — спроектировать основу (этап аналитики, обычно одна-две недели), чтобы увидеть весь проект, а потом садиться проектировать первые интерфейсы, пока программисты будут продумывать архитектуру, выбирать технологии, писать ядро системы.

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

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

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

В таких случаях часто получается первые 90% проекта и вторые 90% проекта. Любое изменение в логике влечет за собой правки дизайна, верстки и программирования, а после это все тестируется и опять меняется и дорабатывается. Знакомая картина? Я думаю, большая часть читателей её видела.

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

Глобально существует два подхода к проектированию:

• Mobile first — когда мы начинаем проектировать с версии под мобильные устройства, а потом полнофункциональную версию.
• Desktop first — когда мы начинаем проектировать полнофункциональную версию, а после делаем упрощенные для мобильных устройств.

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

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

Исходные требования

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

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

• Цель и основная идея. У любого начинания должна быть цель и критерии успеха. У инвесторов есть очень классный прием — они просят сформировать идею проекта в одном предложении. Если стартапер может это сделать, с ним говорят дальше, если не может — идея слишком сырая, и её нужно дорабатывать.
• Целевая аудитория. Любой предприниматель или менеджер должен знать, кто именно будет пользоваться проектом. Определение: «Все, от 18 до 60 лет» — нам точно не подходит. Портрет ЦА должен быть довольно четким, от этого зависит, что именно будет спроектировано. Нужно понимать, кто будет пользоваться, кто платить, кто важен для продвижения проекта и так далее. В идеале подкрепить догадки исследованиями.
• Рынок. У любого продукта есть свой рынок. Это может быть рынок, ограниченный географией отдельной страны, языком, тематикой и так далее. От этого также зависит будущее проекта. Сегментаций при этом может быть несколько, например страна и тематическая ниша в этой стране. В идеале надо узнать не только границы рынка, но и его особенности и правила, если такие имеются. Многое зависит от культуры: например, в России и Украине пользователи не привыкли платить за какие-то услуги в интернете, чего нельзя сказать о США и других развитых странах. То есть при одной и той же идее и размере аудитории мы можем получить совершенно разные особенности проекта и размер конечной прибыли от него.
• Конкуренты. Их нужно знать намного глубже, чем просто название, и вообще наличие их на рынке. Чем они дышат, какие у них проблемы, какие планы. То есть нужен человек с рынка, который его знает досконально. Это очень сильно поможет спроектировать действительно сильное решение. Часто бывают прямые и косвенные конкуренты — знать нужно всех. Я очень люблю проекты, которые задумываются в профильных компаниях для своих же рынков. Некая оцифровка реального бизнеса. Такие проекты очень часто становятся очень успешными, потому что: а) они знают рынок; б) у них достаточно ресурсов; в) нишевых проектов в интернете до сих пор очень мало.
• Монетизация. Большая проблема владельцев продукта в том, что у них есть классная идея, но нет понимания, как этим зарабатывать. Это же и одна из основных причин смерти стартапов. Вариант «подумаем об этом позже» абсолютно не подходит. Это то, с чего нужно начинать думать. Реже бывают случаи, когда проект создается не для заработка, а для продажи большой компании, и инструменты монетизации там априори не нужны. Но это один случай из ста. Да и продаться, будучи прибыльными, все равно намного легче. При этом новые проекты почти всегда стартуют без инструментов монетизации, их дорабатывают потом, но планировать монетизацию нужно сразу.
• Слабые и сильные стороны. Очень часто знание рынка и конкурентов является настолько сильным преимуществом, что его хватает на создание проекта. Сильные и слабые стороны обычно рождаются из таких знаний либо из прошлых наработок компании или конкретного человека.
• Сроки. Это то, на что стоит обратить особое внимание. Если идея инновационная и делается что-то новое, чего нет нигде в мире или на конкретном рынке — сроки будут критическими, нужно сделать максимально быстро, чтобы занять нишу. Если делаем что-то стандартное, как, к примеру, интернет-магазин, то это делается для реального бизнеса, у которого есть четкое планирование. В любом случае, даже несмотря на то, что мы будем делать проект по Agile и сроки у нас размытые, нам нужно узнать временные рамки и контрольные точки.

Цели проекта

Цели проекта «Маркетплейс»

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

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

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

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

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

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

Целевая аудитория

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

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

У каждого из них есть свои параметры, по которым мы можем их группировать. Это важно сделать, чтобы спроектировать полезный сайт для основных групп ЦА, который будет решать задачи каждой из них. В больших проектах таких групп обычно до десяти, и они должны отражать цели для 98% пользователей будущего сайта. Одна из групп при этом будет основной — в неё войдет самый большой процент пользователей будущего проекта, и на неё следует обратить особое внимание.

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

Далее для каждой из этих групп нужно составить описание, некий портрет. Тут уже сложнее. Хорошо, если команда проекта досконально знает рынок и может довольно точно описать ЦА. Но это редкость. Я бы рекомендовал составить список вопросов, важных для проекта, и пойти с ним общаться к представителям разных групп.

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

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

Социально-демографические характеристики: пол, возраст, образование, уровень дохода, род занятий, семья, дети и так далее. Это базовая информация, от неё мы будем отталкиваться. Поведение (потребности, ожидания и так далее) человека с доходом в $300 будет явно отличаться от поведения человека с доходом в $30 тысяч. То есть в рамках одной группы параметров могут быть очень разные люди, и сделать проект одинаково интересным всем просто невозможно. Для этого мы и должны выделить основные группы ЦА, а после оптимизировать сайт под них.

Психографические характеристики: стиль жизни, особенности личности, черты характера, жизненная позиция, система ценностей и так далее. Это менее очевидные, но даже более важные особенности будущей ЦА проекта. Система ценностей студентов будет явно отличаться от системы ценностей политиков или бизнесменов. Это кажется очевидным, однако никто точно не сможет сказать, чем именно отличается та или иная целевая группа, поэтому вопрос нужно исследовать и вникать в него.

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

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

Пять-семь лет назад была мода на копирование Facebook. Так вот все те, кто его копировал, вообще не думали про поведение пользователей. Все воспринимали Facebook как сайт с удобными инструментами взаимодействия, а на самом деле люди пользовались и пользуются Facebook совершенно по другим мотивам. Зная хотя бы что-то о проектировании, очень многие компании могли бы не выбрасывать деньги на клоны Facebook, но нет — лавры Марка Цукерберга до сих пор не дают спать некоторым людям.

Географические характеристики: страна, город, район. В новых проектах я часто слышу, что им будут пользоваться «все». На самом деле у каждой страны не только свой язык, но и своя культура. Так что даже в интерет-проектах нам важно понимать, на какие страны мы ориентируемся. Если проект будет связан с офлайном, тогда эта группа приобретет особое значение. Пользователи из США будут явно отличаться от пользователей из Тайланда, причем отличаться почти во всём.

Кстати, если кто-то еще не догадался: на этапе опросов ЦА вопросы в анкетах должны соответствовать четырем группам, описанным выше. Они должны раскрывать каждую из этих групп.

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

Персонажи и Empathy Map

Персонажи проекта «Маркетплейс»

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

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

В описании персонажа должно быть:

• ФИО.
• Фото.
• Возраст.
• Страна и город.
• Род занятий.
• Семейное положение.
• Поведенческие характеристики.

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

Самое важное после портрета — это задачи-проблемы-решения каждого такого пользователя. Именно тут мы генерируем основную часть идей для нашего проекта. Идеи из предыдущего этапа, в котором была описана первая часть ЦА, мы можем добавить в задачи-проблемы-решения, чтобы понимать, как именно эти идеи появились и с чем связаны.

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

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

Карта эмпатий проекта «Маркетплейс»

Суть карты эмпатий в том, чтобы разделить отношение пользователя на четыре блока:

• Думаю и чувствую.
• Говорю и делаю.
• Вижу.
• Слышу.

Затем проанализировать их и сделать выводы в двух плоскостях:

• Проблемы и болевые точки.
• Ценности и достижения.

Этот инструмент пригодится не только в проектировании, но и в маркетинге.

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

Рынок и конкуренты

Сравнение конкурентов проекта «Маркетплейс»

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

На рынке существует три ситуации:

• Рынок падает.
• Рынок стагнирует.
• Рынок растет.

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

Успешные проекты обычно появляются при росте рынка. Есть еще одна ситуация, четвертая, когда проект создает рынок. То есть владелец продукта придумал что-то совершенно новое, чего нет в мире. Эта самый сложный вариант и самый рискованный. Когда рынка нет, проект создается в полном непонимании, вслепую. Именно в такой рыночной ситуации скрываются единороги, проекты на миллиарды.

Чтобы понять, где мы, нужно еще раз посмотреть на цели и вспомнить, какие именно потребности решает проект. У любого рынка есть границы. Опять же, сказать, что наш рынок — весь интернет, потому что у нас интернет-проект, это в корне неправильно: у рынка должны быть более четкие границы. И чем уже рынок, тем понятнее, что именно нужно спроектировать.

Мы обычно описываем рынок по трем параметрам:

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

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

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

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

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

Зная рынок, мы можем исследовать конкурентов. Цель — быть лучшими. Особенно это важно, когда мы выходим на уже существующий рынок, на котором есть похожие проекты. И классного дизайна нам будет недостаточно, нам нужно быть на несколько порядков лучше, В идеале надо придумать уникальную «фишку», которая будет отличать нас от конкурентов, а прежде нужно узнать каждую клеточку каждого конкурента.

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

Обычно мы спрашиваем признанных экспертов на рынке, гуглим по ключевым словам, ищем рейтинги, тематические каталоги и так далее. Если наш рынок ограничен географически, очень помогает изучение подобных проектов на западе и в соседних странах. Эти проекты не являются нашими конкурентами, но могут быть источником полезных идей. Например, мы сейчас делаем один государственный сайт. Чтобы изучить опыт подобных организаций, мы посмотрели такие же сайты в соседних странах, а также в США и Великобритании, что позволило почерпнуть много полезных идей.

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

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

SWOT-анализ для проекта «Маркетплейс»

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

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

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

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

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

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

Если посмотреть на современные стартапы, то большинство из них не проводят подобных исследований и основываются на догадках основателей. Именно поэтому самой распространенной причиной смерти стартапов является невостребованность рынком (42%), о чем я писал ранее. То есть все это нам нужно не для красивых картинок, которые можно показать инвестору, а для гарантированного успеха всего начинания.

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

Задачи-Проблемы-Решения

ЗПР для проекта «Маркетплейс»

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

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

Этап ЗПР берет свое начало в персонажах и Empathy Map. К каждому персонажу мы должны создать таблицу с тремя колонками: Задачи-Проблемы-Решения. Вживаясь в роль наших персонажей, мы сможем представить, что именно они хотят и с какими проблемами сталкиваются. Именно по этой причине очень важно качество самих персонажей, чтобы они максимально отвечали реальности.

Сама таблица получится очень большой, ведь у нас будет около восьми-десяти персонажей, и у каждого из них может быть по пять-семь задач и проблем, которые могут повлечь за собой 20−30 идей для будущего проекта. В результате получится таблица с сотней идей. Все их реализовывать будет очень долго и затратно, поэтому тут нужно выбрать и разделить все на этапы. Для первого этапа нужно отобрать самое важное, функциональность MVP. Но как выбрать самое важное? С ответом на этот вопрос нам поможет Empathy Map.

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

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

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

©  vc.ru