ТЗ на дизайн: надо ли и как писать. Критика примера

Стартовая страница содержит крупный логотип до 25% высоты сайта

походу заказчикам нравится смотреть на их огромный логотип!:) а вот как же все остальные люди ?

В самом ТЗ предлагается два различных решения - и какой же из вариантов исполнитель должен выбрать?

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

Мне кажется, что в ТЗ смешаны понятия дизайна и контента.

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

Я как-то интересовался темой ТЗ на дизайн, но ничего конкретного не нашёл.
Но хочу отметить, что стоит выделять пунк о цветах, а также о стиле бутьто (академический, Aero, округлые углы из Web2.0, готика(заказы разные бывают), так же стоит указать дизайн главной или ещё и внутренних страниц, (Можно же показать примеры)).

Вывод: результат работы для того, кто писал ТЗ абсолютно не важен: он использовал самую примитивную модель: нравится, не нравится. Он использовал еще более примитивную модель: преимущества, недостатки. Результат будет не такой, на который надеются.
Теперь самоутвердившись на авторе ТЗ, я напишу о том, как писал задание я:
1) определение функций сайта;
2) поиск аналогов;
3) анализ конкурентов (на тот момент конкурентом был только я сам);
4) изучение структуры.
Вывод: как у других делать не надо.
Т.е. я не давал возможность сделать хоть что-то так же, как у конкурентов. Затем, когда мне принесли дизайн от противного, я начал его совершенствовать, т.е. мне казалось, что совершенствовать. В результате родился третий монстрик. Переделали, принесли еще раз. Сравнил с аналогами конкурентов. Сравнение было в пользу нового макета, придравшись к "обезьянке в нижнем углу", отправил на переделку. Принесли, работает. Спасибо студии хх.

Вцелом это же прочитать невозможно.

Творческие задания написаны со слов заказчика или после дизайн-брифинга?

У нас ТЗ для дизайнера примерно в следующей форме.

Тип сайта: Корпоративный (визитка, интернет-маг, портал, эксклюзифф)
Элементы фирм.стиля: Логотип, цвета, слоганы, шрифты, буклеты
Цвета: Такие, такие, такие
Элементы на сайте:
Флэш элемент
Блок контакты (тел, icq, мыло)
Меню

Включенные модули:
Новости
Каталог продукции
Поиск
Портфолио
Что-нить еще (форум, блог, вопрос-ответ, и т.п.)
+ Стандартный пакет (контакты, карта сайта и т.п.)

На главной выводить: посл.новости, поиск, последнее из портфолио, 10 картинок продукции (рандом), блок контакты, флэш элемент, меню.

Клиенту нравятся сайты:
№1
№2
№3

Нарисовать 2-3 варианта.

Примерно так.

Алексей Lessio (http://lessio.ru/):
— Составление технического задания сайта
— Проблема технических заданий

Руководствовался всегда сам и давал читать тем кто не представляет, что такое ТЗ и зачем оно нужно.

Ой ой ой!! Какой интересный топик! Я вот уже все глазами пробежал, чуть позднее наверное смогу подробнее откомментировать, а пока только вот что скажу.

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

Безусловно необходимо отдельно указывать все основные моменты касающиеся поведения сайта и тех технологий, которые будет использованы при разработке. Что же касается формализованного описания композиции, то это ИМХО задача слишком трудно выполнимая. Вот у нас например для это служит такой документ, как сценарий сайта. По сути это рассказ о сайте и о том, что на нем происходит. Легко читать, легко воспринимать, легко сделать!

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

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

Так же не совсем понял с конкурентами. Я не совсем понимаю это конкурирующие фирмы закащика или ваши ?
Цели лучше делить на 3 штуки: с какой целью заказчик делает сайт, с какой целью на него будут ходить люди, ну и дизайнер тоже должен поставить с какими целями он будет делать дизайн(заработать денег, попробывать новую фишку, выделиться среди комьюнити дизайнрского)

Интересно, и что же в этом «ТЗ» технического? Почему вы его так называете?

    ТЗ, по сути, это нечто подобное чертежу, по которому потом строиться сайт, или дизайн, или любое программное творение, оно защищает как заказчика, так и программиста,или в данном случае дизайнера.
    Рассмотрим пример: Есть одна фирма X и она хочет создать сайт,основная концепция программной стороны уже решена и дело перешло к дизайну всей этой программной стороны...
    Варианты дальнейшего развития.
1.Дизайнер рисует макет без ТЗ, немного поговорив с Заказчиком по телефону, и узнав общий план.
    Дизайнер кропотливо вырисовывает макет сайта, с представленной, насколько возможно информацией , и если есть фирменным стилем... Потом он выкладывает макет для просмотра заказчику, и оказывается заказчик хотел немного иначе, другие тона, другие цвета, и переделка данного макета может продолжаться очень долго(Конечно смотря какой заказчик...)
2.Дизайнер рисует макет по полному кропотливо написанному ТЗ.
    Дизайнер по сути механически перерисовывает все то, что он видит на бумаге в ТЗ, никакого полета мысли, жесткие рамки и все. В итоге мы получаем довольно-таки сухой сайт, при создании которого и у дизайнера не было удовольствия, и у заказчика (Сам много раз встречался...) складывается плохое впечатление по самому макету, и ему так-же многое не нравится(Ибо он представлял себе это не так... Хоть и написал жесткие требования) и так как ТЗ является защитой не только заказчика но и исполнителя, существует 2 развязки: 1. Сайт выходит в жизнь, с дизайном, не понравившемся никому, либо 2. Долгие завязки в бюрократии бумаг.
3.Дизайнер и заказчик формируют ТЗ совместно и мягко, в процессе.
    У дизайнера есть небольшое пространство для полета мыслей, у заказчика есть гарантия, что он увидит то, что он хочет. Дизайнер с заказчиком, рассматривают основные цветовые гаммы, рисунки, элементы дизайна, и совместное их расположение. После этого подписывается ТЗ, в котором есть данные о всем что они договорились. И Дизайнер продолжает работу. Неплохой по моему мнению вариант: Дизайнер защищен от того, что после работы по созданию макета, ему не скажут: "Эй, это не совсем то, давай-ка все заново!", ну если и скажут, то это будут другое ТЗ и другие финансы. И у заказчика защита вроде тоже как есть...
    Главное во всем этом не затягивать с бумагой, а выработать небольшой структурированной план, который можно быстро описать. Огромные ТЗ на дизайн заберут много времени, да так, что не хватит времени на сам дизайн...

Это не техническое задание. Это больше похоже на список пожеланий заказчика, конспект беседы, заполненный как-то бриф. Но это — не ТЗ.

ТЗ — это список требований, прежде всего. Конечно, там могут быть и другие разделы, например, цели и задачи, общее описание (рамки проекта) наподобие executive summary.

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

- лента новостей

Лента новостей одна или несколько? Будет ли архив? Как он будет представлен? Будет ли экспорт новостей в RSS? Какие элементы у каждой новости может редактировать заказчик? Как будет осуществляться редактирование новостей? Что будет у каждой новости — заголовок и текст или же будет еще и анонс (краткое содержание)? Куда будут выводиться анонсы или заголовки новостей?

содержит крупный логотип (до 25% высоты сайта)

Кстати, что понимать под «высотой сайта»? Какова будет высота сайта при разрешении экрана 800x600? А при разрешении 1280х1024? Какова будет высота сайта, если страница занимает несколько экранов? Какова будет высота сайта, когда пользователь уменьшит окно?

...и левое текстовое меню с графическими маркерами (стиль как на h__p://viveska.info)

Какое-то левое получается меню. Такое «ТЗ» нельзя прикладывать к договору. Вот изменится меню на viveska.info — что будете делать?

ТЗ — это инструмент для профилактики и разрешения разногласий, устранения неопределенности и недопонимания, определения объема и состава выполняемых работ и характеристик конечного продукта.

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

Вот теперь заказчик может вертеть вами, как хочет. «Хочу трехмерную анимацию и видео!» — изрекает заказчик. «Но мы же так не договаривались», — пищит подрядчик. «Как не договаривались?! Только трехмерная анимация и видео могут подчеркнуть широкий спектр и нашу производственную базу, другого не примем!» — добивает заказчик.

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

Поэтому когда даётся задание дизайнеру, прежде всего, прилагается бред бук, и как дополнение пожелания (которые здесь обозвали ТЗ).

Совсем другой вопрос, что в России и Украине бенд буки есть только у крупных компаний, и в этом случае, конечно, нужно делать полноценное ТЗ на дизайн, иначе заказчик рискует получить совсем не то, что хотел.

Может быть моё сообщение будет и не в тему, но на мой взгляд в этой статье идёт ПИАР четырёх сайтов одной компании (это _alfa-suvenir.ru, _elenara.ru, _tipograf.info, _viveska.info )

Я даже незнаю что это за заказчик (а есть ли вообще этот заказчик ???), которому понравились криво сделанные сайты сделанные в разном стиле.

Посмотрите к примеру сайт _elenara.ru, где поехал весь дизайн, где половина ссылок ведут на другие сайты и т.д. Вообщем тихий УЖАС. И спращивается что ему тут понравилось ???

клиент прав))) не всегда удается объяснить клиенту что вот так будет более правильнее))

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

На мой взгляд, этот раздел надо бы озаглавить "Пожелания заказчика к дизайну" и вместо "каталог товаров и услуг не проиллюстрированы" писать "каталог товаров должен содержать фотографии и цены (выделить на фоне текста)", а вместо "шрифты страниц неконтрастны, плохо читаемы" писать "шрифт должен быть конрастным, хорошо читаемым". Такой раздел - результат анализа конкурентов - действительно является набором требований и нужен дизайнеру.
Если вы просто хотели запечатлеть то, что слышали от заказчика (чтобы он видел, что информацию вы обработали), можно было бы записать это в отдельный документ, но в тз вынести конкретные требования.

Скажите, пожалуйста, а кто должен составлять ТЗ на дизайн?
В примере приводятся варианты расположения блоков, их размеры и состав — все это так или иначе относится к (техническому) дизайну, менеджер проекта вряд ли сможет толково все расположить, а сам клиент тем более. В то же время, дизайнер не знает подробностей проекта и не может решить сам, как будет располагаться информация, как она распределится по страницам, в каком будет формате и прочее.

Из собственной практики: дизайнерам, с которыми довелось работать, было достаточно этого набора:
1. Пакет (диск) с образцами фирстиля: лого (лучше в составе брэнд-бука), слоган, бланки, буклеты, календари и прочая продукция, чтобы без проблем вписаться с сайтом в эту общую линейку.
2. Краткая справка по деятельности компании.
3. Примеры дизайна нейтральных сайтов, которые нравятся заказчику с его краткими комментариями почему.
4. Примеры дизайна нейтральных сайтов, которые не нравятся заказчику с его краткими комментариями почему.
5. Список сайтов конкурентов с краткими комментариями заказчика, что нравится, а что нет.
6. Предполагаемое дерево сайта.
7. Список функциональных элементов на страницах сайта, пример для главной: лого, основное сообщение сайта, меню/навигация по сайту, рубрикатор каталога, несколько новинок, последние новости и т.д. Если дизайнер не дебил, то размеры блоков и то, как расставить акценты, сообразит сам.
8. Если есть ограничения по функционалу модулей/блоков, то это тоже лучше описать. Пример: блок новинки состоит из четырех товаров (можно варьировать), размер изображения товара 120х120 (можно варьировать). У каждого товара: название, краткое описание, производитель, цена. И т.п...

Мне кажется, автор пытался выяснить этапы создания сайта, в частности дизайна. Так как этапы разработки во многом взаимосвязаны, я поделюсь своим видением:

У нас техническое задание составляет проектор, присутствующий вместе с менеджером по работе с клиентами на встрече с заказчиком, цель которой узнать «Для чего нужен сайт?» - концепция, «Что можно и нужно, чтоб было на сайте обязательно» - функциональная часть, «Какое впечатление должен производить сайт?» - дизайнерская сторона, «Предпочтения заказчика» и «Предпочтения целевой аудитории».

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

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

Так, о чем это я… ага – Тяжела судьба проектора, он похож на интерфейс. Он пишет ТЗ и приложения: общается с дизайнером, верстальщиком, программистом, сеошником и другими действующими лицами изъясняясь на ИХ языках и раздавая им задания.

То что автор статьи назвал ТЗ на дизайн, пишется с участием проектора, верстальщика и дизайнера. И это самое ТЗ на дизайн составляется после утвержденной с клиентом концептуальной и функциональной части.

А на стадии утверждения концептуальной и функциональной частей проектор намеренно избегает упоминаний о визуальном отображении вроде: «Здесь будет желтая кнопочка, здесь красненький цветочек», так как это может противоречить мнению дизайнера, и вообще это задача именно дизайнера, он профессионал в этом деле, ему ее и решать.

Если заказчик что-то придумал в дизайне и хочет именно этого, мы обычно делаем два макета: так как пожелал клиент и так как резоннее со стороны дизайнера, а при встрече аргументировано объясняем преимущества решения дизайнера.

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

P.S. простите за трактат, очень актуально :)))

Я тут гляжу, все чаще все кричат о бренд-буках, и всяких подобных вещах. Скажу из практики:
    Множество компаний малого и среднего бизнеса не имеют понятий таких как бренд-бук.
    Пример: Приходит заказчик и говорит: "Хочу сделать сайт для своей компании X". У него спрашивают, а вот у вас есть логотипы, фирменные стили, и тд. Чтобы так- сказать создать концепцию дизайна. А он отвечает: "В моих салонах(К примеру о торговой организации) в основном цвет стен - такой желтенький, и с красненьким по бокам, и я думаю сайт тоже нужно сделать приблизительно также, что-бы люди когда пришли в салон видели туже гамму". Такого понятия о бренд-буке вообще не имеет. Причем если заказчику предложить разработать фирменный стиль, он скажет что его устраивают те цвета в салонах и вывеска, которую сделали без связи, так что не нуждаюсь.
    Если бы все заказчики имели бы бренд-буки, то жизнь всех дизайнеров облегчилась во много раз, а то получается как в сказке, только на другой лад: "Нарисуй мне то, не знай что, нарисуй мне так, не знаю как."

Я даже готов поспорить что если не брать серьезные компании, и большой бизнес, то в лучшем случае у 30% компаний, или будет представление о бренд-буках, или будут сами бренд-буки. Конечно я не говорю о таких городах как Санкт-Петербург, или уж другом государстве Москве, там все иначе, и то не уверен. У остальных компаний, максимум что будет из корпоративного стиля, так это шапка, которую в Word-е накидывают на бланки, или еще куда. И логотип, который они зачастую рисуют сами внутренними силами.(Еще раз говорю для малого и среднего бизнеса).
    По сути, основными клиентами на создание сайтов(коммерческих), как-раз являются развивающиеся компании, а не гиганты вроде Юкоса или Автоваза, которые с помощью интернета развивают свой рынок...

Разработка дизайна сайта - это проект. Проект необходимо документировать. Зачем?

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

В документации нужно указывать лишь необходимый минимум информации в рамках этих задач. Остальное не нужно.

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

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

> viveska.info
Интересно, что у них на главной символизирует мужик в каске — что вывески падают? :)

это не ТЗ, это бриф.
а ТЗ это обязательно нарисованный прототип странички с описанными блоками, цветовой гаммой, шрифтами и общей идеей иначе это не может быть ТЗ, так-как каждый человек может представить работу - по своему.