Проектирование сайта веб-студии ДСТ Глобал

Интересно а почему дизайнеры вообще стали использовать прототипы? Раньше делали ведь просто дизайн и дальше разработку, UI/UX и прототипирование появилось сравнительно недавно если я не ошибаюсь

В разработке сайта прототипирование — это этап, который следует за исследованием, перед созданием дизайна.

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

И конечно самое главное — хорошо, продуманно составленный прототип является полноценным каркасом сайта, на который потом легко «надевается» дизайн.

Проектирование — этот, возможно, ключевой этап создания интернет-сайта, отвечает нам на следующие вопросы:

— Каковы наши цели — зачем мы делаем сайт? Как мы реализуем поставленные цели?
— Как сайт будет выглядеть и работать?

О пользе проектирования

Проектирование даёт сайту очень много:

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

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

Исключение, пожалуй, составляют недорогие сайты — с бюджетом 5-15 тысяч рублей — где проектирование становится нерентабельным, увы.

Как проектировать сайт

Проектирование можно условно разбить на четыре основные части:

— Целеполагание,
— Исследование контекста,
— Создание концепции,
— Моделирование.

Целеполагание

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

В будущем они же помогают оценить успешность проекта.

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

Исследование контекста

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

— Целевая аудитория и её потребности,
— Характеристика и тенденции области,
— Конкуренты и их деятельность,
— Опыт других проектов,
— Законодательные или иные ограничения,
— Другие факторы влияния, в зависимости от тематики проекта.

Польза исследования контекста

Контекст проекта помогает нам понять целевую аудиторию и то, каким нужно сделать сайт: как его позиционировать, какая информация на нём должна быть и на каком языке он должен говорить с ЦА (это называют коммуникативной стратегией), как он будет отличаться от конкурентов (естественно, в выгодную сторону).

Кроме того, исследование погружает команду проекта в тему, позволяет где-то даже на подсознательном уровне видеть/принимать правильные решения.

Лучше всего, конечно, исследование помогает понять аудиторию:

— Как с ней общаться: какие слова использовать в «разговоре» с ней, как называть свой продукт или услугу (возможно, нужно использовать профессиональный сленг, или наоборот, нарочито упрощённую терминологию), обращаться ли к ней на «вы» или на «ты».
— Каковы её потребности: что приоритетно, что необязательно, но желаемо, что нельзя делать ни в коем случае.

Где брать данные

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

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

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

Предвижу комментарии: дескать, самостоятельное исследование рядом не стояло с профессиональными маркетинговыми исследованиями — так зачем тратить время и ресурсы? На то есть несколько причин:

— Без данных о контексте ваши шансы сделать хорошо пользователю стремятся к нулю.
— Даже самостоятельное исследование даёт полезную информацию, пусть и в меньшем объёме, нежели профессиональное.
— И даже если вы настолько неумело проводите исследование (что маловероятно), что не можете получить ответы на вышеобозначенные вопросы, вы всё равно погружатаетесь в контекст проекта и хотя бы подсознательно улавливаете что-то полезное.

Могу сказать по собственному опыту: нам исследование помогало всегда, в любом проекте.

Создание концепции сайта

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

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

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

Моделирование сайта

Моделирование — это создание модели сайта, которая описывает функциональные возможности и информационную структуру.

Функциональная часть модели

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

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

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

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

— Задачи — какие из ранее поставленных задач решает раздел. Например, раздел «Фотографии» в социальной сети решает задачу обмена информацией между друзьями и последующего общения;
— Сообщения — это в буквальном смысле сообщения, которые раздел или его часть передаёт посетителю. Например, сообщение приветствия «Привет, ты на портале ХХХ! Мы рады видеть тебя здесь» или «Эй, это наш лучший товар — попробуй, закажи сейчас и убедись в этом сам!».
— Сообщения бывают разных типов; наиболее часто встречающиеся: рекламные, призывы к действию, уведомления и имиджевые сообщения.
— Функциональные элементы — элементы интерфейса, дающие возможность посетителю выполнить какую-то операцию. Например, функциональным элементом является форма для ввода сообщения, позволяющая отправить сообщение, или кнопка в интерфейсе, сохраняющая сделанные изменения.
— Варианты поведения посетителя — предположения о том, что посетитель сайта может или должен сделать после изучения интерфейса или отдельных его частей.

Мы обычно делаем такие схемы в виде mind maps — очень удобно, надо сказать.

Резюме

Как обычно, краткие выводы:

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

P.S.: Статья эта, очевидно, обзорная, для затравки, поскольку тему проектирования раскрыть в одной статье нереально. Практически любая мысль из этой статьи была неоднократно подтверждена нашим личным опытом, и обо всём мы расскажем позже, подробнее и с примерами.

Стоит добавить, что если клиент планирует в будущем продвигать свой сайт (SEO), то необходимо и это учитывать при проектировании. Как минимум предусмотреть оптимальные точки входа (страницы) по основным группам запросов.

В целом из статьи ничего нового не узнала. Очевидные вещи для разработчика с головой.

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

Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.

Конечно, любое продвижение учитывается в задачах.

Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…

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

Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.

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

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

Например, есть у вас задача сделать агрегатор объявлений по продаже автомобилей. С поиском, отзывами, импортом/экспортом объявлений и прочими клевыми штуками.
Можно указать в ТЗ, что одна из характеристик авто — объем двигателя. Потом разобраться глубже и узнать, что на разных сайтах люди указывают данную характеристику по-разному: где-то в литрах, где-то в кубических сантиметрах. Изучаем дальше — выясняем, что привычнее для людей искать именно по литрам, то есть необходимо будет конвертировать для одних объявлений и оставлять как есть для других.
Стоит ли углубятся в такие детали сразу при проектировании или решать их уже в процессе?

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

Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.

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

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