Бери и делай: как с нуля создать сайт для любого проекта

В чем суть

О проектировании говорят многие: как пользоваться Axure или Sketch, какие функции должен содержать сайт, как правильно спроектировать страницу товара. Это все, безусловно, очень полезно, но не показывает полную картину происходящего. Чтобы спроектировать большой сайт, нужно потратить сотни часов на исследования, прототипирование и разработку подробного ТЗ. В этой статье я впервые в Рунете покажу все этапы проектирования и результаты по ним, полный динамический прототип (более 150 прототипов) и большое ТЗ (более 200 страниц описания). Все это мы будем делать на примере проектирования аналога крупнейшей в мире Ecommerce площадки Alibaba.com.

Знающие люди сейчас начнут говорить про MVP (минимально работающий продукт) и про вред ТЗ на сотни страниц. На самом деле, проектирование не мешает создавать MVP, а помогает.

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

Сценарии поведения

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

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

Динамический прототип

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

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

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

Контроль качества

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

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

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

Техническое задание

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

Особые требования в ТЗ:

1. Архитектура сайта — прорабатывает архитектор
2. Требования по нагрузкам — прорабатывает архитектор и тимлид
3. Сервера и инфраструктура — прорабатывает системный администратор, архитектор и тимлид
4. Требования по безопасности — прорабатывает специалист по безопасности и тимлид
5. Требования по SEO — прорабатывает интернет-маркетолог
6. Требования к дизайну — прорабатывает дизайнер
7. Требования к верстке — прорабатывает верстальщик
8. Микроразметка — прорабатывает верстальщик
9. UML, диаграммы робастности — прорабатывает проектировщик и программист
10. Разграничение прав доступа — прорабатывает проектировщик

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

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

Пример спроектированного аналога Alibaba.com, все основные страницы и подробное техническое задание можно найти здесь.

Подводя итог

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

Многие проекты до сих пор начинают делать без проектирования. Силами менеджера проекта или дизайнера. Это путь бесконечных переделок и бесполезной траты огромных денег. Я лично запускал несколько проектов. И когда-то пытался делать это без проектирования. После таких экспериментов мне часто вспоминалась хорошая фраза: «Я не настолько богат, чтобы покупать дешевые вещи». Она отлично подходит по смыслу.

Материалы по теме:

Сбербанк хочет создать экосистему наподобие Alibaba

В 21 веке у каждого должен быть электронный кошелек. Мало ли что

Что произойдет с чат-ботами и искусственным интеллектом в ближайшие два года?

Почта России создала конкурента AliExpress

Поговори со мной, бот. Делаем бизнес на разговорной коммерции в России