15 требований к оформлению прототипа

Спасибо, что поделились с нами требованиями, очень актуально, думаю внутренние для нашей компании UMKA разработаем на основе ваших. Единственное не соглашусь по поводу дизайна и минимума красивостей. Одна из задач прототипа — общее понимание сайта, чтобы на этапе дизайна было минимум изменений. Функциональность, как таковую, прототип в полной степени не показывает, это отражено в ТЗ, а прототип показывает полную структуру, содержание и общее видение. Мы, например, добавляем в прототип кнопки соц. сетей, логотип и еще некоторые постоянные элементы в монохромных оттенках. Это помогает согласовывать прототип с клиентом.

Хорошая, полезная статья! Не могу сказать, что мы в своей практике учитываем все из данных требований, но основные из них однозначно стоит запомнить и не забывать при работе над любым проектом.
Пожалуй, самое страшное, когда проектировщик перестает видеть главное в своей работе и начинает делать из прототипа объект художественного творчества. Растут сроки, трудоемкость. Более того, клиент начинает именно так и представлять свой будущий сайт. Возникают сложности с утверждением последующего дизайна, т.к. он редко делается полностью по прототипу, особенно это касается главной страницы. Надеюсь, после прочтения данной статьи начинающие проектировщики станут более фундаментально подходить к своей работе.

В целом написано внятно, но 7 из 15 пунктов относятся непосредственно к Axure. К сожалению мы не пользуемся данным инструментом, поэтому оценить актуальность пунктов тяжело — наверное ок, можно так сказать..

Касательно 8-ми оставшихся — в целом грамотные советы, позволяющие снизить количество вопросов и недопониманий при работе с клиентом, улучшить качество прототипирования.

Хотелось бы понять КАК данные, выработанные потом и кровью, советы повлияли на процесс проектирования данной студии? Список советов — хорошо. Что улучшилось — вот это интересно. Более того — считаю что широкой аудитории интересно обоснование для совета.

К примеру стоило бы сказать, что:

10. Используйте осмысленное цветовое кодирование в прототипе.

«это позволяет клиенту лучше понять где ссылка, где навигация, где блок поиска и проч..»

7. При наличии реальных текстов, их можно и нужно использовать в прототипе. Запрещено использовать Lorem Ipsum и другие тексты, не имеющие отношения к проекту.

«клиенты редко понимают значение абстрактно названного блока или абстрактной информации на прототипе. Всё должно звучать максимально понятно по смыслу и назначению — это снижает количество вопросов и облегчает клиенту аналитический процесс, что сказывается на корректности замечаний и скорости их получения»

А так — спасибо за переданный опыт. Если решим использовать в работе Axure — обратимся к вашей инструкции сразу :-)

Прототипирование это классное лукавство. По уму, задача прототипирования помочь понять клиенту чего он хочет получить, как это будет работать, а исполнителю минимизировать риски по разработке.

А каким проектам нужно прототипирование? Корпоративным сайтам? Навряд ли. У хорошего подрядчика достаточно опыта и компетенций чтобы поднять проект и без прототипов. Вероятно, прототипирование нужно большим порталам. Портал может делать человек не в теме, но с деньгами, либо человек в теме, но без денег.

Человек с деньгами что то выдумал, приходит к подрядчику и говорит: «Мне нужен туристический портал». Все и рады на нем заработать — прототип, ТЗ, дизайн и тд. А результат.. он не важен никому. Прототиписты говорят подрядчики что-то не так сделали, подрядчики что прототиписты не то навыдумывали. Получилось то, что получилось. Все заработали деньги. Проект не работе по миллиону причин, заказчик разочарован. Если денег много то все запускается по второму кругу.

Если у человека нет денег, но он что-то строит в сети, то он понимает, что он хочет для чего и как. Достаточно и маркерной доски, компетентного дизайнера и программистов чтобы собрать минимальную упрощённую версию сайта и начать смотреть работает тема или нет. Все крупные и успешные проекты построены именно так.

В современной сети не работает история, построил что-то грандиозное, выкатил и все. Настало счастье. Любой самый большой проект логичнее начинать с малого. Выложили, модель работает и пошло плавное развитие, эксперименты, эксперименты.

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

Есть деньги и хочется зарабатывать в сети? Инвестируйте в работающие проекты. Строить с нуля это рискованно и скорее всего у вас ничего не получится. Вам придется конкурировать с девелоперами, которые делают сами для себя и не спят сутками, потому что их собственный проект вопрос выживания. Самый прекрасный подрядчик к вам так никогда относиться не будет ни за какие деньги.

Формирование требований для создания прототипов является актуальным вопросом для компаний, которые разрабатывают Интернет-проекты.

В современных условиях, когда заказчики Интернет-проектов хотят понимать как будет функционировать их проект перед началом вложения серьёзных инвестиций написания технического задания недостаточно. Создание интерактивного прототипа является обязательным условием перед активной стадией реализации проекта, при его создании можно выделять фокус-группы, тестировать на них востребованность проекта, удобство предоставления информации, необходимость функций. Обо всем этом уже не раз говорилось.

Материал, представленный автором в статье можно использовать в качестве основы для построения требований. В связи с тем, что в разных командах процесс разработки идет по-разному, то возможно дополнение и изменения в требованиях.

Некоторые пункты, обозначенные в статье, являются спорными. Так, например, необходимость применения визуального оформления в прототипе, который обозначен в пункте 11, проявляется в зависимости от решаемой задачи и специфики бизнеса клиента.

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

В случае если клиент начинает комментировать предлагаемое цветовое решение на этапе создания прототипа, это позволяет более четко фиксировать требования к дизайну и уже на первой-второй итерации на этапе дизайна предоставить финальный вариант макетов. Пример визуально оформленного прототипа http://prototype.arealsoft.ru/cmsmagazine.ru/01/

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

Считаю, что требование, предъявляемое в пункте 14, является вредным. Именуя название страниц латиницей, становится не так удобно использовать автоматическое левое меню в прототипе генерируемого программой Axure в качестве дополнительного способа навигации по сайту, так как название на самой странице русское, а пункт в левом меню на английском. Особенно это облегчает процесс согласования прототипа для клиента. Лучше перенастроить сервер, чтобы он понимал русские имена файлов и убрать данное требование.

Позволю себе также уточнить пункт 1. При создании прототипа из повторяющихся элементов можно делать шаблоны для разных типов страниц. Если высота контентной области страниц в прототипе одинаковая, то делается общий шаблон. В случае если высота страниц в прототипе разная, то удобно выносить в мастера, такие элементы как шапку, подвал и если требуется, то подложку для контентной области.

Важно подчеркнуть, что пункт 4 должен выполняться в обязательном порядке, все ссылки внутри страниц прототипа должны быть рабочими.

В дополнении к вышесказанному можно добавить еще несколько дополнительных рекомендаций:

• Если в техническое задание требуются вставить скрины страниц из прототипа (как это обычно бывает), то для этого проще всего использовать механизм автоматической генерации спецификаций.
• Одинаковые блоки между страницами в прототипе не должны прыгать, отступы слева и сверху должны быть одинаковыми. Особенно это касается шапки, контентной области, хлебные крошек. На первый взгляд — элементарная вещь, но новички не уделяют этому должного внимания.
• Хлебные крошки на страницах должны отображать реальный путь и полностью функционировать.

Немного смутил пункт 6. Но я полагаю, что наличие такого требования вызвано вашими внутренними процессами. У нас получается так, что внедрение подобного пункта было бы подобно пункту 11, думаю, это не только у нас так.

От себя добавлю:

1. У нас прижилось присвоение, помимо словесного названия страниц, их численного значения. Например, 1.Main_page. Удобно, если требуется в процессе ссылаться на какую-либо страницу, назвать ее номер.
    
2. В качестве страницы с номером 0 выступает майндмап проекта. Клиенту бывает полезно иметь перед глазами общую структуру.

Хороший список принципов, который есть, наверное, у каждого профессионала-проектировщика интерфейсов или компании, предлагающей проектирование.

«В основе прототипа должны быть сетки» — спорное утверждение. Сетку нужно понимать — это факт. Но если речь идет о проектировании в Axure, то привязка к сетке займет существенное количество времени, т.к. ширина колонок сетки не кратна 10 рх, то есть встроенной в программу сетке. И, что гораздо важнее: прототип должен задавать, в первую очередь, функционал, а не определять последующий дизайн. Хороший дизайнер может вполне придумать, как сделать еще лучше, решить с сеткой и выгодной подачей.

Дополнительные отличия от списка в случае разработки прототипа для последующего тестирования:

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

Объем динамики в прототипе всегда определяется до начала разработки и зависит от целей, для которых делается прототип и имеющегося времени.

Некоторые пункты из моего списка:

1. Если предложен нестандартный контрол, то логика его работы должна быть показана полностью. Если это невозможно или потребует большого количества времени — допустимо показать все состояния в статике.
2. Если прототип сложный и используются динамические панели, то они должны иметь четкое понятное название, равно как и элементы в них.
3. Все названия (страниц, панелей, мастеров и других элементов) должны быть понятными и осмысленными. Например, не Had, а Header.
4. Если прототип сложный и мастеров много, то в названиях стоит указывать страницы и группировать по ним.

Спасибо за статью! Действительно оказалась полезной, добавили к своим внутренним правилам ещё одно: помечать неочевидные интерактивные элементы дополнительными значками.

Хотя для прототипирования мы используем inDesign, все эти правила для нас так же актуальны и мы их придерживаемся. Единственное, что у некоторых заказчиков встречаются проблемы с воображением и приходится добавлять в макет реальные изображения и фотографии. Бывает, что это даже и не плохо, как и в случае с рабочими текстами вместо «рыбы», это позволяет сразу проверить выбранное при проектировании решение. Одна оговорка для этого пункта, стоит использовать материалы заказчика, а не найденные в интернете картинки, т.к. тестовые изображения можно легко подобрать или подогнать под прототип, в отличие от реальных материалов.

Хороший материал, все верно подмечено. Действительно, Axure, пожалуй, лучший инструмент для прототипирования на сегодня. Для работы дизайнера или программиста готовый прототип будет лучшим руководством к действию. Именно в процессе его разработки получается быстрее всего найти общий язык с Заказчиком. А прототипирование на начальной стадии проекта, намного сокращает трудоемкость дальнейших этапов и оптимизирует рабочий процесс.