Студийные истории #6. Хорошим верстальщикам ТЗ не обязательно.

Как я понял на тот момент, да и на сегодняшний тоже, необходимость технического задания для верстальщика обратно пропорциональна его компетентности.

Почему так? Рассмотрим небольшой сайт визитка на 3 макета: главная страница (она же текстовая/информационная), каталог страниц (что бы отобразить вложенность разделов), и какая-то страница с формой обратной связи и картой от Яндекс.Карты. Дизайнер отдал Вам (менеджеру) все три макета в PSD… все как положено.

Вопрос: что объяснять верстальщику?
Увидеть где и какие элементы будут ссылками совершенно не есть проблема — логика у всех работает (должна по крайней мере!!!). Должен ли сайт «тянутся»? Тут тоже все понятно: нормальные дизайнеры, если сайт фиксированной ширины, рисуют фоновые поля. Рассказывать верстальщику как должны меняться ссылки при наведении? А вот и нет! Это задача дизайнера показать все выделения и все варианты отображения. Можно попробовать рассказать о том, что нужно оставлять комментарии в коде, но это и так должно быть понятно: отсутствие комментариев не комильфо. Так же хороший верстальщик сам знает, что названия страниц надо делать h1, и как правильно дальше использовать h2,h3 и т.д. Хороший верстальщик знает, что поисковик читает страницу сверху вниз, ровно так как это написано в html-коде, а не так как это видит пользователь, потому более важные элементы выносятся выше по коду и т.д. О W3C я вообще молчу.

Выводы:
а) чем более компетентный верстальщик, тем менее необходимо ему тех.задание. Достаточно будет пояснительного письма: этот блок должен тянуться туда-то, тут будет то-то и т.д. Это не ТЗ.
б) для некомпетентных верстальщиков тоже не надо писать ТЗ, с ними просто не надо работать. Ищите хотя бы средний уровень.
в) работая со штатным верстальщиком и с фрилансерами, я сделал себе небольшой документ «рекомендации верстальщику«, и раздаю его всем, с кем работаю. Соответственно работу принимаю, учитывая его. В документе собраны истины, которые повторять каждому лень, но хочется как-то донести информацию.

Реальные кейсы роста продаж
и повышения конверсии!

Узнайте как другие увеличивают продажи на 10%, 30%, 50% или даже в 2 раза!

100% без спама!

  • неплохие рекомендации, хотя есть и спорные моменты, в любом случае приятно что я практически на 99% верстаю в таком стиле :)

    • А Вам заказы нужны? :) 
      Если да, то скинье плиз портфолио и прайс мне на контактную почту. Спасибо. 

  • Интересно, а что должно быть указано в ТЗ для верстальщика?

    • В том-то и дело. Если верстальщик хороший, то можно без ТЗ спокойно обойтись. Если верстальщик неопытный/некомпетентный, то надо описывать все: что является ссылками, что и куда тянется, как тянется макет, рамки картинок входят в файл картинки или это верстка, логическую структуру (какой текст каким тегом делать h1,h2, etc). И т.д. В принципе все, что описано в файле «рекомендации верстальщику» можно и нужно описавать в ТЗ, только не общими словами, а конкретно тыкая пальцем в макет.

      Я сделал вывод, что мне проще работать с профи или чуть выше среднего, чем обучать новичков.

      • То есть верстальщик должен сам придумать как должен тянуться сайт?

        • Верстальщик это не придумывает, а видит и принимает решение. Этому способствют две вещи:
          — логическое мышление и вообще неличие мозка у человека
          — дизайнер должен нарисовать два: в простом виде и в растянутом виде — именно для того, что бы верстальщик не придумывал. Если в каких-то местах некие элементы могут присутствовать или отсутствовать, то дизайнер должен показать оба варианта.
          Если что-то особенное получается, то можно черкнуть две строчки верстальщику о том как это должно быть. Но это скорее заметка, чем ТЗ.

          • В таком случае можно и программистам не писать ТЗ, а лишь заметку черкануть, что здесь будет так.

            Вот из таких заметок и состоит ТЗ.

            • По сути, если проекты шаблонные и конвеерные, то да. Но вообще программисты работают не только с интерфейсом, но и сущностями объектов. Там надо описывать поведение сущности, ее состояние и т.д.