АНАТОЛИЙ ИВАНОВ / МЕТОДЫ / ПРОЦЕСС ДИЗАЙНА

И фото и дизайн проекты зависят от восприятия эстетики клиентом.

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

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

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

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

1 / ПРОЦЕСС ПОЛИГРАФИЧЕСКОГО ДИЗАЙНА

Процесс дизайна материалов для печати — относительно прост:

1.1 / Пролог

• Анатолий ИВАНОВ и клиент анализируют:
  • бизнес клиента
  • потребности клиента
  • индустрию клиента
• Анатолий ИВАНОВ и клиент определяют цели проекта.
• Анатолий ИВАНОВ и клиент просчитывают бюджет (создание и производство).

1.2 / Графический дизайн

Итерации:

• Анатолий ИВАНОВ создаёт графический дизайн
• Анатолий ИВАНОВ и клиент рассматривают и обдумывают дизайн

повторяются до достижения согласия… или до исчерпания сроков / бюджета. 😀

1.3 / Производство

• допечатная подготовка
• печать (офсетная или цифровая)
• пост-печать (резка, высечка, биговка, сгибание, переплёт)
• распределение и отправка

2 / ПРОЦЕСС ДИЗАЙНА ФИРМЕННОГО СТИЛЯ

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

3 / ПРОЦЕСС ВЕБ-ДИЗАЙНА

3.1 / Сложность и неизвестность

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

Всё «живёт» в интернете. Ценности, культура и история компании. Сухая, техническая документация соседствует с манифестами о том, как команда меняет мир. Нормально наличие разделов, посвящённых отношений с клиентами, инвесторами, сотрудниками, поставщиками и прессой. Даже ИП одного человека редко сводится к простой странице. Даже когда её называют SPA (одностраничным приложением).

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

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

И, конечно же, специфика интернета не отменяет традиционные вопросы дизайна. Что действительно нужно пользователям? Как дизайн решает реальные бизнес-задачи? Кто в компании из 500+ человек принимает эстетические решения за всех остальных? Как планировать и оценивать дизайн, неуловимый творческий процесс?

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

3.2 / Два способа справиться со сложностью и неизвестностью: предсказательный vs адаптивный

3.2.1 / Обычный подход: отрицание неизвестности с помощью детальных предсказаний

Естественная человеческая реакция на неопределенность — сделать прогноз, разработать план, а затем следовать ему шаг за шагом:

• Чтобы компенсировать неизвестность, менеджеры проектов разрабатывают чрезвычайно детальное Техническое Задание (ТЗ). 100 страниц этого документа определяет функции сайта, указывает график и выделяет фиксированный бюджет.
• Клиент утверждает это ТЗ.
• Графические дизайнеры используют ТЗ для создания внешнего вида сайта: неинтерактивные экраны будущих веб-страниц. Чаще всего, без конкретного понимания того, как это выразится в программном коде — «они же не компьютерщики!».
• Клиент утверждает дизайн.
• Программисты пишут код сайта: HTML и CSS; JavaScript и его множество библиотек и фреймворков (React, Vue, Svelte, HTMX); SSR с Node.js или даже старый добрый PHP; Markdown файлы, JSON API или SQL базы данных и т.д.
• После месяцев упорной работы клиент и конечные пользователи наконец-то могут попользоваться функционирующим сайтом. И только тогда, когда начинают поступать первые отзывы, клиент понимает, что некоторые функции нужно изменить, а некоторые добавить или удалить.
• Руководители проектов переписывают Техническое Задание. Дизайнеры корректируют дизайн. Программисты переделывают код.
• Но этого не достаточно. Клиент просит дополнительных изменений. Обратная связь от пользователей выявляет проблемы, о которых никто даже не подозревал. Требования продолжают меняться.
• С каждым новым изменением конечный результат всё дальше отходит от первоначального документа ТЗ. Проект задерживается, и бюджет взрывается.
• Летят обвинения, появляются боль и обида. Не самая приятная ситуация. Но, к сожалению, очень распространённая в индустрии веб-дизайна и разработки программного обеспечения.

3.2.2 / Мой подход: принимать неизвестность — адаптивностью

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

• Я не создаю детальное Техническое Задание.
• Я переношу графический дизайн на более поздний этап в работе над проектом.
• Я начинаю с функционального прототипа сайта, с которым удобно играть и экспериментировать, предоставляя его конечным пользователям, слушая их отзывы на самых ранних этапах, чтобы узнать, какие идеи стоит развивать, а какие — отбросить.
• Никакой письменный документ не ограничивает креативность команды клиент-дизайнер-пользователь.
• Гибкая, автоматизированная система подсчёта стоимости позволяет клиенту решать, какие функции реализовывать.

Результаты:

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

3.3 / Как это работает?

Мой процесс веб-дизайна проходит через 2 системы:

1. макро-уровень: этапы проекта
   (чёрные полосы на примере графика проекта диаграммы Ганта ниже)
2. микро-уровень: задачи проекта
   (синие, оранжевые и зелёные полосы на примере графика проекта диаграммы Ганта ниже)

Примечание: подробное объяснение диаграммы Ганта следует после графика.

3.3.1 / Этапы проекта

3.3.1.1 / Пролог

Во время этапа пролога мы:

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

3.3.1.2 / Интерактивный сценарий

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

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

Результаты:

• Конкретный, детальный сайт, который сосредотачивается на функционале, контенте и навигации.
• Так как интерактивный сценарий сайта не содержит графического дизайна, он остаётся очень податливым, простым HTML-ом. Я могу быстро и просто менять его содержание, перемещать страницы, добавлять ссылки и т.д.
• Интерактивный сценарий позволяет нам тестировать сайт на конечных пользователях и реагировать на их отзывы на самом раннем этапе процесса, используя знакомые им мобильные или десктоп браузеры.
• Интерактивный сценарий идеально адаптируется к интенсивному сотрудничеству и располагает к итеративной работе с максимальной гибкостью.

3.3.1.3 / Графический дизайн

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

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

  Пример: сайт состоит из 30 страниц, но требует только 3 шаблона:

  1. шаблон «главной» страницы (например, первая страница, которой открывается адрес сайт, на трёх языках)
  2. шаблон категорий (например, страница «услуги», «о нас»…)
  3. шаблон детализации (например, страница с описанием товара)

  Содержание каждой из 30 страниц меняется, но 3 дизайна остаются одинаковыми. Результат: визуальная консистентность, идентификация бренда и понятная навигация.

• Этап графического дизайна сосредоточен на создании шаблонов страниц.
• Предыдущий этап — интерактивный сценарий — устраняет основные неизвестные и помогает процессу дизайна:
  • Мы можем решить, сколько шаблонов страниц нам нужно, потому что к этому моменту мы создали весь контент и информационную архитектуру. Иными словами: содержание и информационная архитектура выявляют необходимые типы страниц.
  • Мы можем сосредоточиться на эстетике веб-сайта, улучшая его эргономику, потому что интерактивный сценарий определил особенности и функционал всех разделов сайта.
  • Мы точно знаем, как графический дизайн должен работать с контентом, потому что определили тип и длину текстов, а также количество необходимых фотографий и иллюстраций.
  • Клиент часто обнаруживает необходимость в дополнительных фотографиях, видео и текстах и выделил время на их создание — будь то с помощью внутренних ресурсов, либо задействовав мои всесторонние навыки (как режиссера, фотографа, копирайтера…), или же после привлечение дополнительных профессионалов к проекту.
• Я показываю графический дизайн в виде «сплющенных экранов»: точных JPEG копий каждого шаблона страницы, заполненных типичным контентом или, для более технически подкованных клиентов, экранов Figma. «Сплющенные экраны» показывают все навигационные элементы, тексты, фотографии, формы и т.д., как они будут выглядеть для посетителя сайта. Конечно, «сплющенные экраны» не включают весь диапазон кликабельных гиперссылок или любых других продвинутых интерактивных функций, но поскольку мы уже определили эти детали на этапе интерактивного сценария, мы можем пользоваться ими для более эффективный способ работы над графическим дизайном:
  • Гораздо легче формировать шаблоны страниц в Фигме или Иллюстраторе и сохранять их как JPEGи. Я могу быстро реагировать на отзывы клиентов и конечных пользователей и вносить изменения в графический дизайн по мере необходимости.
  • Для сравнения, технология создания полностью интерактивных страниц HTML / CSS / JavaScript сочетает программирование (на всех вышеперечисленных языках), лицензирование шрифтов, позиционирование графики и оптимизацию изображений. Следовательно, любые изменения в них требуют – опять — весь набор трудоёмких модификаций в коде, исходных графиках и повторных переговоров о лицензировании шрифтов / иллюстраций.

Результаты:

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

3.3.1.4 / Техническая реализация

На этапе технической реализации я объединяю графический дизайн с интерактивным сценарием.

• Я повторно использую HTML-код этапа интерактивного сценария и добавляю «сплющенные экраны» этапа графического дизайна для создания смеси:
  • изображений, оптимизированных для интернета
  • кода HTML
  • кода CSS
• В зависимости от сайта, я добавляю интерактивности на «клиентской стороне» (технически говоря, в браузере посетителя или фронтенде):
  • JavaScript
  • WebAssembly / Canvas / Web Components
• Для большинства веб-сайтов я генерирую значительную часть изображений, HTML, CSS и JavaScript на «серверной стороне» с использованием PHP, Node.js, какого-то варианта базы данных SQL, а также правил переписывания, маршрутизации, кэширования и балансировки нагрузки Nginx.
• Конечно, я могу подстроиться под любой технологической стэк, который уже использует ваша организация — это может быть React SPA или система Shopify — предлагая свои возможные улучшения. В любом случае, выбор технологий служит в первую очередь посетителям сайта. Да, DX (опыт разработчика) — важен, но UX (опыт пользователя) — ещё важнее.
• И да, я и дизайнер, и фотограф, и… программист, который пишет и «деплоит» свой код, фронт и бэк-энда (полного стека), один или с командой… как можно ближе к минималистским, «ванильным» принципам, настолько, насколько это позволяет проект. Я выступаю за технологическое долголетие, Непрерывную поставку, точные коммиты, строгое типирование, тщательное тестирование и чёткую документацию. С моих первых строк Паскаля в возрасте 9 лет, в 1989, я просто люблю программировать. 35 лет «зачем делать вручную то, что можно решить алгоритмично…» и другие приключения с IT, которые часто влияют на мои дизайнерские придумки. 😂

Результаты:

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

3.3.2 / Задачи проекта

Задачи проекта подразделяют этапы проекта на менее громоздкие блоки работы и продолжительности.

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

Она основывается на 5 концепциях:

3.3.2.1 / Человеко-дни

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

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

3.3.2.2 / Типы задач

Все задачи проекта делятся на 3 категории:

3.3.2.2.1 / Административные задачи

• Голубые полосы на примере диаграммы Ганта типового проекта выше.
• Примеры: подписания, платежи.
• Я не учитываю продолжительность административных задач как мои человеко-дни.

3.3.2.2.2 / Мои задачи

• Оранжевые полосы на примере диаграммы Ганта типового проекта выше.
• Примеры: создание графического дизайна.
• Я работаю над этими задачами один.
• Я учитываю 100% продолжительности этих задач как мои человеко-дни.

3.3.2.2.3 / Совместные задачи

• Зелёные полосы на примере диаграммы Ганта типового проекта выше.
• Примеры: совместная работа над интерактивным сценарием.
• Клиент и я работаем вместе над этими задачами, либо одновременно (встречи, мозговые штурмы), либо асинхронно (редакция, добавления, изменения… сначала от клиента, а затем от меня).
• В среднем, я учитываю 40% продолжительности этих задач как человеко-дни клиента и 60% продолжительности как мои человеко-дни.

3.3.2.3 / Изменение продолжительности задач — влияния на качество и стоимость сайта

3.3.2.3.1 / Мои задачи

• Продолжительность моих задач остаётся фиксированной в течение проекта (оранжевые полосы).
• Мои задачи формируют ядро проекта. Они создают основу для совместной работы, которая следует.
• Я рассчитываю абсолютный минимум человеко-дней, необходимых для их выполнения.
• До начала проекта:
  • Клиент может попросить уменьшить количество человеко-дней, выделенных на мои задачи, но рискует сильно снизить качество сайта.
  • Клиент также может попросить увеличить количество человеко-дней, выделенных на мои задачи, если предпочитает инвестировать в премиальное качество сайта.

3.3.2.3.2 / Совместные задачи

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

3.3.2.3.3 / Экстремальные бюджеты

На 2 бюджетных крайностях клиент может получить:

1. Минимальный бюджет:
   • Веб-сайт, разработанный мной без какого-либо вмешательства клиента.
   • Исключительно мои задачи (оранжевые).
   • Клиенту либо нравится, либо не нравится мой дизайн.
2. Максимальный бюджет:
   • Веб-сайт, создание которого занимает много времени с частыми изменениями, запрашиваемыми клиентом.
   • Только совместные задачи (зеленые).
   • Конечный результат - сайт, который удовлетворяет клиента на 300%.

3.3.2.3.4 / Средний бюджет

Более разумный подход лежит где-то между этими двумя крайностями.

3.3.2.4 / Пакет дней – фиксированное ценовое обязательство

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

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

Поскольку мы ведём переговоры, используя подход выигрыш / выигрыш, никто не обязан соглашаться на первый вариант сметы. Мы остаёмся открытыми и находим баланс между:

• вашими потребностями (функции сайта)
• моими временными требованиями для создания сайта, который отвечает вашим потребностям (пропускная способность и продолжительность)
• вашим бюджетом (стоимость сайта)

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

После того как мы находим оптимальное общее количество человеко-дней, я беру на себя обязательство по пакету дней - фиксированной цене / фиксированному количеству человеко-дней:

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

3.3.2.5 / За гранью пакета дней

3.3.2.5.1 / Что происходит, если клиент требует больше времени, чем мы запланировали в пакете дней?

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

За пределом пакета дней (фиксированная цена / фиксированное количество человеко-дней), я применяю свою дневную ставку, использованную для пакета дней:

• Проект с более длительным пакетом дней — соответственно, большей скидкой — будет с более низкой посуточной ставкой.
• Проект с более коротким пакетом дней — следовательно, с меньшей скидкой — будет с более высокой посуточной ставкой.
• Фактически, может оказаться дешевле договориться о более продолжительном пакете дней (фиксированная цена / фиксированное количество человеко-дней), чем о коротком и затем оплачивать все дополнительные дни по более высокой цене.
• Я сообщаю об использовании дополнительных человеко-дней еженедельно, используя как диаграмму Ганта, так и лист ресурсов.
• Я выставляю счет за дополнительные человеко-дни в конце каждого из 3 этапов проекта.

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

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

3.3.2.5.2 / Что происходит, если проект занимает меньше времени, чем мы запланировали в пакете дней?

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

3.3.3 / Аварийные выходы

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

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

Поэтому в моём процессе веб-дизайна предусмотрены встроенные аварийные выходы:

3.3.3.1 / Постепенная оплата

Вы платите по мере продвижения, в конце / начале каждого этапа проекта.

3.3.3.2 / Отказ и прекращение

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

В таком случае все предыдущие платежи останутся навсегда приобретенными Анатолием ИВАНОВЫМ, но никакие другие платежи, например, за не начатые этапы, запрашиваться не будут.

3.3.3.3 / Возможность повторного использования

Если вы хотите повторно использовать работу, проделанную до этого момента, я с удовольствием лицензирую вам права на использование, если:

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

3.4 / Сложный ответ на сложную проблему?

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

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

В реальности, удивительно, насколько этот процесс кажется легким в применении, естественным по ощущениям и доверительным как для клиента, так и для меня.

Более того, мы всегда знаем, где находится проект и сколько он стоит.

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

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

4 / ДОПОЛНИТЕЛЬНЫЕ ВОПРОСЫ?

Я всегда рад ответить на ваши вопросы и обсудить детали моих дизайн-процессов: свяжитесь со мной.

СЛЕДУЮЩЕЕ : АНАТОЛИЙ ИВАНОВ / МЕТОДЫ / ГЕОГРАФИЧЕСКИЙ ОХВАТ