Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 12 384 веб-студии, 939 CMS, 223 615 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Прктрвнье, «проектирование» и проектирование

Проектирование — это не прототип накалякать.

Проектирование вошло в моду, его делают уже в каждой подворотне. Статьи по UX, UI и Usability прочитаны от хедера до футера. Хорошо? Хорошо.

Только вот называют этим словом слишком разные вещи со слишком разным результатом. Есть ощущение, что у 99% специалистов и заказчиков проектирование ограничивается ТЗ на страничку (иначе — «брифом») и прототипом. Нехорошо.

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

Часть работ

прктрвнье

«проектирование»

Проектирование

Сбор и анализ информации

ТЗ от заказчика (все знаю, что это такое, да?) + 10 простых вопросов вроде «Пришлите каталог с описанием товара».

ТЗ от заказчика + аж 20 вопросов чуть посложнее.

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

Персонажи и сценарии

«Мужчина 20-60 лет. Нужно оборудование.»

«Сергей, 25-50 лет, старший инженер, любит маму, рыбалку и природу. Поручили выбрать оборудование для снижения расходов на топливо.»

Подробное описание: стимулы, мотивы, задачи, вопросы, сомнения, барьеры, откуда и зачем придёт, какой есть опыт и знания, ожидания и критерии оценки, особенности взаимодействия... Вот небольшой кусочек описания персонажа: https://yadi.sk/i/9f4Qkr1FehfVg, специально без лица и общей информации.

Концепция

Идеи, которые ложатся в основу всего: структуры, содержания, взаимодействия с пользователями.

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

Структура и содержание

Список разделов и меню.

Меню, список разделов и страниц с кратким содержанием.

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

Взаимодействие с пользователями

«Покажем посетителю, что заявка отправлена. Наверное, нужно ещё подтверждение на почту прислать.»

Проработанные и описанные процессы обработки информации и взаимодействия с пользователями в разных ситуациях: например, в каких случаях и как предлагается консультация, как проходит, сохраняется и анализируется, как начинается и подтверждается запись на тест-драйв или бронирование номера, кто за что отвечает в это процессе. И снова для примера кусочек такого описания: https://yadi.sk/i/g3hKz2bxepMGW, https://yadi.sk/i/x0mbch5QepMLr.

Прототип

Наскоро собранный из типовых элементов, без описания.

Нормально собранный, но обычно без описания. «Да там всё понятно».

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

Управление

«Поможем выбрать CMS.»

«Поможем выбрать и, наверное, настроить CMS.»

Продуманное управление содержанием и процессами, с учётом роли и прав каждого пользователя.

Советы по выбору CMS или даже специально спроектированная система управления со своими персонажами, сценариями, процессами.

Структура данных

Описание каждого вида данных: поля, свойства и связи.

Проектное задание

«ТЗ заказчика — это разве не оно?»

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

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

Контроль разработки

«Сами разберутся.»

«Ответим на вопросы.»

«Поясним все документы, поможем построить процесс [разработки и контроля], проверим результат.»

Подготовка содержания

«Контентом мы не занимаемся.» или «Наш seo-копирайтер всё сделает!». Второе хуже.

«В прототипе всё показано.»

Советы по каждому типу содержания: задачи, состав, размер, стиль; постановка задачи [копирайтеру или дизайнеру] и проверка результатов.

Тестирование

«Проверим, что там программисты сделали»

Тестирование на настоящих пользователях с настоящим содержанием по настоящим сценариям + выводы, что и как нужно улучшить.

Что нужно от заказчика

Мм, всё, кроме самого прототипа — придумать структуру и содержание, сказать, что требуется от системы управления...

Тут уже получше: «проектировщик» не только спрашивает, но и предлагает решения.

Активно помогать при сборе информации — ответить на вопросы по бизнесу, предоставить материалы, организовать интервью с клиентами — и согласовывать результаты. Всё остальное делает проектировщик.

Да, заказчик здесь тратит довольно много времени, но, что важно, решения принимает и защищает тот, кто и должен — проектировщик.

Результат

Не очень продуманный и частенько оторванный от реальности прототип.

И больше ничего. Голая внешняя часть сайта.

Симпатичный прототип с каким-то описанием логики работы и иногда советами по содержанию.

Здесь вырисовывается хоть какая-то система.

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

Простыми словами: продуманная система, которая нацелена на пользователей и ваши задачи, а не собрана из кусочков мнений, примеров сайтов и «модных» решений.

 

И несколько мыслей напоследок.

Контроль и тестирование?

Мне возразят — и ведь возражают, — что это уже не работа проектировщика. А чья? Кто лучше него проверит и увидит ошибки, скажет, как их исправить? Есть такое понятие — «авторский надзор». При разработке сайтов/информационных систем он просто необходим, иначе разработчики и заказчик сделают что-то своё, часто далёкое от проекта и потому плохо работающее.

Важна системность

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

Например, недавно мне показали симпатичный интерфейс сервиса для обмена валют. Всё в нём хорошо — цвета, формы, вёрстка, учтены особенности разных валют, — только вот бизнес-процесс подвёл. Сервис предлагает посетителю ввести сумму и выбрать валюту, которую он хочет получить, и подтвердить перевод. С его счёта списывают деньги и..., если сумма превышает 1 000 долларов, требуют авторизации и подтверждения личности с помощью скана паспорта. Эээ... Почему мне не сказали об этом, когда я вводил сумму? И тут самое весёлое: после проверки перевод может быть отклонён, а возврат осуществляется по правилам платёжной системы, т.е. в ряде случаев — до 30 дней. Как вам?

Почему пока что проектирование = прототип?

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

Если проектировать без серьёзного сбора и анализа информации и всего перечисленного, получится дикая смесь пожеланий заказчика и шаблонов в голове прктрвщка вроде «Как же без баннера с прокруткой на главной странице!».

Проектирование не заканчивается на прототипе, а только начинается.

Докажи!

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

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

Автор: Александр Туник, Проектная студия «Тектоника» (Руководитель и проектировщик)

Комментарии (Facebook)

Рекомендуем:


CMS Magazine CMS Magazine
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine