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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала проектировщик должен понять, за что люди готовы платить. Для этого лучше всего использовать Empathy Map, которая нам показывает самое ценное для пользователей. Затем нужно продумать, как именно применяется та или иная модель монетизации. Третьим шагом нужно сделать расчеты по выручке, при этом привязываясь к пользователям.

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

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

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

Для этого можно:

У каждого из методов есть проблемы:

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

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

Основная часть идей у нас в большой таблице ЗПР. Берем колонку «Решения» и по порядку вписываем все идеи в нашу Mind-Map, параллельно их группируя. Выписывать следует краткие, но понятные формулировки, весь текст в Mind-Map запихивать не нужно. При этом, если у есть идея какой-то функции, которая обладает разными параметрами, мы их должны выписать как продолжение карты ума.

Например, если у нас есть функция «онлайн-оплата», и у неё есть варианты: кредитная карта, PayPal и наличными, то в карте ума так и показываем — ветка «Онлайн-оплата», вложенности — три варианта оплаты. Детализировать карту очень важно, местами вплоть до полей во всех формах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы просто не сможем проверить работу на логические ошибки перед тем, как отдать на следующий этап, и будем вынуждены переделывать после. А классика разработки, наверное, — самая известная книга «Совершенный код» нам очень наглядно показывает, как на разных стадиях исправление ошибки будет повышаться от $1 до $10 тысяч.

Мы должны планомерно идти по нашей Mind map и проектировать страницу за страницей. Axure слева может показывать оглавление, там мы называем страницы, делаем вложенности и нумеруем все в формате: «1.0.0», «2.0.0», «2.0.1» и так далее. Это не даст нам запутаться, когда у нас будет несколько десятков страниц. Важно также стараться проектировать целыми разделами, а не выборочно несколько страниц в одной части проекта, а потом несколько страниц в другой.

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

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

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

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

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

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

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

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

Так мы оживляем прототип, и у нас появляется возможность проверить логику его работы и даже показать реальным пользователям для получения первой обратной связи. Пример такого прототипа в динамике мы показывали в статье, в которой описано проектирование аналога Alibaba.com — более 200 уникальных прототипов, и это еще упрощенная версия.

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

Пользователь этого не знает, но технически мы должны спроектировать несколько отдельных версий. Минимум их должно быть три: 320 px, 768 px и 1200 px. Реже делаются еще варианты под 420 px. и 960 px. Чем меньше экран, тем меньше функциональности должно быть в прототипе, то есть для маленьких экранов мы делаем упрощенные варианты. Как альтернатива, можно не проектировать адаптив, а оставить его на этап верстки, на усмотрение верстальщика — это значительно дешевле, но и качество пострадает.

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

В общем, за последние несколько лет мы проектировали почти все, что только можно — тут далеко не полный перечень проектов. Технология проектирования универсальная и довольно близка к стандарту ISO 9241−210 «Human-centered design for interactive systems». Другими словами, это то, чем пользуются во всем мире, и оно отлично работает.

Для иллюстрации слов еще несколько прототипов разных проектов:

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

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

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

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

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

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

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

Смысл в том, что поведение каждого человека можно спрогнозировать хотя бы по основным шагам. Для основных групп пользователей мы должны создать сценарии поведения на сайте, которые покажут его основные шаги. Такие сценарии могут быть как маленькими в рамках одной страницы (Use Case), чтобы протестировать на логические ошибки отдельный кусок работы, так и большими — решение какой-то задачи в рамках сайта и его нескольких страниц. Важно покрыть такими сценариями весь сайт, все основные функции.

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

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

Например, когда он воспользовался нашим продуктом, и он ему понравился или не понравился, он может что-то дальше сделать в зависимости от своего опыта. Построив такие Customer Journey Map, мы сможем подготовиться к любым событиям до и после сайта, сделать пользователя лояльным и встроить его в мультиканальную коммуникацию с проектом. Это мы должны сделать для реальных клиентов, тех, кто платит (будет платить) нам деньги. В принципе, CJM можно подготовить еще в этапе аналитики и учесть идеи до прототипирования, а на этом этапе только перепроверить себя.

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

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

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

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

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

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

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

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

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

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

Структура ТЗ опять же бывает разная. Кроме описания самого интерфейса мы обычно включаем такие блоки:

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

Что если не прорабатывать требования, указанные выше?

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

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

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

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

В статье я показал много примеров из проекта «Маркетплейс», в том числе прототип карточки товара, и дал ссылку на полный динамический прототип. После проектирования любой проект передается на дизайн. И этот проект в дизайне выглядит вот так:

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

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

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

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

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