Школа
Управление

Подскажите, при создании сайта что раньше должно быть — дизайн или программирование?

Здравствуйте Артём. Подскажите, при создании сайта что раньше должно быть — дизайн или программирование (ТЗ уже есть)? Шеф считает, что можно весь сайт написать, а дизайн — дело последнее, я же, наоборот, считаю, что пока дизайна нет, делать не стоит.

Максим Сорока
19 ноя 2009
👁 4035   🗩9
Управление

Подскажите, при создании сайта что раньше должно быть — дизайн или программирование?

Здравствуйте Артём. Подскажите, при создании сайта что раньше должно быть — дизайн или программирование (ТЗ уже есть)? Шеф считает, что можно весь сайт написать, а дизайн — дело последнее, я же, наоборот, считаю, что пока дизайна нет, делать не стоит.

Максим Сорока
19 ноя 2009
👁 4035   🗩9
А. Г.
Арт‑директор и автор учебных программ бюро
Полезно
  
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

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

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

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

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

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

Управление проектомНоситель: сайт
Полезно
  
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для меня разработка выглядит так:

  1. Анализ требований

  2. Выбор задач нужных для решения в первую очередь и не блокирующих друг друга

  3. Выбор решений и тестирование их по мере возможностей с пользователями, клиентами и т. п.

  4. См. пункт 1., учитывая изменения и, возможно, новые требования.

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

Всё зависит от того, какой сайт вы разрабатываете. Помимо ТЗ, я выделаю следующие этапы разработки:
дизайн основной концепции;
дизайн типовых страниц пользовательской части;
дизайн системы администрирования;
дизайн иконок и функциональных элементов;
вёрстка;
проектирование базы данных;
разработка (адаптация) функциональных програмных модулей и запросов;
разработка (адаптация) системы отображения информации;
разработка (адаптация) системы администрирования;
подготовка информации;
размещение информации и тестирование.

В зависимости от сложности проекта различные этапы могут идти в разной последовательности. Хотя лучше разные процессы делать параллельно.

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

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

37signals (создатели Бейскемпа и авторы хорошей книги Getting Real) считают, что начинать нужно с дизайна. Это позволяет раньше «почувствовать» продукт и ответить на ключевые вопросы вроде «решает ли он полезную задачу»? Кроме того, дизайн легче поменять, чем код.

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы