Что такое т3 в дизайне
Перейти к содержимому

Что такое т3 в дизайне

  • автор:

Что такое Т3?

Виктор Ющев

Aizek000, А вы — заказчик или исполнитель? Если последнее, то хочу напомнить о существовании Яндекса и гугла, где можно поискать ответы на тривиальные вопросы. И навык поиска информации в копирайтинге и рерайтинге очень даже нелишний. На Ваш же вопрос Вам ответили выше.

Фаина Ш.

148 сообщений
# 8 лет назад

Еще вам может встретиться такое — (цифра)/1К. Цифра означает стоимость (30, 50, 75 рублей или в долларах), за которую вам предлагается написать 1000 знаков без пробелов (=1К). Эх, сразу вспомнила свои первые шаги и попытки расшифровать некоторые опубликованные проекты.

Ольга Жосан

1756 сообщений
# 8 лет назад
Faina_Shatrova, а я все интуитивно как-то растолковывала)))) причем успешно

Фаина Ш.

148 сообщений
# 8 лет назад
helga_1985, везёт. У меня не всегда получалось:o

Ольга Жосан

1756 сообщений
# 8 лет назад

Faina_Shatrova, есть многие вещи, которые и сейчас меня в тупик заводят. Вот недавно узнала про Markdown, благодаря заказчику. Хотя раньше о нем и не слышала. Освоила за 2 минуты.

Фаина Ш.

148 сообщений
# 8 лет назад
helga_1985, Да, по ходу пьесы многое приходится осваивать, — и это радует.

Екатерина С.

1227 сообщений
# 8 лет назад
Что вы человека с пути сбиваете? Есть же википедия, ссылка ответ на его вопрос.

Ольга Жосан

1756 сообщений
# 8 лет назад
Zozulya, точно, именно Тракторный завод

Наталия Иванова

3002 сообщения
# 8 лет назад

Мне Яндекс на запрос «ТЗ это» выдал верную трактовку относительно нашей специфики деятельности. А так круто было бы — заказчик для рассмотрения проекта должен бы был предоставить тракторный завод исполнителю.

Что такое хорошее Т3 на сайт?

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

  1. Описание проекта — цели, задачи, целевую аудиторию, конкурентов и т.д.
  2. Требования к дизайну — цветовые схемы, шрифты, типографику, макеты и т.д.
  3. Функциональные требования — перечень страниц, функций, форм, виджетов и т.д.
  4. Технические требования — платформа, язык программирования, базы данных, CMS и т.д.
  5. Требования к безопасности — защита от взломов, шифрование данных и т.д.
  6. Требования к оптимизации — скорость загрузки, адаптивный дизайн, оптимизация под SEO и т.д.
  7. Тестирование — тест-кейсы, условия тестирования и т.д.
  8. Сопровождение — техническая поддержка, обновления, доработки и т.д.

Зачем составлять техническое задание ( ТЗ) на сайт?

Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: “А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?” В разработке как ПО, так и любого сайта частая проблема — никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?

Следствие закона Паркинсона “девяносто-девяносто”:
Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.
Из книги А.Купера “Психбольница в руках пациентов”.

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

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

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

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

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

Стоит разделять ТЗ для малых и больших сайтов. Это — два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько “отделов”, а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

По сути, толщина документов зависит от сложности процесса в больше степени, нежели от размеров проекта.

Мы будем следовать самому сложному пути.

ТЗ отвечает на вопросы

ТЗ изначально создается для нескольких участников разработки:

  1. Разработчики проекта (дизайнеры и программисты).
  2. Проект-менеджер.
  3. Клиент.
  4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

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

Для кого создается сайт и для чего?

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

Как будут решены задачи заказчика и пользователей?

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

Как будет проходить создание проекта?

Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику?
По ГОСТу предусмотрен отдельный раздел “Этапы разработки системы”. В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

Что будет приниматься на выходе?

ТЗ начинает разработку и ставит в ней точку.
В идеале вы должны пройтись по всем пунктам ТЗ вместе с заказчиком, свериться с полученной системой и спустя неделю сказать: “Уф-ф. Вроде все сделали”.
“ТЗ является средством верификации выполненных работ.” — такая фраза записана во введении многих моих ТЗ.

Что требуется для дальнейшего запуска проекта?

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

Из чего состоит ТЗ

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

Общая информация

Первая часть ТЗ содержит введение и общую информацию о документе и проекте в целом. Введение надо написать один раз и на всю жизнь. Как правило, там пишутся настолько абстрактные фразы, что в каждом новом проекте надо лишь подправить пару слов.

Общая информация включает в себя:

  • Информацию о заказчике и исполнителе.
    Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
  • Назначение проекта.
    Указывается: для чего будет использоваться полученный продукт.
  • Цели создания и задачи, которые должен решить ресурс.
    С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены нечетко и неизмеримо, то может быть довольно сложно им следовать.
  • Описание аудитории проекта.
    Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
    Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация, которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи — описывать собирательный образ конкретных людей.
  • Термины и определения.
    В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.

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

Эта информация собирается в рамки проекта.

Рамки проекта

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

Рамки проекта примерно то же самое. Прочитав эту главу каждый должен представлять, что будет получено в процессе разработки, но абсолютно не вдаваясь в детали. Вы пишите, что на сайте будет работать “регистрация пользователей”, но не пишите, как конкретно она будет устроена, или какие поля должен будет заполнить пользователь.

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

Рамки проекта пишутся в виде сценариев работы пользователей с сайтом и описывают общую функциональность и интеракции с интерфейсом.

Информационная архитектура и интерфейс

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

Для описания ИА потребуется описывать сверху вниз:

  1. Структуру сайта. Это так называемые высокоуровневые прототипы.
  2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
  3. Опись контента. Табличное описание содержания каждой страницы сайта.
Структура сайта

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

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

Не забывайте присваивать номер каждой отдельной странице карты сайта. Это потребуется на этапе описания контента.

Полезные советы при рисовании карты сайта:

  • Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг от друга. Это поможет читабельности карты.
  • Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
  • Выравнивайте “квадратики” страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
  • Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны “перескакивать” одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
  • Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
  • Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.
Шаблоны страниц

На уровне карты сайта каждая страница представляет для нас только “квадратик” на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне недешево.

Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.

Описание шаблонов состоит из 3х частей:

  1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
  2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
  3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

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

Описание контента

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

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

Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

Функционал

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

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

Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты.

Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы “клиенту было понятно”. Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему надо.

Требования

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

  • Технические требования к системе;
  • Требования к персоналу;
  • Требования к надежности;
  • Требования к эргономике и технической эстетике;
  • Требования к защите информации от НСД;
  • Требования по сохранности информации при авариях;
  • Требования к видам обеспечения;
  • Требования к программным средствам;
  • Требования к информационному обеспечению;
  • Требования к техническим средствам;

Может быть также ряд специфических требований.

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

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

Прочее

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

Что дальше?

ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.

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

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

В сухом остатке

Эту статью я написал больше года назад. Прошло довольно много времени, а я за это время не написал ни одного большого ТЗ. Но, перечитав представленную информацию, согласился со всем, что здесь написано. Итак хорошее ТЗ на сайт должно содержать в себе:

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

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

Что такое т3 в дизайне

Термины и определения

Термины и определения — Форум Адвего

Каталог заказов

  • Статья, обзор, SEO-копирайтинг
  • Перевод
  • Корректура текста, исправление ошибок
  • Расшифровка аудио и видео, сканов и фото
  • Лайки в соцсетях
  • Лайки без отзыва на сторонних ресурсах
  • Репосты, подписки, голосования
  • Приглашение пользователей в группы
  • Публикации в соцсетях, репосты с комментариями
  • Новая тема на форуме
  • Комментарии на сайте заказчика
  • Google Play, AppStore — оценка без отзыва
  • Google Play, App Store — установка и отзывы
  • Яндекс и Google — карты, маркеты, справочники
  • Отзовики, каталоги компаний
  • Авито, маркетплейсы и доски объявлений
  • Размещение ссылок на сайтах и форумах
  • Продвижение бренда без ссылок
  • Работа на сайте исполнителя
  • SEO-услуги
  • Контент-менеджмент, работа на сайте заказчика
  • Работа в поисковых системах, улучшение ПФ
  • Поиск информации, полевые задания, чеки и бонусы
  • Тестирование, разметка данных, картинок

Поиск статей
Поиск работы
Авторизация

Вывод средств самозанятым
  • комиссия 0% + 40 руб.,
  • вывод за 1 рабочий день,
  • вывод на карты РФ и Юмани.
  • Акция для исполнителей: заработай праздничный кешбэк в январе!
  • Награждение лучших исполнителей 2023 года и конкурс поздравлений!
  • Заказчикам: новые пакеты продвижения заказов
  • Приложение Адвего 1.7.26 для Android — выполнение заказов, форум и конкурсы
  • Сертификация Адвего для исполнителей / Возможность получить статус Гуру
  • Поздравляем победителей и призеров конкурса «Короткометражки Адвего»!
  • Новогодняя распродажа PRO-аккаунтов — со скидкой до 70%!

Лучшие исполнители

Что значит Т3 и как это понять?

Доброго времени суток, уважаемые пользователи помогите пожалуйста разобраться начинающему копирайтеру. Недавно отправила работу заказчику, он мне прислал её обратно на доработку, указывая что необходимо » добавить ключи, смТ3″, подскажите что значит это самое Т3, как я понимаю это именно третий ключ который необходимо в текст?

/blog/read/faq_terms/4626544
Написала: DELETED , 02.08.2018 в 08:24
Комментариев: 16
Вы успешно подписались на тему и теперь будете получать уведомления при появлении новых сообщений

Вы успешно подписались на ответы на собственные сообщения в теме и теперь будете получать уведомления

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

Участники: DELETED 2 , DELETED 1 , flashlom 1 , julitim20 1 , S0-866 6 , Белоусов (advego) 4 , Евгения (advego) 1

Лучший комментарий DELETED написала 28.04.2022 в 05:38

Эти задания далеко не так просты, как кажутся. У меня реальные отзывы блокируют на раз-два — как положительные, так и отрицательные. Я упрела уже со . Эти задания далеко не так просты, как кажутся.
У меня реальные отзывы блокируют на раз-два — как положительные, так и отрицательные.
Я упрела уже со службой поддержки Яши спорить.
Ни одного заказного отзыва никогда не размещала, но проходит модерацию один из пяти.
Череда отклонений приходится, чаще всего, на периоды конкурсов Адвего — когда я начинаю по несколько раз на дню открывать сайт биржи.
Автоматика Яндекса определяет меня, как лазутчика, и до модерации «живыми» сотрудниками дело не доходит.
Кроме того, специалисты службы поддержки Яндекс Бизнес не раз сообщали, что после автоматического отклонения никак повлиять на публикацию не могут.

Как составить ТЗ для дизайнера?

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

Немного о хорошем ТЗ

Существует мнение, что ТЗ ограничивает фантазию дизайнера и не дает ему выплеснуть весь свой креативный задор в работе над макетом. Это неправда

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

Представьте, что вы дизайнер интерьера и к вам пришел заказчик, вам дают работу и говорят: «Я хочу поменять интерьер своей гостиной, я не хочу в чем-то вас ограничивать, я хочу увидеть ваши идеи, можете креативить по-полной». Если вы начинаете задавать вопросы, то в ответ ловите фразу: «Я полностью полагаюсь на вашу фантазию». Заказчик не хочет наводить вас на мысли. Он в серьез полагает, что не должен придумывать за вас дизайн.

И вы, конечно же, попадаете в ловушку. Получив такое задание, вы становитесь счастливым, как будто завтра вам улетать на Бали, а жить вы там будете целый месяц. Можно же делать теперь, что душа пожелает и воплотить все свои давние задумки в жизнь! Но не стоит так радоваться. На самом деле целый месяц вы будете не на Бали, а у компа работать над правками. В 99% случаев заказчик не одобрит ваш вариант

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

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

Так что же делать?

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

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

Хороший специалист должен вытянуть из вас всю информацию

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

Именно дизайнер должен составлять ТЗ на основе ваших ответов. Вопросы не должны быть прямо в лоб, типа: «Какие вы любите цвета? Какой шрифт вы предпочитаете? Какой вам нарисовать дизайн?»

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

Вопросы должны быть, например, такими: «Для чего вам сайт? Чем вы отличаетесь от конкурентов? Какими достижениями гордитесь? Кто ваш идеальный клиент? Что в идеале должен сделать посетитель на вашем будущем сайте?»

Если сайт уже есть, то вопросы могут быть такими: «Почему вы решили обновить дизайн? Какую текущую проблему вы хотите устранить при помощи обновления дизайна? Как изменился ваш подход к клиенту с того времени, как вы запустили первую версию сайта?»

Ваша задача внимательно заполнить бриф дизайнера

После того, как вы ответили на все необходимые вопросы, дизайнер сам составляет ТЗ

Он должен выслать его вам на согласование. Вы либо подтверждаете, что со всем согласны и все так, либо вносите коррективы.

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

Дизайнер должен подсказать как будет лучше для проекта и предложить решения, на основе ваших ответов

Вот и все. Надеюсь теперь вам стало понятно, как важно на первоначальном этапе поработать над ТЗ. Всем успехов, и хороших дизайнеров!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *