Предыдущий ролик Следующий ролик  

Видео урок: Стандартная последовательность действий в работе дизайнера

Основы веб-дизайна

У каждого дизайнера и агентства есть своя любимая последовательность действий, выполняемых ими при создании собственного проекта. Последовательность действий - вещь поразительно индивидуальная, и то, что хорошо для одного, необязательно подходит другому. Поэтому в этом видео я поделюсь с вами своей личной последовательностью действий. Некоторым из вас она, возможно, понравится, а некоторые могут испытать к ней отвращение. Смысл в том, что таким образом вы получите исходную последовательность действий, которую впоследствии можно будет изменить и подогнать под собственные проекты и предпочтения. Большинство последовательностей можно разбить на 4 отдельных сегмента:

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

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

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

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

Саманта Уоррен создала прекрасный сайт, посвященный применению Style tiles и тому, какую пользу этот инструмент может принести, если использовать его при планировании дизайна сайтов. По сути, вы демонстрируете клиентам лишь элементы дизайна, а не макеты всего сайта. Таким образом вы избавляетесь от распространенной проблемы, когда клиенты привлекаются к процессу определения дизайна отдельной страницы, и вместо того, чтобы анализировать всю эстетику дизайна, им приходится отчасти выискивать недостатки. Недавно Брэд Фрост описал процесс атомного дизайна. Атомный дизайн подразумевает, что сначала выполняется дизайн отдельных компонентов, а затем эти компоненты объединяются в более крупные области страницы.

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

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

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

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

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

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

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