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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33. СПАСИБО! 33

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