Самый частый старт проекта по вёрстке выглядит так. Заказчик скидывает верстальщику картинку макета и пишет: «Сделай как тут». И обе стороны искренне думают, что этого достаточно — вот же дизайн, что ещё нужно. А потом начинается. «А почему на телефоне всё разъехалось?» — «Вы не говорили, что нужен мобильный». «А почему в этом браузере кнопка не работает?» — «Я проверял в своём». «А я думал, код будет чистый под программиста» — «Вы это не указывали». И каждый по-своему прав, потому что договаривались-то только о картинке.
Корень почти всех таких конфликтов один: макет показывает, как сайт выглядит, но молчит о том, как он себя ведёт и в каких условиях работает. Всё «невидимое» — устройства, браузеры, поведение кнопок, качество кода, формат сдачи — остаётся на додумывание, и верстальщик додумывает по-своему. Техническое задание как раз закрывает эту дыру. Это не бюрократия ради бюрократии, а две страницы, которые превращают «я думал, будет иначе» в чёткую договорённость. Разберём, что обязательно в нём прописать, дадим готовый шаблон по пунктам и покажем, как он экономит деньги обеим сторонам.
Эта статья — опорная в разделе про вёрстку. Смежные темы: как передать макет, кроссбраузерность, как принять работу.
Что вы узнаете из статьи
- Почему макета недостаточно и что он не показывает
- Готовый шаблон ТЗ на вёрстку из шести блоков
- Как описать требования, не разбираясь в технике
- Почему чёткое задание снижает цену и убирает переделки
- Что делать, если составить ТЗ самому пока сложно
Почему макета мало: ТЗ про «невидимое»
Макет — это фотография сайта в одном застывшем состоянии, на одном экране. Он отвечает на вопрос «как это выглядит», но не отвечает на десяток других вопросов, без которых вёрстку не сделать однозначно. Как сайт перестраивается на телефоне? Что происходит, когда наводишь на кнопку или нажимаешь её? В каких браузерах он должен работать? Что показывать, если форма заполнена с ошибкой? В каком виде заказчик получит результат? Картинка про это молчит.
И вот в этом молчании рождаются все будущие споры. Где макет молчит — там верстальщик принимает решение сам, исходя из своего понимания «как обычно». А «как обычно» у заказчика в голове и у верстальщика в практике — это часто разные вещи. ТЗ нужно ровно для того, чтобы проговорить невидимое: зафиксировать то, чего нет на картинке, но что критично для результата.
Половина этого начинается ещё раньше — с того, как заказчик сумел передать макет из Figma: живой файл с доступом, порядок в слоях, показанные состояния. Хороший исходник и хорошее ТЗ работают в паре: первый показывает, как выглядит, второе описывает, как ведёт себя и в каких условиях. Вместе они почти не оставляют места для додумывания.
Готовый шаблон ТЗ: шесть блоков
Не нужно писать многостраничный документ с печатями. Хорошее ТЗ на вёрстку умещается на пару страниц и состоит из шести понятных блоков. Пройдитесь по ним и заполните своими словами.
1. Макет и доступ. Ссылка на файл дизайна с открытым доступом (не картинки, а сам файл). Если есть отдельные версии под разные экраны — перечислите. Тут же — где взять шрифты, иконки, картинки, если они не в макете.
2. Устройства и тип вёрстки. На каких экранах сайт должен выглядеть правильно: только десктоп, или десктоп плюс мобильный, или десктоп, планшет и мобильный. Нужен ли полноценный адаптив. Это один из главных пунктов, потому что именно его чаще всего «забывают» и потом из-за него спорят.
3. Браузеры. В каких браузерах проверять: популярные на компьютере, браузер на айфоне, телефоны на Android. Не «во всех» абстрактно, а конкретным списком. Почему это критично и где сайт чаще ломается — в материале про кроссбраузерная вёрстка.
4. Требования к коду. Нужна ли семантическая разметка, важна ли скорость загрузки, будет ли код потом подхватывать программист. Если сайт продвигается в поиске — укажите, что код должен быть пригоден для SEO. Это превращает вёрстку из косметики в код, который работает на результат.
5. Интерактив и состояния. Что происходит при наведении и клике, как ведут себя формы, что показывать при ошибке, как открывается меню, есть ли анимации. Всё «движение» сайта, которого нет на статичной картинке.
6. Сдача и сроки. В каком виде вы получите результат (готовые файлы, доступ к репозиторию), к какому сроку, как проходит приёмка. Тут же полезно договориться, что исправление недочётов входит в работу.
Как описать всё это без технических знаний
Главная тревога заказчика — «я же не программист, как я напишу техническое задание». Хорошая новость: глубоких знаний не нужно. Вы описываете не то, как верстальщик должен это сделать, а то, что должно получиться и в каких условиях работать. Способ — забота исполнителя, ваше дело — результат.
Это как заказать ремонт. Вам не нужно знать, какой раствор замешивать, — вам нужно сказать «хочу, чтобы в ванной была плитка, тёплый пол и чтобы ничего не протекало». Так же и с вёрсткой: «хочу, чтобы сайт нормально открывался на телефоне, работал в Safari на айфоне, кнопка заявки при наведении подсвечивалась, а форма при ошибке показывала понятное сообщение». Это нормальный, понятный язык требований, и верстальщику его достаточно.
Если идти от шаблона из шести блоков и просто заполнять каждый своими словами, ТЗ получится даже без всякого опыта. А на приёмке этот же документ станет вашим чек-листом: вы пройдётесь по пунктам и проверите, что всё сделано как договаривались, — как раз так, как описано в материале про то, как проверить качество вёрстки. Задание на входе и приёмка на выходе по одному списку — это замкнутый круг защиты от сюрпризов.
Почему ТЗ экономит деньги обеим сторонам
Может показаться, что ТЗ — это лишняя возня в начале, проще сразу к делу. Но именно эта возня экономит больше всего. И заказчику, и исполнителю.
Заказчику ТЗ снижает цену двумя путями. Первый: когда верстальщик видит чёткое задание, он точно оценивает объём и называет честную цену — без надбавки за неизвестность. Размытое «сделай как на картинке» исполнитель закладывает с запасом на риск, потому что не знает, что вы потом потребуете. Второй: ТЗ убирает почву для переделок. Когда требования зафиксированы, на приёмке нечего домысливать и не возникает споров «я думал, будет иначе». А переделка — это всегда дороже и дольше, чем сделать сразу правильно.
Исполнителю ТЗ тоже выгодно, и это важно понимать обеим сторонам. Чёткое задание защищает верстальщика от заказчика, который сначала молчал, а на приёмке вдруг захотел мобильную версию и десять браузеров «бесплатно, это же само собой». Когда объём зафиксирован, понятно, что входит в работу, а что — дополнительный заказ. Поэтому хорошее ТЗ — это не оружие одной стороны против другой, а общая страховка от недопонимания. Обе стороны точно знают, о чём договорились, и работают спокойно.
Получается простая арифметика: пара страниц требований на входе экономит десятки тысяч на переделках и недели нервотрёпки на согласованиях. Это, пожалуй, самое выгодное вложение времени во всём проекте.
Как платформа помогает с ТЗ и заказом
На Где.Эксперт обсуждение требований — обычная часть старта работы. Хороший верстальщик сам задаст правильные вопросы про устройства, браузеры, код и состояния и поможет оформить задание, даже если вы пришли с одной картинкой. Это снимает страх «не смогу составить ТЗ сам».
Зафиксированные до старта требования становятся основой для спокойной приёмки. Оплата идёт по факту выполнения: вы проверяете работу по тому же списку, по которому договаривались, и деньги уходят только после приёмки. А отзывы и история заказов помогают выбрать исполнителя, который привык работать по ТЗ и сдавать без переделок, — это видно по тому, как прошлые клиенты оценили чёткость и результат.
Часто задаваемые вопросы
Что обязательно прописать в ТЗ на вёрстку?
Шесть вещей: макет и доступ, устройства и тип вёрстки, список браузеров, требования к коду, интерактив и состояния, формат сдачи и сроки. Эти пункты закрывают почти все источники споров.
Зачем нужно ТЗ, если есть макет?
Макет показывает вид, но молчит о поведении и условиях: браузеры, адаптив, состояния кнопок, качество кода, формат сдачи. ТЗ описывает это «невидимое». Без него верстальщик додумывает сам.
Нужно ли разбираться в технике, чтобы написать ТЗ?
Нет. Вы описываете результат и условия понятными словами, а не способ реализации. Технические детали — забота верстальщика. Готовый шаблон по пунктам помогает ничего не упустить.
Как ТЗ экономит деньги?
Верстальщик точно оценивает объём и не закладывает надбавку за неизвестность. И убирается почва для переделок: на приёмке нечего домысливать. Две страницы на входе экономят десятки тысяч на исправлениях.
Что делать, если не получается составить ТЗ самому?
Идти от готового шаблона по пунктам или обсудить задачу с верстальщиком — хороший специалист сам задаст правильные вопросы. Главное — не отдавать вёрстку с одним «сделай как на картинке».
Заключение
Макет показывает, как сайт выглядит, но молчит о том, как он себя ведёт и в каких условиях работает, — и именно в этом молчании рождаются все переделки и споры. Техническое задание закрывает дыру: фиксирует невидимое, чего нет на картинке, но что критично для результата. Это не бюрократия, а пара страниц, превращающих «я думал, будет иначе» в чёткую договорённость.
Хорошее ТЗ умещается в шесть блоков: макет и доступ, устройства и тип вёрстки, браузеры, требования к коду, интерактив и состояния, сдача и сроки. Описать всё это можно обычными словами, без технических знаний, — вы говорите, что должно получиться, а как сделать, решит верстальщик. И выгода взаимна: заказчику ТЗ снижает цену и убирает переделки, исполнителю — защищает от внезапных бесплатных «доработок». Пара страниц на входе — самое выгодное вложение времени во всём проекте.
Найдите верстальщика на Где.Эксперт — зафиксируйте требования до старта и платите по факту выполнения.