Комментарии 33
М-да. А где комменты?.. :)
Вопрос к автору,
Сегодня как раз сдал свой первый полный прототип, речь идет о wireframe-модели.
В случае нашего проекта именно эта модель вместе с концепцией отправится к дизайнерам, которые будут заниматься визуализацией.
А если делать прототип на основе готового дизайна - получается что на дизайнера ложится ответственность за проектирование интерфеса?
И при отработке функциональности, вы учитываете все возможные сценарии? Или только основные?
Сегодня как раз сдал свой первый полный прототип, речь идет о wireframe-модели.
В случае нашего проекта именно эта модель вместе с концепцией отправится к дизайнерам, которые будут заниматься визуализацией.
А если делать прототип на основе готового дизайна - получается что на дизайнера ложится ответственность за проектирование интерфеса?
И при отработке функциональности, вы учитываете все возможные сценарии? Или только основные?
Да нет, в случае готового дизайна просто добавляется еще один шаг. Получается цепочка wireframes -> дизайн -> HTML-прототип. В зависимости от бюджета и ресурсов можно ее удлинять или укорачивать.
В прототипе учитываем только основные сценарии плюс вспомогательные, без которых основные не будут целостными. Если делать в прототипе все — выйдет чересчур накладно :) Хотя в компании EPAM, где я до этого работал, мы обычно делали все сценарии, до мелочей — но там и прототип был основной для разработчиков, а не просто быстрой демонстрацией. Да и проекты дорогие и долгосрочные, так что это было оправдано.
В прототипе учитываем только основные сценарии плюс вспомогательные, без которых основные не будут целостными. Если делать в прототипе все — выйдет чересчур накладно :) Хотя в компании EPAM, где я до этого работал, мы обычно делали все сценарии, до мелочей — но там и прототип был основной для разработчиков, а не просто быстрой демонстрацией. Да и проекты дорогие и долгосрочные, так что это было оправдано.
а кто-нибудь может конкретно вынести положительные стороны прототипирования для всего проекта в целом или каких-то его отдельных частей? на сколько уменьшается время на разработку?
у меня создалось такое впечатление, что по сути, можно достаточно серьезно разгрузить разработчиков и избежать множество юзабилити проблем о которых в будущем сообщат заказчики или тестировщики, если создавать прототипы, тем самым можно сэкономить определенное время на разработке средних проектов, возможно до 15-30%?
в общем, пока без оснований, но я надеюсь получить следующие результаты от полноценного интерактивного прототипирования:
1. экономия времени разработки 15-30% (средние разработчики)
2. экономия времени на создании тест-кейсов тестировщиками
3. более качественный проект в плане юзабилити
4. проще тестирование - воможность сравнивать многие вещи живой системы с интерактивным прототипом
5. возможность считать клики, и показывать варианты задолго до конечной реализации проекта, и дешевле чем реализации реальной функциональности
6. экономия времени на общении с разработчиками - при качественной спецификации проекта, хорошо продуманной архитектуре и еще интерактивных прототипах - у разработчиков возникнет значительно меньше вопросов (по крайней мере когда они привыкнут так работать).
т.е. в результате я расчитываю получить меньшее время на разработку проекта в целом, более довольного заказчика и более качественный продукт.
это похоже на правду? или это только мечты? :)
у меня создалось такое впечатление, что по сути, можно достаточно серьезно разгрузить разработчиков и избежать множество юзабилити проблем о которых в будущем сообщат заказчики или тестировщики, если создавать прототипы, тем самым можно сэкономить определенное время на разработке средних проектов, возможно до 15-30%?
в общем, пока без оснований, но я надеюсь получить следующие результаты от полноценного интерактивного прототипирования:
1. экономия времени разработки 15-30% (средние разработчики)
2. экономия времени на создании тест-кейсов тестировщиками
3. более качественный проект в плане юзабилити
4. проще тестирование - воможность сравнивать многие вещи живой системы с интерактивным прототипом
5. возможность считать клики, и показывать варианты задолго до конечной реализации проекта, и дешевле чем реализации реальной функциональности
6. экономия времени на общении с разработчиками - при качественной спецификации проекта, хорошо продуманной архитектуре и еще интерактивных прототипах - у разработчиков возникнет значительно меньше вопросов (по крайней мере когда они привыкнут так работать).
т.е. в результате я расчитываю получить меньшее время на разработку проекта в целом, более довольного заказчика и более качественный продукт.
это похоже на правду? или это только мечты? :)
У нас (UIDesign Group) было несколько ярких примеров экономии времени для заказчика. В одном из таких проектов мы делали ПИ для сложного рабочего места (урегулирование страховых случаев). У разработчиков было очень мало времени на завершение проекта. Мы на основе работы бизнес-аналитиками заказчика сделали прототип - получилось более 20ти экранов. Ведущий разработчик посмотрел на это и сказал, что к сроку все это реализовать не успеет. Мы снова сели с аналитиками и выкинули массу функционала из системы. Получилось 12 экранов. Проект был сдан в срок. Уверен, что если бы нас не было, и разработчики нижнего уровня в паре с аналитиками начали реализовать систему, то у них не было бы целостной картины (времени просто не хватило бы расписать все Use Cases) и проект бы они запороли.
Я первую часть статьи посвятил перечислению выгод от прототипирования. Точно подсчитать экономию времени на разработке невозможно. Хотя можно прикинуть риски ошибиться, если не все проработано перед тем как делать — обычно это зависит от количества, сложности и взаимозавязанности бизнес-логики. Если ее много — шансы что где-то работа пойдет не туда очень большие. Либо если запускается важный для компании продукт, где нужно выстрелить точно с первого раза — в случае большой конкуренции или если первое неудачное впечатление не даст шанса на второе.
Экономия на разработке точно есть, есть разные цифры и формулы, но все зависит от конкретного случая. Поэтому можно и 15%, а можно и 50% сэкономить. Есть отличная статья на сайте Usability Professionals Association про подсчет ROI от юзабилити — многие статьи о выгоде юзабилити берут данные именно оттуда.
По пунктам все так :) При желании можно расписать и больше, но тут есть все наиболее важные.
Экономия на разработке точно есть, есть разные цифры и формулы, но все зависит от конкретного случая. Поэтому можно и 15%, а можно и 50% сэкономить. Есть отличная статья на сайте Usability Professionals Association про подсчет ROI от юзабилити — многие статьи о выгоде юзабилити берут данные именно оттуда.
По пунктам все так :) При желании можно расписать и больше, но тут есть все наиболее важные.
На данный момент пользуюсь Axure RP. Ms Visio не пользовался. Чем он интерснее? Какие плюсы, минусы? Что посоветуете? Вообще-то, назревает потребность в отдельной теме о программах для прототипирования:) Никто не хочет взятся?
P.S. Предоставлять прототип для заказчика, по-моему, неплохая идея. Еще лучше попросить заказчика предоставить прототип желаемого сайта. Программа до того проста и удобна, что ею сможет пользоваться даже 12-ти летний ребёнок. К тому же требования изменить, внести некоторые поправки обычно обусловлены тем, что заказчик обычно хочет получить самый красивый сайт (лучше чем у конкурента), а потом когда надоедает затянувшийся процесс разработки соглашается на то что уже сделано.
Без прототипирования (черно-белого), сотрудничество между заказчиком и разработчиком можно назвать "сделай сайт - удиви меня". Если заказчик сначала сделает прототип, а потом уже разработчик поверх этого сделает ответный эффект будет лучше! ИМХО, проверено!
P.S. Предоставлять прототип для заказчика, по-моему, неплохая идея. Еще лучше попросить заказчика предоставить прототип желаемого сайта. Программа до того проста и удобна, что ею сможет пользоваться даже 12-ти летний ребёнок. К тому же требования изменить, внести некоторые поправки обычно обусловлены тем, что заказчик обычно хочет получить самый красивый сайт (лучше чем у конкурента), а потом когда надоедает затянувшийся процесс разработки соглашается на то что уже сделано.
Без прототипирования (черно-белого), сотрудничество между заказчиком и разработчиком можно назвать "сделай сайт - удиви меня". Если заказчик сначала сделает прототип, а потом уже разработчик поверх этого сделает ответный эффект будет лучше! ИМХО, проверено!
Не встречал таких заказчиков, которые с энтузиазмом бы отнеслись к тому, что им надо нарисовать прототип....
Все, с которыми я работал, сказали бы: А за что, простите я вам плачу???
А вот на счёт темы "о программах для прототипирования" - это было бы очень интересно и актуально...жаль, я совсем не компетентен в этой области...
Все, с которыми я работал, сказали бы: А за что, простите я вам плачу???
А вот на счёт темы "о программах для прототипирования" - это было бы очень интересно и актуально...жаль, я совсем не компетентен в этой области...
Как это за что!? Значит плохо формулируете пользу прототипированияю
Ты видимо торопился, или просто суетной....
Заказчики бы спросили: А за что, простите, я вам плачу???, если бы я им сказал - рисуйте ПИ сами!
Заказчики бы спросили: А за что, простите, я вам плачу???, если бы я им сказал - рисуйте ПИ сами!
А к вам заказчик приходит с уже спроектированной системой?
Наверное, заказчики у вас пока еще не готовы к нормальной модели разработки до этого дорасти надо :)
Да, на тему убеждения есть перевод отличной статьи:
http://fresh.gui.ru/2007/12/06/usability…
По себе могу сказать, что на задачи связанные с убеждением заказчика или его представителей я трачу до трети своего рабочего времени.
http://fresh.gui.ru/2007/12/06/usability…
По себе могу сказать, что на задачи связанные с убеждением заказчика или его представителей я трачу до трети своего рабочего времени.
Значит пока не повезло :) На этом и в самом деле очень многие экономят, но вполне можно убедить на примерах, что польза есть. Хотя, конечно, и не всех.
Конечно не стоит пихать подобное предложение всем заказчикам подряд. Бывают и исключения (заказ большого проекта, компетентность заказчика в сфере разработки сайтов). Но в большинстве своём заказчик не знает что ему нужно. Сегодня разработчики делают акцент на предоставлении ТЗ! У этого решения есть свои минусы: не все любят писать, не знают как написать ТЗ, ТЗ составленное заказчиком не отображает желаемую модель - такое тоже случается :))(написал, но это не то, что ему нужно:)) На Axure, например, они с удовольствием и легкостью сделают прототип. Важно даже чтобы попытались, тут именно важно чтобы они потратили на это 2-3 часа своего времени. Дальше я могу предсказать с какими трудностями они столкнутся: перенести этот блок туда, а может лучше сюда, всё же лучше наоборот. Вася, как лучше сделать? И вот тут появляется компетентный человек: расставляет все точки над i, объясняет что этот блок туда лучше не ставить по причине ... здесь идёт объяснение законов УИ дизайна и эффект обеспечен.
Надеюсь понимаете что я имел ввиду. Писать нет времени :((
Вообще, лучше изначально включать в прайс-лист скидку на случай составленного прототипа. Это хороший стимул для составления прототипа.
Надеюсь понимаете что я имел ввиду. Писать нет времени :((
Вообще, лучше изначально включать в прайс-лист скидку на случай составленного прототипа. Это хороший стимул для составления прототипа.
Тут зависит от того, что нужно получить в итоге. Если просто смоделировать идеи для не очень крупной системы — подойдет Axure. Я в Axure сделал для интереса один несложный проект и понял, что не мое — он не очень гибкий и для сложных проектов не подойдет. Visio хорош, когда идет работа над сложной системой с множеством нетиповых решений, где проектирование является частью документации и нужны детальные схемы всех страниц.
Но Axure, конечно, здорово помогает неспециализирующимся на проектировании компаниям. Я описал в статье случай, когда к нам пришел заказчик и у него уже были подробные наброски системы в Axure. И нам помогло понять, что же они хотят, и им самим — понять и детально описать, как должны работать с системой разные группы пользователей.
Но Axure, конечно, здорово помогает неспециализирующимся на проектировании компаниям. Я описал в статье случай, когда к нам пришел заказчик и у него уже были подробные наброски системы в Axure. И нам помогло понять, что же они хотят, и им самим — понять и детально описать, как должны работать с системой разные группы пользователей.
Зачем же вы так об Axure. Этот продукт появился совсем не давно и развивается достаточно быстро. Основной плюс Аксуры - это возможность реализовать динамические элементы. Тем самым это скорее не инструмент чистого прототипирования, это скорее нечто среднее между прототипированием и созданием интерактивного прототипа. Причем среднее - в связи с пока еще ограниченными возможностями самой Axure :) Впрочем в недавно вышедшей версии 4.6 добавлены новые возможности. Надеюсь в ближайшем будущем добавятся действительно недостающие функции :)
Например, что вы делаете когда необходимо отрисовать несколько состояний блока для ввода логина и пароля? Мне кажется, вы несколько раз отрисовываете этот блок с указанием что после чего происходит. Axure же позволяет подобное реализовать (и второй пример) достаточно быстро и наглядно.
Возьмем другой пример - в Axure практически любую форму можно детализировать за счет этой же динамичности. Указать все возможные варианты в выпадающие списки, отрисовать все действия при выборе того или другого пункта формы и так далее. По-моему это лучше, чем потом описывать все возможные варианты для программистов\верстальщиков. И все это занимает ничуть не больше времени, чем если это делать в Visio + сопроводительный документ.
И применено это может быть как в маленьких, так и крупных проектах.
Например, что вы делаете когда необходимо отрисовать несколько состояний блока для ввода логина и пароля? Мне кажется, вы несколько раз отрисовываете этот блок с указанием что после чего происходит. Axure же позволяет подобное реализовать (и второй пример) достаточно быстро и наглядно.
Возьмем другой пример - в Axure практически любую форму можно детализировать за счет этой же динамичности. Указать все возможные варианты в выпадающие списки, отрисовать все действия при выборе того или другого пункта формы и так далее. По-моему это лучше, чем потом описывать все возможные варианты для программистов\верстальщиков. И все это занимает ничуть не больше времени, чем если это делать в Visio + сопроводительный документ.
И применено это может быть как в маленьких, так и крупных проектах.
Axure я не обижаю, просто мне изначально кажется неверной идея смешивать два процесса в одном — проектирование и прототипирование. Мы ведь стремимся подать проектирование как важный процесс, который нельзя "размывать" вливанием в состав разработки, а стоит обособить. А вот Axure и в целом инструменты быстрого прототипирования предлагают снова смешать две разные задачи.
Чем проще задача — тем качественнее ее можно проработать. Сужу по себе — когда проектировщик пытается не забыть ничего важного на странице и одновременно занимается эффектами появления всплывающих слоев — получается не очень здорово. Точно также, как если при отрисовке схем страниц пытаться делать красивые цвета и иконки, расчитывать расстояния в пикселях. При отрисовке схем страниц лучше заниматься только двумя вещами — указывать, что должно быть на странице и расставлять между этими элементами приоритеты, что важнее и что второстепенное.
Axure и другие подобные средства подходят в двух случаях, как мне кажется — если на проектирование не выделено достаточно денег или если система достаточно простая. И дело тут не в молодости продукта — это понятно, что он еще будет развиваться. Просто лучше, если на каждом этапе идет работа только над чем-то одним.
Еще что мне не нравится в Axure — это то, что многие вещи находятся только в прототипе. Но если есть, например, небольшая кнопка в углу, при наведении на которую в некоторых случаях появляется всплывающий слой. Чтобы узнать о таких вещах из прототипа, нужно, грубо говоря, прокликать все что есть, как в квесте :) Поэтому прототип не должен отменять сопроводительный документ — иначе обязательно что-нибудь потеряется или будет понято не так.
Чем проще задача — тем качественнее ее можно проработать. Сужу по себе — когда проектировщик пытается не забыть ничего важного на странице и одновременно занимается эффектами появления всплывающих слоев — получается не очень здорово. Точно также, как если при отрисовке схем страниц пытаться делать красивые цвета и иконки, расчитывать расстояния в пикселях. При отрисовке схем страниц лучше заниматься только двумя вещами — указывать, что должно быть на странице и расставлять между этими элементами приоритеты, что важнее и что второстепенное.
Axure и другие подобные средства подходят в двух случаях, как мне кажется — если на проектирование не выделено достаточно денег или если система достаточно простая. И дело тут не в молодости продукта — это понятно, что он еще будет развиваться. Просто лучше, если на каждом этапе идет работа только над чем-то одним.
Еще что мне не нравится в Axure — это то, что многие вещи находятся только в прототипе. Но если есть, например, небольшая кнопка в углу, при наведении на которую в некоторых случаях появляется всплывающий слой. Чтобы узнать о таких вещах из прототипа, нужно, грубо говоря, прокликать все что есть, как в квесте :) Поэтому прототип не должен отменять сопроводительный документ — иначе обязательно что-нибудь потеряется или будет понято не так.
Я и согласен с вами и не согласен одновременно :)
Основной мыслью моего поста я постарался аргументировать Аксуру в пользу создания интерактивных прототипов, а не прототипов в чистом виде. Это быстрый и доступный способ создания некого макета, который доступен в понимании не только специалистам, но и простым смертным. Касательно квестов тоже и согласен и нет, любой интерактивный прототип (а тем боле е готовый сайт) - сам по себе и есть квест. А в случае прототипа все элементы можно снабдить так называемыми техническими спецификациями, которые можно использовать именно для описания функционала. Считай как аналог сносок в Visio.
Таким образом я вижу плюсы в более детальной проработке действий и последствий в проектировании того или другого динамического элемента. Так же это может исключить верстальщика из процесса, или существенно сократить его время, если сам верстальщик анимирует все динамические элементы в Axure.
Впрочем это мое ИМХО. Я занимался разработкой и в Visio и в Axure. И все еще настаиваю, что это инструменты для двух разных задач :)
Основной мыслью моего поста я постарался аргументировать Аксуру в пользу создания интерактивных прототипов, а не прототипов в чистом виде. Это быстрый и доступный способ создания некого макета, который доступен в понимании не только специалистам, но и простым смертным. Касательно квестов тоже и согласен и нет, любой интерактивный прототип (а тем боле е готовый сайт) - сам по себе и есть квест. А в случае прототипа все элементы можно снабдить так называемыми техническими спецификациями, которые можно использовать именно для описания функционала. Считай как аналог сносок в Visio.
Таким образом я вижу плюсы в более детальной проработке действий и последствий в проектировании того или другого динамического элемента. Так же это может исключить верстальщика из процесса, или существенно сократить его время, если сам верстальщик анимирует все динамические элементы в Axure.
Впрочем это мое ИМХО. Я занимался разработкой и в Visio и в Axure. И все еще настаиваю, что это инструменты для двух разных задач :)
Похоже, вышла небольшая путаница в терминах опять :) Я специально начал первую часть с классификации прототипов.
Кажется, в этой цитате имеются в виду и бумажные, и интерактивные прототипы? :)
Основной мыслью моего поста я постарался аргументировать Аксуру в пользу создания интерактивных прототипов, а не прототипов в чистом виде
Кажется, в этой цитате имеются в виду и бумажные, и интерактивные прототипы? :)
А я вам сразу за третью часть, где вы отрицаете возможность создания интерактивных прототипов при использовании Axure :)
Да нет, я не отрицал :) Я говорил о том, что наибольший эффект от интерактивного прототипа есть в случае, если он сделан в финальном дизайне. А черно-белый имеет множество ограничений, хотя и пользы несет немало — в этом суть третьей части была :)
Вооот! Теперь согласен, по всем пунктам, особенно после слов "в финальном дизайне" все встало на свои места :)
Кстати, какие решения вы используете при разработке "интерактивного прототипа в финальном дизайне" - каждый раз пишете код под каждый проект или есть какие-то готовые библиотеки автоматизации или сторонние инструменты?
Кстати, какие решения вы используете при разработке "интерактивного прототипа в финальном дизайне" - каждый раз пишете код под каждый проект или есть какие-то готовые библиотеки автоматизации или сторонние инструменты?
Отлично, значит поняли друг друга :)
Для прототипа в финальном дизайне код каждый раз пишется заново, но я с радостью бы нашел автоматические библиотеки :) Пока что кроме scripalicious для скриптов ничего не используется, хотя были попытки сделать что-то вроде такого фреймворка. Пока ничего не вышло, но мы работаем над этим :)
Для прототипа в финальном дизайне код каждый раз пишется заново, но я с радостью бы нашел автоматические библиотеки :) Пока что кроме scripalicious для скриптов ничего не используется, хотя были попытки сделать что-то вроде такого фреймворка. Пока ничего не вышло, но мы работаем над этим :)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 2. Подходы к процессу