20 октября 2009 в 18:43

О пользе прототипа

О пользе прототипа Как часто наши ожидания не оправдываются. Покупаем продукт – он выглядит иначе, нежели на упаковке. Пользуемся новой услугой – и тут несоответствие рекламе…

В сфере создания сайтов аналогичная ситуация не редкость. Хорошая презентация, договор, бриф, техническое задание, дизайн, разработка и получается … мало того, что совсем не то, чего ждали. Оно еще и не работает. То есть дизайн есть, контент сайта добавляется и редактируется, даже посетители приходят. А денег проект не приносит.

По опыту можно сказать, что чаще всего это происходит из-за отсутствия:

  • взаимопонимания между заказчиком и исполнителем
  • проработки сценариев использования при создании дизайна
  • Взаимопонимание: терминология и документация
    Чтобы описать некоторые аспекты работы будущего сайта, часто приходится пользоваться специальной терминологией. Разобраться в ней без специальной подготовки бывает непросто. Конечно, можно описывать требования простым языком, но это влечет за собой ряд трудностей при передаче документации в разработку. Слишком уж неоднозначны будут документы, чересчур много вопросов потребуется повторно уточнить.

С другой стороны, надо ли говорить, что техническое задание – довольно сухой и тяжело читаемый документ. Здесь ключевым является слово “техническое”. ТЗ содержит огромное количество деталей, вдаваться в которые заказчику, в большинстве случаев, совсем не хочется, ему просто нужен результат. А если ТЗ содержит более 100 страниц, то вероятность того, что он будет прочитан кем-либо, кроме менеджера проекта и разработчиков, очень мала.

  1. Дизайн или интерфейс?
    Довольно часто, основным критерием оценки качества сайта для заказчика является графический дизайн. При этом почти всегда забывается несколько особенностей:
  • Дизайн сайта — это не произведение художественного искусства, а пользовательский интерфейс
  • Пользовательский интерфейс должен помогать пользователям решать их задачи
  • В 90% случаев заказчик сайта не является его пользователем (если речь не идет о панели управления сайтом).

То есть, в случаях, когда исполнитель разрабатывает дизайн, основываясь исключительно на требованиях заказчика (а такое не редкость), конечные пользователи такого проекта (потенциальные клиенты) будут обречены на множественные неудобства и, скорее всего, уйдут. Связано это с тем, что, с одной стороны, заказчик, не знаком с правилами usability, с другойон склонен уделять гораздо больше времени художественному оформлению, нежели решению вопроса “как сделать сайт удобным для посетителей”. Оформление отвлекает от сути.

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

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

Гораздо лучше и для облегчения взаимопонимания, и для решения задач пользователей, создавать прототип. Или, другими словами, модель будущего сайта.

Продолжение статьи http://intecco.ru/blog/o-polze-prototipa

Удачных вам проектов.
Макаров Петр, менеджер проектов компании INTECCO

369
  • Тема закрыта
Комментарии (3)
  • 21 октября 2009 в 13:22 • #
    Николай Тупик

    Здравствуйте уважаемая Елена Литвинова!
    Так прототип и есть то самое ТЗ, только "в живую", а не на 100 страницах и что самое главное - хорошо понятное как заказчику, так и исполнителю. Другое дело, что часто заказчик говорит "Вот прототип, но нужно внести в него то-то и то-то" и тем самым разрушает прототип до основания и тогда требуется неординарное (не в русле прототипа) решение, которое позволит совместить и то и другое. Наличие прототипа позволяет понять вектор направленности заказчика, а это уже почти половина успешной реализации проекта. А скучное ТЗ это скорее точка в пространстве, чем вектор.
    С уважением

  • 21 октября 2009 в 14:52 • #
    Виталий Новиков

    Добрый день, Елена.

    То, что вы пишите, интересно. Но, существует и несколько иной путь.
    Это совмещение вашего понятия "бумажный прототип" и "интерактивный прототип". Делается это довольно просто. Например, использованием для разработки ТЗ такого редактора, как Визио. Здесь можно и основы дизайна заложить и логику работы проверить.
    Много времени можно сэкономить.
    Попробуйте, может понравится :-)

    Удачи!

  • 21 октября 2009 в 16:29 • #
    Александр Литвинко

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

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

    Если это модель нового структурного взаимодействия, - тогда берется инструмент на основе графового представления связей.
    Если это иллюстрация к модифицированному интерфейсу существующего продукта - тогда что-нибудь из интерактивных моделей (Axure, Balsamiq, проч.)
    Если же это просто интерфейс стандартного веб-сайта, то лучше всего использовать в качестве прототипа готовое решение на базе какой-либо ЦМС c замечанием, типа, - работать будет так, а выглядеть - так (аль-таб на скриншот нового графического интерфейса)... =))

    Дерзайте!


Выберите из списка
2019
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970