Хорошая практика:
Материал для вёрстки должен быть в формате PSD (не исключён другой популярный формат, поддерживающий слои). В PSD используемые слои названы соответственно своему содержимому. Шрифты, не входящие в стандартную поставку Windows, используются только для картинок.

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

Пример: в дизайне используется кнопка в виде картинки. Необходимо сделать похожую по аналогии. При дизайне, каким он должен быть, это займёт около 10 минут. При плохом качестве может занять и 2 часа.

Действия:
1. PM: На этапе выяснения требований дать клиенту ознакомиться с документом по требованиям к графическому материалу. (Содержащему примеры требований. Желательно со скриншотами и пояснениями к каждому пункту).

2. PM: Вовлечь клиента в процесс контроля за соблюдением требований при приёмке у сторонних дизайнеров. Объяснить, что качество графического материала, прежде всего, влияет на чувство доверия и отношения его будущих клиентов (пользователей) сайта, а также на качество работы html кодера. (Важно различать качественный дизайн и красивый дизайн: это не тождественные вещи).

1.2 Редизайн
Худший вариант:
Клиент присылает или сообщает ссылки (что ещё хуже) на страницы со свёрстанным дизайном плохого качества (без типовых элементов, содержащим проблемы кроссбраузерности, невалидный код).

Хорошая практика:
Клиент присылает свёрстанный код. HTML кодер, PM и другие участники проверяют его качество и наличие необходимых элементов.

Влияние:
Если факт плохого качества страниц не озвучен перед клиентом или PM’ом, то за все вытекающие баги ответственность перекладывается на HTML кодера. Тем самым увеличивается время незапланированного фиксинга багов.

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

Пример: Чтобы воссоздать локально сайт, где все картинки прописаны в CSS, верстальщику надо отследить путь каждой, прописать его в адресной строке, чтобы скопировать каждую картинку на локальный диск. Количество прописанных в CSS картинок не ограничено.

Действия:
1. PM: На этапе выяснения требования подчеркнуть важность качества входящего материала и последствия плохого: технические (баги, перерасход проектного времени, плохая расширяемость) и негативное влияние на чувство доверия и отношение будущих клиентов (пользователей).

2. PM: Просить клиента прислать свёрстанный код вместо публикации на сайте (если нет FTP доступа). Это позволяет HTML кодеру сразу же работать с кодом «как есть», не занимаясь переподготовкой. Важно отметить, что это ещё и позволяет предотвратить тихое добавление клиентом новых элементов под видом того же плана работ.

3. HTML кодер: Известить PM’а о возможных проблемах, ошибках и качестве материала. Написать, каких элементов не достаёт в новом дизайне. Попросить провести сравнительный анализ нового и старого дизайна (выяснить, что меняется, что добавляется, что убирается и т. д.).

2. Требования к вёрстке (DIV, table, смешанная).
2.1 Вёрстка на дивах
Худший вариант:
Проекты с требованием блочной вёрстки (семантическая вёрстка с использованием DIV) выполняются кодерами, не имеющими необходимого опыта, или используется блочная вёрстка там, где она не обоснована.

Хорошая практика:
Блочную вёрстку стоит применять в тех местах, где это применение обосновано (субъективное мнение), если:
- необходимо соблюдение стандартов;
- это единственно-возможный способ реализации;
- это требования клиента или платформы;
- это способ уменьшить количество багов у web-developer’oв при работе с HTML кодом;
- необходимо упростить места соприкосновения клиента с кодом

Умение «верстать на дивах» (и править достаточное количество нетривиальных багов) требует наличия подобного опыта у HTML кодера.

Менее изящная, но стабильная табличная вёрстка покрывает основные запросы к вёрстке в 80% типовых задач.

Смешанная вёрстка - компромисс и способ вобрать лучшее из двух вариантов.

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

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

Действия:
1. PM и HTML кодер: В начале проекта обсудить вопросы, касающиеся типа вёрстки.

2 PM и HTML кодер: Воспользоваться консультантом, попросить консультации у коллег.

2.2 Требуется табличная вёрстка, а исходный материал на блочной
Худший вариант:
Для редизайна проектов, которые были на табличной вёрстке клиент предоставил версию, полностью выполненную в DIV вёрстке.

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

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

Тот же результат (создание практически с нуля, а не переделка), если заказчик прислал вёрстку не подходящую для используемой платформы.

Действия:
1. HTML кодер: Использовать смешанную вёрстку (процесса адаптации и багов на стыках двух типов не избежать, однако это минимизирует расход времени в сравнении с созданием с нуля).
2. PM: Понимать и учитывать при оценке, что в подобной ситуации дизайн не берётся как есть. Конечный результат представляет собой симбиоз прошлого решения и клиентского варианта. Любое нововведение чревато багами, множащимися в геометрической прогрессии.

3. Знание проекта (структуры папок, элементов, генерирующих дизайн).
Худший вариант:
HTML кодер не знает проект.

Хорошая практика:
HTML кодер знает проект.

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

Действия:
1. Рабочий процесс: Изучение используемых платформ в свободное от проектов время. Таск на ознакомление с системой перед началом проекта. Проведение обязательной аттестации на знание системы.

2. Рабочий процесс: Использовать в проекте консультанта с таском «Консультирование» (кроме этого таска он в проекте может не участвовать).

3. PM и HTML кодер: Воспользоваться консультантом, попросить консультации у коллег.