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

1. Прототипы (mockups), как
средство снижения риска неудач
на проектах.
Презентация по следам чтения Главы №15 
SD2 1

2. Представить будущую программную систему,
а именно ее пользовательский интерфейс, и
ясно изложить требования к ней – нелегкая
задача.
SD2 2

3. Это трудно даже если у вас есть
текстовая документация к системе и
набор диаграмм к ней.
SD2 3

4. Поэтому клиенты часто отвечают на вопросы
бизнес-аналитика о поведении пользовательского
интерфейса новой системы: «Я пойму что надо,
когда это увижу »
SD2 4

5. Пользователь гораздо более охотно согласится
поэкспериментировать с прототипом (Balsamiq или
Axure), что интересно и занимательно, чем читать
спецификацию требований к программному
обеспечению!
SD2 5

6. Необязательно делать прототип всего продукта (что
может занять много времени), а необходимо
сосредоточиться на узких областях системы, к
которой у вас есть главные вопросы.
SD2 6

7. Для каждого создаваемого прототипа необходимо
доводить до заинтересованных лиц, почему он
создается, что вы хотите узнать с его помощью и что
вы будете делать с прототипом после выяснения
требований (он будет удален! и использоваться в
реальном ПО не будет! – особенно прототип Axure).
SD2 7

8. Поэтому есть опасность, создавать очень
детализированный и динамический прототип,
который будет похож на реальный проект – в таком
случае технически неграмотный клиент будет
требовать от вас разместить на реальном сервере
ваш прототип! Но это невозможно!
SD2 8

9. Удачи в прототипировании, как
средстве снижения риска неудач в
проектах!
Далее... 15 правил оформления прототипа (взято с CMS Magazine – прямая ссылка)
SD2 9

10. Глубина проработки (взято с CMS Magazine – прямая ссылка)
1. Все повторяющиеся элементы должны быть сделаны через мастера. Мастера
должны быть разложены по папкам и проименованы в соответствии со своим
предназначением.
SD2 10

11. 2. Обязательно использовать встроенный редактор стилей — все стили текста в
прототипе задаются только через него. Чем стилей меньше, тем лучше,
отталкиваемся от семантики текстов и стандартных HTML-тегов: h1, h2 и т.д.
SD2 11

12. 3. Интерактивные элементы нужно программировать и, если срабатывание не
очевидно, то помечать их для заказчика специальным знаком — у нас принят
треугольник.
SD2 12

13. 4. Необходимость залинковки прототипа обсуждаем с менеджером проекта. Если
прототип залинкован частично, то отмечаем элементы, на которые можно
нажать, треугольником. Не забываем подчеркивать псевдоссылки пунктирной
линией.
SD2 13

14. 5. Однотипные разделы можно не дублировать, показывая один раз. Тем не менее, если
для них есть контент, размещение которого необходимо планировать, то делаем все
страницы.
Внешний вид
6. В основе прототипа должны быть сетки. Удобнее всего использовать классические сетки
12/16 колонок, но лучше всего согласовывать это с арт-директором, который будет
курировать дизайн. Все объекты прототипа располагаются по сетке, далее дизайнеры
сохраняют такое размещение.
SD2 14

15. 7. При наличии реальных текстов, их можно и нужно использовать в прототипе.
Запрещено использовать Lorem Ipsum и другие тексты, не имеющие отношения к
проекту.
8. Небольшие фрагменты текста: подписи к кнопкам, заголовки и т.д. пишем
сами. Эти задачи не требуют участия копирайтера, менеджера и тем более
клиента.
9. Все должно быть просто и аккуратно: минимум цветов, стандартные веб-
шрифты, отсутствие полноцветных изображений и т.д.
SD2 15

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

17. 11. Прототип — это инструмент, который позволяет проработать и утвердить
функциональность проекта отдельно от дизайна. Поэтому он ни в коем случае не
должен выглядеть как дизайн. Запрещено тратить время на всевозможные
красивости.
SD2 17

18. 12. Используем стандартные контролы, если нет острой необходимости в обратном.
Другое
13. Файлы, страницы, мастера и пр. необходимо именовать только латиницей. При выгрузке
прототипа на сервер, не работает все, где использована кириллица.
14. Все имена в прототипе должны быть осмыслены, начинаться с большой буквы и
отражать суть объекта, пробелы заменяются на подчеркивание.
Например: Cart_active_var2
15. Прототипы, публикуемые в интернете для согласования с заказчиком, обязательно
защищать паролем в Axure 7.0. Особенно это относится к договорам с NDA.
Может показаться, что некоторые требования усложняют работу, напротив, они облегчают
и систематизируют процесс. Все правила основаны на реальном опыте.
Над иллюстрациями с статье работал Юрий Панасюк.
Автор: Никита Михеенков, Nimax (Директор по развитию)
Если интересно вот ссылка на супер-Видео с Analyst Days-3 в Москве о прототипах:
http://analystdays.com/en/talk/20824
SD2 18