Почему PSD → HTML — устаревшее решение

Когда-то давным давно, в году так 2008 (который я люблю вспоминать за то, что веб в нем был менее развит, чем сейчас) были интересные практики — сначала дизайнер отрисовывал макет в Photoshop, затем верстальщик его верстал. Вроде бы неплохой путь, но у меня к нему есть несколько претензий.

• Я не встречал на этом пути этап «разработка интерфейса». Графический дизайнер делал макет, затем верстальщик его реализовывал (очень часто pixel perfect — пиксель-в-пиксель). А графический дизайнер мог быть отличным иллюстратором, но как же часто я при таком подходе видел огромные дыры в юзабилити.
• При pixel perfect дизайн получался не гибким (например, разрешения экранов — обычно брали 1280х1024 и 1920х1080, больше никаких). «Резиновая» верстка была уделом дорогих специалистов.
• Я всегда считал и считаю, что Фотошоп необходим для редактирования фотографий, а не для макетов. Для макетов подходят другие вещи, например, тот же Illustrator — векторная графика, на самом деле, отличная вещь.

Адаптивный дизайн

screensiz.es наглядно демонстрирует огромное количество touch-устройств и их разрешения экранов.

Да, мир изменился — здесь теперь не господствуют desktop с 1280×1024, в нем теперь есть огромное количество ноутбуков, но чего еще больше (субъективное мнение) — планшетов и смартфонов. Я не буду в этом посте рассказывать, почему сложилось именно так, ответ очевиден — большинству людей не нужны мощные рабочие станции, им достаточно планшетов и мобильных устройств для потребления контента.

Photoshop-way не особо подходит для такого мира — нужно делать несколько макетов, что весьма трудозатратно по времени и бюджету.

Развитие веба

Веб изменился, стал интереснее и сложнее домашних страничек, и весьма сложно этого не заметить. Пока Фотошоп предлагает лишь графический дизайн, в вебе появились как минимум анимации и прочие интерактивные вещи. Single page application туда же относятся — если правильно подойти к этой технологии, можно сделать удивительной отзывчивости и некой приятности интерфейс. Да, в фотошопе есть анимации, но вы же не будете, простите, писать на PHP работающие сервисы, а не небольшие скрипты, вы предпочтете Scala или какой-нибудь другой язык, потому что под каждую задачу нужен свой инструмент.

Решение проблемы

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

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

1. Product manager собирает требования к функциональности, собирает полное ТЗ по проекту.
2. UX Developer оценивает это ТЗ, предлагает свои улучшения — кому, как не человеку, который занимается интерфейсами, знать, как должен выглядеть конечный продукт. И, конечно же, делает прототипы — для этого годится Balsamiq, Axure, NinjaMock и другие сервисы и технологии.
3. После нескольких итераций по обсуждению базовой функциональности получаем готовое ТЗ, которое идет для первой версии.
4. Архитектор на основе этого ТЗ продумывает архитектуру сервиса, а верстальщик верстает макет финального прототипа с помощью фреймворков — Twitter Bootstrap, Foundation и тому подобное. Они экономят время, позволяя сосредоточиться на работе.
5. …которую затем реализовывают backend-программисты с учетом подхода API first.
6. Если API изначально было задокументированно, то параллельно с backend-программистами frontend-разработчики делают клиентскую часть, а графический дизайнер реализовывает конечный дизайн продукта (верстка-то готова уже).

А затем цикл повторяется в каждой итерации, улучшая функциональность. Как видите, такой подход позволяет сократить издержки и вот почему:

• Нет постоянного уточнения ТЗ, оно полностью готово и необходимо лишь ему следовать.
• Несколько команд работают одновременно:
  
  • UX Developer и Product Manager обсуждают и формируют ТЗ
  • Затем архитектор разрабатывает архитектуру, параллельно верстальщик верстает финальный прототип
  • Backend-разработчики делают API, параллельно frontend-разработчики делают клиентскую часть. Иллюстратор (человек, не программа от Adobe) реализовывает графический дизайн сервиса.

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