Записи

web-site

Хотим создать сайт, с чего начать?

Сегодня на почту пришел актуальный, на мой взгляд, вопрос: «Хотим создать сайт, с чего начать?».

А действительно, с чего?

Вопрос создания бизнес-модели, описания ЦА, УТП и прочего уберем за скобки. Это доступно описано в книге Александра Остервальдера и Ива Пенье «Построение бизнес-моделей». Будем считать, что все эти задачи хоть как-нибудь выполнены.

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

1. Время. Раскачиваться им некогда, они и так зарабатывают мало.

2. Деньги.

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

Делать «свою» CMS никто не будет, причина скрыта в пунктах 1-2 (об этом обязательно будет отдельная статья). В «крутую» веб-студию тоже никто не пойдет, по причинам, указанным в пунктах 1-2.

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

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

Модели поведения должны описывать:

1. Цели, к которым необходимо привести пользователя.

2. «Хлебные крошки», ведущие к цели.

3. Пути перемещения пользователя по сайту.

4. Варианты перемещений.

5. Манипуляции пользователя на протяжении пути.

6. Результаты манипуляций.

Далее, этот документ должен стать основой максимально детализированного ТЗ, которое лучше разделить на несколько блоков.

Блок 1: Дизайн

1. Детально опишите главную страницу, страницу продукта, страницу покупки и страницы личного кабинета.

2. Приведите примеры понравившихся сайтов или красивого дизайна.

3. Укажите, какие элементы должны быть кликабельны.

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

Блок 2: Пользовательский интерфейс и триггеры (при наличии пользовательского кабинета и процесса покупки)

1. Укажите, что должно происходить при нажатии на определенные кнопки.

2. Не забудьте о шаблонах писем.

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

Перечитайте и упростите все, что можно.

Сложные системы менее надежны.

Меньше свободы – короче путь к цели.

Простота дешевле.

И главное – минимализм в тренде.

Блок 3: Интерфейс администратора

Если какая либо часть данных должна быть доступна для изменения администратором, не ленитесь это описать. Даже если вы уверены, что CMS, используемая для сайта, точно поддерживает нужную опцию, обязательно отметьте ее в ТЗ. Часто оказывается, что стоковые функции после изменения кода или не работают, или выполняют операции некорректно.

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

В дальнейшем, я обязательно опубликую несколько примеров технических заданий для сайта, а пока вы можете отправлять свои вопросы на почту grigoriev.dmitriy85@gmail.com