Думай и Богатей

Думай И Богатей
11 декабря 2017

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

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

1. В чем суть

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

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

Если работать по Agile и двигаться в сторону MVP, мы можем либо проектировать кусочками, либо спроектировать всю систему, но разбить её на этапы. Важно, чтобы этап проектирования в любом случае был и не пришлось все переделывать много раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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