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

Слово «дизайн» означает «проектирование», а не «оформление». Техническое задание — часть проекта. Но новый самолёт нельзя строить без конструкторских чертежей, а сайт — без макетов интерфейса.

Из этого правила есть вполне работоспособное исключение. Можно один раз спроектировать стандартный сайт для всех будущих клиентов, сведя функцию дизайнера к оформлению пунктов меню и заполнению «места для бомбы» в шапке главной страницы. Такая конвейерная разработка позволяет существенно снизить сроки и издержки на разработку. При таком подходе программисты могут начать прикрутку ещё до ТЗ.

Насколько я могу судить, по такому пути идут многие веб-студии. И здесь всё хорошо, пока клиент не понимает, что получившийся сайт решает какую-то среднестатистическую задачу сферического клиента в вакууме, а не его, любимого.

Мы придерживаемся такого порядка работы: работоспособная схема системы → сценарии использования → структура навигации ↔ макеты экранов ↔ вёрстка и программирование. Дизайнерская работа не прекращается на этапе программирования — в это время возникают и решаются самые неожиданные и ответственные задачи.

Комментарии

Максим, можно делать и так, и эдак, только в результате получатся два разных сайта.

>> Мы придерживаемся такого порядка работы:
>> работоспособная схема системы → сценарии
>> использования → структура навигации ↔ макеты
>> экранов ↔ вёрстка и программирование.

Интересно! Артём, пожалуйста, поделитесь своим опытом, приоткройте ещё немного свою «кухню»:

Какими инструментами вы пользуетесь на этапах «работоспособная схема системы — макеты экранов»? Простыми — такими как бумага, карандаш, флипчарт, наброски в визио/шопе/иллюстраторе или сложными — создавая рабочие прототипы (которые можно потыкать) — какими-нибудь средствами.

Считаете ли вы полезными средства совместной работы (Бэйскемп и т. п.) или же вам хватает для работы над проектами переписки по электронной почте?

Когда вы считаете правильным показывать заказчику первые результаты вашей работы? На этапе «макеты экранов» или же на более ранних?

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

Мы используем Бейскемп и находим его очень полезным. Макеты делаем в обычных графических редакторах.

Джесс Джеймс Гаретт тоже долго думал насчёт порядка этапов разработки сайта. И нарисовал такую замечательную диаграмму: http://www.jjg.net/elements/pdf/elements.pdf

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

Я всегда следую принципу «1001 черного ящика». Компоненты системы (отрисовщики, прокси к БД, к кешерам и т. д.) представляют собой полноценные законченные модули (чёрные ящики), при этом имея возможность неявно подгружать друг друга при необходимости. Но между собой они общаются по так называемым общесистемным «контрактам», то есть формат передачи данных между модулями един для всей архитектуры. В целом как раз и получается система из большого количества маленьких ящичков, каждый из которых можно переписать, при этом не сломав всю архитектуру.

Также необходимо быть аккуратным с хранилищем данных. Знайте, если вы проектируете и оптимизируете базу данных под конкретную бизнес-задачу, то при даже незначительных изменениях бизнес-задачи могут понадобиться значительные изменения в БД.

Я рекомендую хранить сущности и связи между ними в БД в разных таблицах. Это позволит без потрясений переживать ситуации, когда изменяется характер связи (было один ко многим, стало многие ко многим) или её направление.

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

Никогда не надо ставить самоцелью проекта его техническую реализацию, это совсем не то, что интересует клиента. Наоборот, надо подчинить процесс разработки дизайну, ведь именно он продаёт продукт.

Артём, если можно, расскажите подробней о «работоспособной схеме системы», которая появляется ещё до составления сценариев. Что это и для чего служит, ну а если ещё и пример покажете, то вообще замечательно.

Я, если честно, удивляюсь что все пытаются расставить очередность задач. Все последние конференции о разработке программного обеспечения и разработке веб-проектов говорили об одном и том же. Итеративное движение более эффективнее «порядкового».

Для меня разработка выглядит так:
1. Анализ требований
2. Выбор задач нужных для решения в первую очередь и не блокирующих друг друга
3. Выбор решений и тестирование их по мере возможностей с пользователями, клиентами и т. п.
4. См. пункт 1., учитывая изменения и, возможно, новые требования.

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