Серьезное проектирование серьезных сайтов. Часть 1. Аналитика

*Эта статья была опубликована на площадке для предпринимателей VC.RU от 27 Декабря 2016. Тут публикуется полная её версия.

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

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

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

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

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

Убедил? Думаю, не всех. В комментариях к каждой моей статье всегда находятся люди, которые утверждают, что это необоснованно дорого. Обычно это программисты, которые привыкли писать код, они не думают предпринимательскими масштабами. Представим, что мы решили работать без проектирования. Посадили программиста, он начал что-то делать. Посадили дизайнера, показали ему описание на несколько страниц, сказали «рисуй». Программист думает технически: какой язык выбрать, какую архитектуру заложить, как БД будет устроена. Дизайнер думает творчески: какой стиль выбрать, какие цвета, где какой блок расположить. В итоге у нас будет красивая картинка от дизайнера и правильный код от программиста, но работать на достижение конечной цели это не будет, придется корректировать логику, двигать блоки, добавлять функционал. И в таких случаях часто получается первые 90% проекта и вторые 90% проекта. Любое изменение в логике влечет за собой правки дизайна, верстки и программирования, а после это все тестируется и опять меняется / дорабатывается. Знакомая картина? Я думаю, большая половина читателей этой статьи её видела. Именно проектирование может защитить от бесконечных переделок, то есть это не лишний этап в нагрузку, это тоже самое, как проектирование при строительстве, обследование больного или диагностика неисправностей автомобиля. Другими словами, это — обязательный этап разработки любого большого сайта, и пора к этому привыкать.

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

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

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

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

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

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

2. Целевая аудитория. Любой предприниматель или менеджер должен знать, кто именно будет пользовать проектом. Определение: «Все, от 18 до 60 лет» — нам точно не подходит. Портрет ЦА должен быть довольно четким, от этого зависит, что именно будет спроектировано. Нужно понимать, кто будет пользовать, кто платить, кто важен для продвижения проекта и т.д. В идеале подкрепить догадки исследованиями.

3. Рынок. У любого продукта есть свой рынок. Это может быть рынок ограниченный географией отдельной страны, языком, тематикой и т.д. От этого также зависит будущее проекта. Сегментаций при этом может быть несколько, например, страна и тематическая ниша в этой стране. В идеале надо узнать не только границы рынка, но и его особенности и правила, если такие имеются. Многое зависит от культуры: например, в России и Украине пользователи не привыкли платить за какие-то услуги в Интернете, чего нельзя сказать о США и других развитых странах. То есть при одной и той же идее и размере аудитории, мы можем получить совершенно разные особенности проекта и размер конечной прибыли от него.

4. Конкуренты. Их нужно знать намного глубже, чем просто название, и вообще наличие их на рынке. Чем они дышат, какие у них проблемы, какие планы. То есть нужен человек с рынка, который его знает досконально. Это очень сильно поможет спроектировать действительно сильное решение. Часто бывают прямые и косвенные конкуренты — знать нужно всех. Я очень люблю проекты, которые задумываются в профильных компаниях для своих же рынков. Некая оцифровка реального бизнеса. Такие проекты очень часто становятся очень успешными, потому что: а) они знают рынок; б) они имеют достаточно ресурсов; в) нишевых проектов в Интернете до сих пор очень мало.

5. Монетизация. Большая проблема владельцев продукта в том, что у них есть классная идея, но нет понимания, как с этого зарабатывать. Это же — одна из основных причин смерти стартапов. Вариант «подумаем об этом позже» абсолютно не подходит. Это — то, с чего нужно начинать думать. Реже бывают случаи, когда проект создается не для заработка, а для продажи большой компании, и инструменты монетизации там априори не нужны. Но это 1 случай из 100. Да и продаться, будучи прибыльными, все равно намного легче. При этом почти всегда новые проекты стартуют без инструментов монетизации, их дорабатывают потом, но планировать монетизацию нужно сразу.

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

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

Цели проекта

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

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

С момента написания прошлой статьи мы разработали несколько собственных продуктов и разрабатываем их сейчас. В какой-то момент пришло понимание, что нам недостаточно Project Manager’ов, нам нужны Product Manager’ы. То есть люди, которые могут управлять продуктом, а не только ставить задачи по написанию кода и рисованию картинок. Тоже самое относится и к UX / UI Designer’ам или на русский манер, к проектировщикам. Нужны люди, которые смогут понять бизнес клиента. Я не зря об этом написал в блоке про цели, именно тут начинается работа, и нужны правильные люди, с абсолютно другим складом ума, которые не просто способны осознать, что вообще нужно сделать, но и добиться этого.

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

Кроме самих целей важно выяснить критерии успеха. Некий набор KPI, который покажет нам, добились ли мы целей или нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы понять, где мы, нам нужно еще раз посмотреть на цели и вспомнить, какие именно потребности решает проект. У любого рынка есть границы. Опять же, сказать, что наш рынок — весь интернет, потому что у нас интернет-проект, это в корне неправильно: у рынка должны быть более четкие границы. И чем уже рынок, тем понятнее, что именно нужно спроектировать. Мы обычно описываем рынок по 3-м параметрам: 1. Продукты (потребительские свойства, группы продуктов, заменители, цены, комплект поставки и т.д.) 2. География (страны, города). 3. Время (сезонность, перманентный или временный). С первыми двумя группами более-менее понятно, нужно только вывести критерии для проекта и описать его. Параметр «время» бывает довольно редко и свойственен некоторым типам проектов, которые завязаны на сезонности. Например, сезонность может быть важна в туристических проектах, и от понимания этого феномена в проектировании мы сможем заложить определенные «сезонные» функции, типа сезонных предложений / рассылок / активностей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап ЗПР берет свое начало в персонажах и Empathy Map. К каждому персонажу мы должны создать таблицу с тремя колонками: Задачи-Проблемы-Решения. Вживаясь в роль наших персонажей, мы сможем представить, что именно они хотят и с какими проблемами сталкиваются. Именно по этой причине очень важно качество самих персонажей, чтобы они максимально отвечали реальности. Сама таблица получится у нас очень большой, ведь у нас будет около 8-10 персонажей, и у каждого из них может быть по 5-7 задач и проблем, которые могут повлечь за собой 20-30 идей для будущего проекта. Получится таблица с сотней идей. Все их реализовывать будет очень долго и затратно, поэтому тут нужно выбрать и разделить все на этапы. Для первого этапа нужно отобрать самое важное, функционал MVP. Но как выбрать самое важное? С ответом на этот вопрос нам поможет Empathy Map.

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

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

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

Customer Development

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

На предыдущих этапах мы получили много информации о будущих потребителях и рынках. Мы знаем, чего они хотят, какие у них проблемы и знаем, как их решить. Самое время понять, за что можно брать с нашей ЦА деньги. В этом и есть суть Customer Development — создать настолько большую ценность, за которую готовы будут платить. Это безумно сложный, но и безумно важный этап. Именно тут лежит ответ на вопрос: станет ли стартап бизнесом и как быстро. Сделать популярный проект недостаточно, с него нужно научиться зарабатывать.

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

1. Реклама — показ рекламы пользователям, основные функции для них бесплатные. Например, контекстная реклама в Google.
2. Подписка — платная подписка на премиум функционал или просто доступ. Например, платные приложения в App Store.
3. Freemium — базовый функционал бесплатно, а остальное за деньги. Например, VIP анкета на сайтах знакомств.
4. Платформа — проект выступает платформой, на которой люди (компании) друг другу что-то платят, а проект с этого берет процент. Например, фриланс сайты, которые берут процент от транзакций.
5. Услуги — разовая или постоянная оплата за какие-то услуги. Например, за открытие какой-то информации или возможность выделится.
6. Реальные товары — продажа товаров реального мира, классическая электронная коммерция. Например, любой интернет-магазин.
7. Виртуальные товары — продажа виртуальных товаров. Например, продажа виртуальных товаров в играх.

Многие модели могут пересекаться друг с другом. Например, Facebook и Google 80% своих доходов получают от рекламы, но у них также есть много разных продуктов, которые можно купить по подписке, есть целые платформы и т.д.

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

Для начала проектировщик должен понять, за что люди готовы платить. Для этого лучше всего использовать Empathy Map, которая нам показывает самое ценное для пользователей. Затем нужно продумать, как именно применяется та или иная модель монетизации. И третьим шагом, нужно сделать расчеты по выручке, при этом привязываясь к пользователям. Например, есть мы решили делать платформу и брать 3% ос всех транзакций, то нам нужно добиться оборота хотя бы в 1 млн. долл. в мес., чтобы проект заработал 30 тыс. долл. А еще у нас есть текущие затраты на поддержку такого сайта, команда разработки, которой нужно платить и т.д.

Отдельно стоит задуматься над тем, сколько клиенты будут готовы платить за ту ценность, которую мы предлагаем. Для этого нам нужно понять, сколько сейчас они тратят денег и времени на решение своей потребности или сколько они сэкономят, воспользовавшись наши продуктом. Например, если у нас SaaS сервис, скажем CRM, то мы помогаем клиентам продавать больше, значит, зарабатываем для них больше денег. Как выяснить, насколько больше наши клиенты зарабатывают с нами? Для этого можно: 1. Сделать расчет. 2. Спросить клиентов. 3. Сделать сравнение конкурентов. У каждого из методов есть проблемы: 1. При расчете можно ошибиться, да и данных обычно недостаточно. 2. Клиенты не всегда говорят правду, да и платить хотят как можно меньше. 3. Конкуренты не всегда есть. Но в любом случае мы должны на чем-то основывать в ценообразовании, и это тоже часть правильного проектирования, в которой нам могут помочь профессиональные маркетологи.

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

Mind map

Рис. 7. Mind Map для проекта «Маркетплейс».

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

Основная часть идей у нас в большой таблице ЗПР. Берем колонку решения и по порядку вписываем все идеи в нашу Mind map, параллельно их группируя. Выписывать следует краткие, но понятные формулировки, весь текст в Mind map запихивать не нужно. При этом, если у есть идея какой-то функции, которая имеет разны параметры, мы их должны выписать, как продолжение карты ума. Например, если у нас есть функция «онлайн-оплата» и у неё есть варианты: кредитная карта, PayPal и наличными, то в карте ума так и показываем, ветка «Онлайн-оплата», вложенности — 3 варианта оплаты. Детализировать карту очень важно, местами вплоть до полей во всех формах. Проблема в том, что пока мы работаем с аналитикой, мы хорошо помним, что нужно сделать. Как только мы перейдем на работу с отдельными интерфейсами, все начнет забываться. И если мы не детализируем карту, нам придется проектировать интерфейсы не по карте (как правильно делать), а рыться в прошлых этапах аналитики и вспоминать, что мы придумали. Также, кроме ЗПР, нам нужно внести идеи в нашу карту и из других документов, которые у нас накопились. Абсолютно все идеи должны быть отражены в карте.

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

Мы делаем карты в специальной программе — Xmind, хотя есть много альтернативных программ и онлайн сервисов. Тут не принципиально.

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

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

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

В конце этого этапа у нас будет одна Mind map или несколько на разные части проекта, этапность внедрения фич и приоритеты.

Структура сайта

Рис. 8. Структура сайта для проекта «Маркетплейс».

Сделав карту по функционалу, в теории можно приступать к интерфейсам. Но на первом же интерфейсе возникнет проблема — какую структуру и какое главное меню сделать? В нашей Mind map у нас 7-10 основных разделов, а еще есть множество важных второстепенных. Золотое правило юзабилити («Кошелек Миллера») гласит: в одном блоке не может быть более 5-7 элементов. Это же распространяется и на главное меню. Впрочем, есть и исключение, если все пункты меню несут одинаковую смысловую нагрузку, то можно и больше. Например, сайты СМИ или интернет-магазинов, где меню — это тематические разделы. Внутри каждого пункта меню статьи, просто разной тематике. Бывают и другие исключения, но это редкость.

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

В конце этого этапы у нас будет полная структура сайта и понимание главного и второстепенного меню. Она ляжет в основу первого интерфейса.

Это конец первой части статьи. То, что мы называем аналитической частью проектирования. В следующей статье вы узнаете, как превратить всю эту аналитику в интерфейсы и в частности в динамический прототип.

Вторая часть статьи уже доступна по адресу.

P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook иTwitter