Четыре этапа разработки сайта, или 4 круга ада?

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

Публикация составлена совместно с командой Годунова.

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

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

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

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

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

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

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

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

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

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

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

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

В зависимости от масштаба и сложности проекта, к стандартной триаде технологий HTML&CSS&JS могут присоединяться различные надстройки в виде сборщиков проектов, препроцессоров, в особых случаях, например в веб-приложениях, обычного JS становится недостаточно и подключаются различные фреймворки например Vue или React, но статья не о технологиях.

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

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

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

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

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

Для самых ленивых: