Чем проектирование отличается от дизайна
Май, 2017
#Тезисы
В прошлом материале я рассказывал про оценку проектов и по ходу сказал, что без проектирования сделать точную оценку практически невозможно. Но вот что такое проектирование не рассказал. А с этим как известно проблема.
Большинство клиентов под проектированием понимает "нарисовать интерфейс", а если проще сделать дизайн. Дальше уже разработчики разберутся. Самое интересное, что разработчики часто думают также. Сейчас я хочу рассказать подробнее, что же такое проектирование и где в этом всем дизайн.
Рассказывать о том, зачем нужно проектирование я не буду, об этом я уже рассказал в прошлом материале. Также в этом материале я не буду рассказывать про методологии разработки, например, Agile, Scrum, RUP, MSF, критическую цепь или водопад, это тема следующего материала, где я расскажу, как может быть устроен проект, в котором проектирование выделяется в отдельный этап работ.
Рассказывать о том, зачем нужно проектирование я не буду, об этом я уже рассказал в прошлом материале. Также в этом материале я не буду рассказывать про методологии разработки, например, Agile, Scrum, RUP, MSF, критическую цепь или водопад, это тема следующего материала, где я расскажу, как может быть устроен проект, в котором проектирование выделяется в отдельный этап работ.
Материал по теме:
Так все-таки, чем проектирование отличается от дизайна?
Проектирование – это термин, обозначающий продумывание устройства, т.е. внутреннего устройства.
С точки зрения английского языка – ничем, это одно и тоже. Прямой перевод с английского слова дизайн – проектирование. Но так получилось, что в русском языке дизайн означает в большей степени за графическое представление, форму. А проектирование – это термин, обозначающий продумывание устройства, т.е. внутреннего устройства. Почему произошло такое раздвоение у нас я не знаю.
С термином проектирования разобрались, теперь давайте немного поподробнее, из чего оно состоит. Если мы говорим про проектирование программного продукта, то проектирование бывает функциональным, интерфейсным и техническим. В свою очередь каждый из этих пунктов разделяется еще на несколько.
С термином проектирования разобрались, теперь давайте немного поподробнее, из чего оно состоит. Если мы говорим про проектирование программного продукта, то проектирование бывает функциональным, интерфейсным и техническим. В свою очередь каждый из этих пунктов разделяется еще на несколько.
Функциональное проектирование — это когда проектируются пользовательские сценарии, в рамках которых пользователь взаимодействует с системой.
Интерфейсное проектирование — это собственно подбор внешней формы системы для взаимодействия с пользователем в рамках тех самых пользовательских сценариев. Это часто называют UX.
Техническое проектирование — продумываение технической архитектуры и способа реализации.
Интерфейсное проектирование — это собственно подбор внешней формы системы для взаимодействия с пользователем в рамках тех самых пользовательских сценариев. Это часто называют UX.
Техническое проектирование — продумываение технической архитектуры и способа реализации.
А где же в этой всей истории дизайн?
В зависимости от того, что это за интерфейс. Если интерфейсом является чат-бот, то дизайна вообще нет. Если мобильное приложение, то дизайн очень сильно связан с интерфейсным проектированием и как правило выделенной роли дизайнера нет и он совмещается с проектировщиком интерфейса. Для сайтов дизайн и проектирование интерфейса разделено, т.к. возможности реализации произвольного представления в вебе гораздо шире.
Почитать ещё:
Почему клиенты как правило готовы платить только за дизайн, а за проектирование не готовы?
Это в человеческой природе, воспринимать ценность только того, что можно увидеть. Поэтому дизайн и до определенной степени интерфейсное проектирование в глазах представляет собой осязаемую ценность. Такую ценность представляет разработанный продукт.
Проектирование для большинства людей штука абстрактная, ценность ее непонятна и главное нет никакой возможности проверить, хорошо оно сделано или нет. Как принимать работу, куда потом пойти с этими спецификациями, если отношения с подрядчиком испортяться. Именно по этой причине в большинстве случаев клиент даже если соглашаются на этап проектирования, то настаивают на общем контракте, который объединяет проектирование и разработку.
Что с этим делать я рассказывал в предыдущем материале и что-то мне подсказывает, что напишу еще, потому что тема острая и нужно искать слова, которые смогут донести до клиента ценность проектирования как отдельной работы.
Думаю ещё одна причина такой ситуации в том, что корни подходов к организации проектов идут из рекламных агентств, там брифы, референсы и все дела.
В какой-то момент рекламные агентства в качестве одного из инструментов начали использовать сайты. У промо-сайтов очень короткий жизненный цикл, невысокие требования к качеству исполнения и всегда жесткие сроки, потому что рекламные акции запускаются к определённому моменту. Соответсвенно там культ ASAP'а и практически никакой производственной культуры.
В тоже самое время сервисные проекты, например, сайт банка или сервиса для поиска билетов чисто технически тоже сайты, но для их качественной реализации нужен другой производственный цикл.
К сожалению агентский способ работы над проектами начисто это игнорирует и прививает у клиентов ожидания быстрого результата по брифу. Отсюда этот постоянный конфликт серьёзной разработки и инфантильных ожиданий ивент-менеджеров.
Что ещё веселее, те же самые агентства начали использовать мобильные приложения для промотирования, сделав мостик между сайтами и мобильными приложениями. Но между ними пропасть. Фактически мобильные приложения — это отдельная проектная дисциплина с более сложным циклом производства и гораздо ближе по технологии разработки к старым-добрым десктопным приложениям.
В результате на рынке мобильных приложений, даже там, где разрабатываются функционально сложные сервисные системы у клиентов есть ожидания упрощённой агентской модели работы над проектом.
Проектирование для большинства людей штука абстрактная, ценность ее непонятна и главное нет никакой возможности проверить, хорошо оно сделано или нет. Как принимать работу, куда потом пойти с этими спецификациями, если отношения с подрядчиком испортяться. Именно по этой причине в большинстве случаев клиент даже если соглашаются на этап проектирования, то настаивают на общем контракте, который объединяет проектирование и разработку.
Что с этим делать я рассказывал в предыдущем материале и что-то мне подсказывает, что напишу еще, потому что тема острая и нужно искать слова, которые смогут донести до клиента ценность проектирования как отдельной работы.
Думаю ещё одна причина такой ситуации в том, что корни подходов к организации проектов идут из рекламных агентств, там брифы, референсы и все дела.
В какой-то момент рекламные агентства в качестве одного из инструментов начали использовать сайты. У промо-сайтов очень короткий жизненный цикл, невысокие требования к качеству исполнения и всегда жесткие сроки, потому что рекламные акции запускаются к определённому моменту. Соответсвенно там культ ASAP'а и практически никакой производственной культуры.
В тоже самое время сервисные проекты, например, сайт банка или сервиса для поиска билетов чисто технически тоже сайты, но для их качественной реализации нужен другой производственный цикл.
К сожалению агентский способ работы над проектами начисто это игнорирует и прививает у клиентов ожидания быстрого результата по брифу. Отсюда этот постоянный конфликт серьёзной разработки и инфантильных ожиданий ивент-менеджеров.
Что ещё веселее, те же самые агентства начали использовать мобильные приложения для промотирования, сделав мостик между сайтами и мобильными приложениями. Но между ними пропасть. Фактически мобильные приложения — это отдельная проектная дисциплина с более сложным циклом производства и гораздо ближе по технологии разработки к старым-добрым десктопным приложениям.
В результате на рынке мобильных приложений, даже там, где разрабатываются функционально сложные сервисные системы у клиентов есть ожидания упрощённой агентской модели работы над проектом.
Почитать ещё:
Любой проект начинается с проектирования?
Проектирование – это поиск наиболее подходящего способа реализации системы, которая решает задачи бизнеса. Если задачи не сформулированы, то проектирование не даст результата.
В идеальном мире проектированию предшествует этап анализа бизнес-задачи клиента. Проектирование – это поиск наиболее подходящего способа реализации системы, которая решает задачи бизнеса. Если задачи не сформулированы, то проектирование не даст результата.
Проектирование можно выполнять сразу для всей системы, можно для отдельных ее частей – это отдельного материала. Но в любом случае должно быть сформулировано задание на проектирование, документ, описывающий концепцию продукта, бизнес-задачи, критерии успешности проекта и все те факты, которые позволят проектировщикам принимать решения исходя из фактов. Например, портретов пользователей, сценариев общения этих пользователей с бизнесом в целом (Customer Journey Map).
Проектирование можно выполнять сразу для всей системы, можно для отдельных ее частей – это отдельного материала. Но в любом случае должно быть сформулировано задание на проектирование, документ, описывающий концепцию продукта, бизнес-задачи, критерии успешности проекта и все те факты, которые позволят проектировщикам принимать решения исходя из фактов. Например, портретов пользователей, сценариев общения этих пользователей с бизнесом в целом (Customer Journey Map).
На этом этапе проектирования нужно найти ответ, какие именно функции выполняет система, чтобы пользователь мог сделать свои задачи в рамках пользовательских сценариев (Customer Journey Map). Например, это сценарий получения клиентом банка кредита. В таком сценарии есть и звонок в банк и возможно общение с операционистом. Но при проектировании нужно найти в таком сценарии точки взаимодействия с системой и выделить их как функции. В описаном сценарии это может быть функция отправки заявки на кредит.
Вторая задача – это сгруппировать функции системы в функциональные разделы. Это поможет в дальнейшем на всех этапах проектирования и вообще работы над проектом. В глазах клиента, который заказывает создание продукта, такие функциональные разделы и есть его функции, а для проектировщиков и разработчиков – удобная группировка задач и отдельных функций. То же оформление кредита состоит из нескольких функций, например, отправка заявки на кредит, проверка статуса заявки и т.д.
Вторая задача – это сгруппировать функции системы в функциональные разделы. Это поможет в дальнейшем на всех этапах проектирования и вообще работы над проектом. В глазах клиента, который заказывает создание продукта, такие функциональные разделы и есть его функции, а для проектировщиков и разработчиков – удобная группировка задач и отдельных функций. То же оформление кредита состоит из нескольких функций, например, отправка заявки на кредит, проверка статуса заявки и т.д.
Функциональное проектирование
Получилось немного абстрактно, но интерфейсное проектирование – отдельная большая тема.
На первый взгляд кажется, что задача проектирования интерфейса в том, чтобы сделать удобным каждый экран приложения или сайта. Это не так. Суть задачи в том, чтобы сделать простым и понятным для пользователя взаимодействие с системой в целом для выполнения тех функций, которые были выявлены на этапе функционального проектирования.
Иными словами, если есть возможность вообще обойтись без интерфейса, то это был бы идеальный интерфейс. А как будет выглядеть конкретный экран — это вопрос важный, но второй. Это не новость, про это многие пишут, но немногие делают.
После того, как определен канал взаимодействия с пользователем (сайт, мобильное приложение, чат или их комбинация), нужно сделать несколько задач:
Иными словами, если есть возможность вообще обойтись без интерфейса, то это был бы идеальный интерфейс. А как будет выглядеть конкретный экран — это вопрос важный, но второй. Это не новость, про это многие пишут, но немногие делают.
После того, как определен канал взаимодействия с пользователем (сайт, мобильное приложение, чат или их комбинация), нужно сделать несколько задач:
Продумать архитектуру интерфейса, т.е. подобрать решения для структурирования функций системы и информации, с которой работает пользователь.
Способы навигации между элементами интерфейса, жизненный цикл экранов.
Конкретные функции системы разложить на выбранную архитектуру интерфейса, причем не обязательно одна функция – один экран, все зависит от найденного решения.
Спроектировать каждый элемент интерфейса – это могут быть экраны, отдельные функциональные блоки, страницы, короче все, из чего состоит интерфейс системы.
Интерфейсное проектирование
Многие не в курсе, что такое вообще есть. Но без него все эти интерфейсы – просто картинки, не позволяющие дать оценку проекту и вообще быть уверенным, что все фантазии клиента и дизайнера получится воплотить в жизнь.
У технического проектирования есть три задачи:
У технического проектирования есть три задачи:
Почитать ещё:
Обратите внимание, что формально разработка еще не начинается, но разработчики уже могут подключаться для написания прототипов и отдельных частей архитектуры системы. Вообще выполнить полноценное техническое проектирование без участия разработчиков нельзя.
Верифицировать реализуемость требований к проект
Определить общую архитектуру систем
Сделать детальную проработку способа реализации каждого из компонентов системы
Техническое проектирование
Кто должен проектировать?
Кто же те волшебные люди, которые смогут выполнить всю описанную выше работу? На мой взгляд лучшими проектировщиками являются люди, у которых есть существенный практический опыт в том, что они проектируют.
Например, технический архитектор в прошлом должен быть достаточно сильным разработчиком с опытом работы и с разными технологиями и в разных проектах. Должна быть достаточная широта понимания задач.
Проектирование функций и интерфейсное проектирование – это пересечение знаний психологии поведения людей, дизайна, текущих тенденций в интерфейсах систем и опыт работы в отрасли клиента.
В то же время, практических знаний мало, нужна сложившаяся модель работы, методология поиска решений. Ведь проектирование – это процесс именно поиска решений в ситуации, когда много чего неизвестно.
Например, технический архитектор в прошлом должен быть достаточно сильным разработчиком с опытом работы и с разными технологиями и в разных проектах. Должна быть достаточная широта понимания задач.
Проектирование функций и интерфейсное проектирование – это пересечение знаний психологии поведения людей, дизайна, текущих тенденций в интерфейсах систем и опыт работы в отрасли клиента.
В то же время, практических знаний мало, нужна сложившаяся модель работы, методология поиска решений. Ведь проектирование – это процесс именно поиска решений в ситуации, когда много чего неизвестно.
Что дальше?
Как я уже написал в начале статьи, я хочу рассказать подробнее про организацию работы над проектом при использовании проектирования. Там обязательно будет история про использование методологий, типа того же Agile (Scrum) и теории ограничений Голдратта. Еще я запланировал подробнее рассказать про каждый шаг проектирования.