Максим Сорока
19 ноября 2009

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



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

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

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

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


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


Поделиться

Комментарии

Денис Братчук
19 ноября 2009

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

Дмитрий Олляк
19 ноября 2009

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

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

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

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

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


20 ноября 2009

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

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

Женя Софронов
19 ноября 2009

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


19 ноября 2009

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

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

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

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

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

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

Виктор Глушенков
20 ноября 2009

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

Саша Сергеев
21 ноября 2009

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

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

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

Евгений Ширин
2 февраля 2011

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

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

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

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

Георгий Иванкин
7 февраля 2011

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

http://gettingreal.37signals.com/ch09_Interface_First.php


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

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

Вот такой веб 2.0.

Вы не обязаны соглашаться Как вести документацию по дизайну Как флексить. Перенести на следующую итерацию Как флексить. Не выходить в надсистему




Недавно всплыло

5 Расскажите об обратной связи в интерфейсе 1 Это я неправ, что долго думал, или магазин, что допустил такую ситуацию? 3 1