Рационализация проектирования: роль прототипов в веб-разработке Павел Горчев Руководитель аналитического отдела Агентства Интернет-Маркетинга AGIMA

« Порочный круг экономии » в web-разработке. 2

Качество – все! 3 «Единственный возможный источник экономического подъема – это повышение качества и, как следствие, привлекательности продукта или услуги. А повышения качества невозможно добиться, сокращая затраты на проектирование и программирование.» Алан Купер Основатель компании Cooper Interaction Design, автор нескольких книг о проектировании взаимодействия, пользовательских интерфейсах и юзабилити.

Креативно, но неэффективно... 4 Детальное проектирование и прототипирование в веб-разработке важны так же, как и в других отраслях.

Подходы к проектированию. 5 1.Проектная документация «для галочки»; 2.«Обычная» проектная документация текстового характера; 3.Детализированная документация с прототипами.

Кем выполняется проектирование в web-студиях? 6

Особенности подхода «для галочки» 7 Характерен для небольших и начинающих веб-студий; Предпроектный анализ отсутствует; ТЗ составляется только ради приложения к договору; Точный состав работ определить из ТЗ невозможно.

Причины проектирования «для галочки» 8 Экономия средств; Желание быстрее закрыть проект; Нехватка человеческих ресурсов; Желание сделать «по минимуму» и сдать; Надежда на личные отношения с Заказчиком.

Почему важно ПОДРОБНОЕ описание? 9 Реализация разработчика: Ожидания клиента:

Недостатки подхода «для галочки» 10 Если проект подробно не описан, заказчик может требовать по максимуму; Высок риск никогда не завершить проект; Качество итогового продукта под сомнением; Серьезный заказчик не будет сотрудничать без достойной документации; Себестоимость и сроки разработки проекта не поддаются адекватной оценке; Полная зависимость судьбы проекта от человеческого фактора.

«Типичная» проектная документация 11 Особенности В компании нет специалистов, занимающихся непосредственно проектированием; Единственное средство описания разрабатываемого решения – текстовое ТЗ; Итоговый документ трудно воспринимается; Полнота ТЗ часто вызывает сомнения; Заказчик редко вникает в ТЗ, чаще подписывает «не глядя».

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

«Типичная» проектная документация 13 Преимущества для разработчика Средняя по детализации документация может быть разработана сравнительно быстро; Необязательно требовать с заказчика отдельного бюджета на проектирование; Нет необходимости нанимать выделенного специалиста; Срок реализации проекта и себестоимость поддаются оценке; В конфликтных ситуациях существует возможность апеллировать к подписанной документации.

«Типичная» проектная документация 14 Недостатки для разработчика В большинстве случаев детализация ТЗ все же недостаточна для установления точного состава и объема работ; Существует разрыв между описанием функционала и интерфейсами. Дизайнеры вынуждены выполнять несвойственные им функции; Программисты и верстальщики вынуждены постоянно выяснять недостающие детали у менеджера или заказчика; … то что им удается выяснить в процессе, порой вызывает непредусмотренные работы и рост издержек.

Пример логического разрыва 15 Что реализовал разработчик в соответствии с ТЗ:

Возможная альтернатива

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

Прототип низкой детализации 18

Прототип низкой детализации 19

Прототип низкой детализации 20 Для первоначального согласования концепции с заказчиком; Для начального концептуального обсуждения внутри компании; Часто используется заказчиком для информирования исполнителя (для начальной постановки задачи на разработку). Когда применяется:

Прототип низкой детализации. 21 В проектной документации; Обычно нежелателен для демонстрации заказчику. Средства подготовки: Программы MS Office (лучше Visio); Бумага или доска; Некоторые онлайновые сервисы, такие как Balsamiq Mockups. Когда не применяется:

Фрагмент прототипа средней детализации. 22

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

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

Прототип высокой детализации 25 Пример прототипа высокой детализации

Прототип высокой детализации 26 Axure RP Pro и другие специализированные инструменты (с ограничениями). Adobe Photoshop, Fireworks Adobe Flash Adobe InDesign Средства подготовки:

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

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

Взаимодействие прототипа с ТЗ 29

Взаимодействие прототипа с ТЗ 30

Взаимодействие прототипа с ТЗ 31

Прототипирование помогает! 32 Качественный прототип является хорошим обоснованием стоимости проекта; Ускоряется процесс разработки сайта; Возрастает качество реализации продукта; Значительно улучшается взаимопонимание с Заказчиком.

СПАСИБО! 33

34 Павел Горчев Высшее экономическое образование. Преподаватель, автор учебных программ. Руководитель аналитического отдела Агентства Интернет-Маркетинга AGIMA. Руководил разработкой проектов для таких клиентов как: страховая компания «АльфаСтрахование», МДМ Банк, страховая компания «РОСНО», Федеральная Антимонопольная Служба РФ, издательский дом «Открытые системы» и др (495)