'

Рационализация проектирования: роль прототипов в веб-разработке

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

Возможная альтернатива 16 1. 2. 3.


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

СПАСИБО! 33


Слайд 33

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


×

HTML:





Ссылка: