×

Прототипирование для менеджеров: зачем это нужно и какие бывают прототипы

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

Уметь делать прототипы полезно бизнес-аналитикам, маркетологам, продукт-менеджерам, дизайнерам и тем, кто работает в распределённой команде.

Для чего нужно прототипирование

  • Выявление и написание требований к функционалу, интерфейсу, веб-сайту.
  • Управление ожиданиями заказчика.
  • Иллюстрирование user stories или use cases для того, чтобы они стали более понятными (в том числе и для самого аналитика).
  • Создание собственно дизайна, когда в команде нет дизайнера (редко).
  • Утверждение основных блоков и расположения с заказчиком.
  • Передача требований дизайнеру.
  • Тестирование расположения блоков, кнопок, да и валидация идей.

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

Визуальное представление, понимание, оценка и изучение идей также лежат в основе методологии Design thinking.

Какие бывают прототипы

Так как чаще всего мы работаем с иностранными заказчиками, то и термины будут звучать на английском: wireframe и prototype (low-fidelity prototype, high-fidelity prototype).

Wireframe

Начальный вид прототипирования. Черновой набросок от руки на бумаге. Некоторые приложения, например Balsamiq, специально имитируют стиль небрежного рисунка, чтобы не фокусироваться на внешнем виде. Такие «наброски» лишь обозначают блоки на странице. Что очень удобно и не отвлекает внимания на самом первом этапе обсуждения. Для wireframes лучше не использовать цвет — это будет отвлекать от сути и совещание пройдёт в обсуждении цветов кнопки. Оставьте цвет дизайнерам для создания прототипов высокой детализации.

Что даёт wireframe:

  • предметное отображение функционала;
  • описание доступных функций;
  • определение правил отображения разных видов информации;
  • описание различных сценариев.

Кто делает: менеджеры, бизнес-аналитики, маркетологи, дизайнеры и UX-дизайнеры.

Олег Руденко, Senior Business Analyst в EIS Group:

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

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

Low-fidelity prototype (прототип малой детализации)

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

Прототип малой детализации чаще всего применяется для окончательного утверждения расположения функциональных блоков с заказчиком или другим ответственным лицом (product owner). При создании переходов по кнопкам и ссылкам между страницами используется для пользовательского тестирования. Создать готовый кликабельный прототип такого типа можно в Axure. Отдельно переходы можно сделать в Invision или Marvel.

Если хотите сделать прототип более привлекательным для клиента, но вы не Web- или UI-дизайнер, сделайте равные расстояния между блоками и определите иерархию размеров шрифта (заголовки 1, 2, 3 уровней и основной текст, ссылки).

Кто делает: менеджеры, бизнес-аналитики, маркетологи, дизайнеры и UX-дизайнеры.

Ирина Тищенко, Marketing Ninja of Ministra TV platform в Infomir:

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

Еще такой подход к работе помогает избежать ситуации «я не так себе это представлял» в работе с Product Owner и поставить четкое техническое задание при работе с удаленной командой дизайнеров. Количество итераций для получения желаемого результата значительно уменьшается, экономятся ресурсы и время.

High-fidelity prototype (прототип высокой детализации)

Этот вид прототипа уже выглядит как готовый продукт с подобранным стилем и pixel perfect элементами. Он тестируется на соответствие требованиям по доступности для людей с разными видами нарушения восприятия цветового диапазона. Утверждается с заказчиком и передаётся в разработку.

Кто делает: только дизайнеры.

Выводы

Любой из представленных видов прототипа можно (и нужно) сделать кликабельным и протестировать на ваших потенциальных пользователях. Для этого есть такие приложения как Balsamiq, Axure, InVision, Marvel и многие другие.

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

Делайте прототипы: экономьте ваше время, деньги проекта и нервы ваших пользователей :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn

Схожі статті




35 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо! Я вот о чём всё время думаю: делаем прототип в «Бальзамике» и со временем выбрасываем; делаем слабодетализированный и тоже выбрасываем; самое страшное произойдёт и с хай-фаем. Как на ваш взгляд можно сократить эту мусорку хотя бы на один пункт?

Hi-Fi передаётся в работу по цепочке дальше, потом мокапы используются в спецификации, qa смотрят на них при тестировании. Вопрос: зачем сокращать и что это даст? Всё-таки это не бумага, дерево вы не спасём :)

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

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

Почему для лендинга не надо делать прототип? В своём опыте начала использовать прототипирование с 2010-го года и как раз при работе с нашими клиентами, для веб-сайтов.

Потому что получается универсально и бесполезно.

Репонен, кстати, тоже говорил, что они никогда не делают отдельные ваерфреймы и на это есть миллион причин))

Было полезно, спасибо!

Для

прототип малой детализации

можно использовать условно бесплатный инструмент www.figma.com

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

В «Фигме» есть прототипирование (кажись, оно уже появилось во всех скетчобразных инструментов). help.figma.com/...​ng/prototyping-presenting

Очень интересная статься, прототипирование, действительно бывает полезным. К сожалению не совсем нашел информацию по

Прототипирование для менеджеров

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

Согласен, если нет тестировщика, то пээм тестирует, а вот если и разработчиков нет... то уже не менеджер получается. :) Мы вообще делаем, что пока нельзя делегировать, если все можно делегировать, то можно пока ничего и не делать, похоже.

Однако, если назвать статью «Тестирование нефункциональных требований для менеджеров» потому что, если нет тестировщика менеджер тестирует, выйдет чуть менее логично?

Но повторюсь, статья интересная.

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

А де недоліки прототипування?

В мене багато разів було таке, що вайрфрем був шикарним, але функціональний прототип показав, що це повне лайно та так робити не можна. А ще нещодавно потрапили на випадок, коли навіть прототип не дав розуміння помилки, бо він сильно спрощував бізнес-логіку.

Значит вайрфрейм был непродуман совсем. При создании вайрфрейма все продумываешь, а на прототипе просто разворачиваешь логику продукта. Если такое «много раз» повторялось, вывод прост — меняйте вашего прототипировщика :)

Значит вайрфрейм был непродуман совсем.

Навпаки, він був ідеально зроблений, враховані всі кейси, всі нюанси. Але він був статичним. Це важко врахувати.

Если такое «много раз» повторялось, вывод прост — меняйте вашего прототипировщика :)

Я не можу сам себе замінити. Я можу тільки ставати краще із кожною помилкою, яку я робив. ;)

можно сделать прототип в Axure, он будет кликабельным, живым

Я взагалі в реальному коді це роблю. З даммі даними тільки. Одразу декілька зайців вбиваю.

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

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

Если вы допускаете одни и те же ошибки, повод задуматься, что прошлый опыт не научил. Значит надо попробовать другой подход. Попросить совета, по-другому смотреть на интерфейс, заглянуть как там у конкурентов это сделано. Я не говорю, что мои интерфейсы идеальны (ах если бы), но ошибки из раза в раз не должны повторяться. Поменяйте инструмент, возьмите больше времени для разработки и все будет отлично :)

Ніхто не казав, що помилки постійно повторюються. Я казав про те, що вайрфрейми не дають уяви про динаміку, це треба враховувати окремо, а живі прототипи інтерфейсів можуть не враховувати всі бізнес-кейси та процеси, особливо під час зміни стану. Простий приклад, якщо у вас є механізм автозбереження документа, чи потрібна вам кнопка save?

Конечно, прототип не может покрыть абсолютно всё, но хорошо продуманный покроет 99%.

Простий приклад, якщо у вас є механізм автозбереження документа, чи потрібна вам кнопка save?

Человеку по ту сторону монитора надо дать понять о существовании такого механизма.

Человеку по ту сторону монитора надо дать понять о существовании такого механизма.

Якого саме?

В цитируемом куске текста было написано о механизме автосохранения. Человеку по ту сторону экрана надо дать знать о том, что есть автосохранение, данные сохранены и так далее. Такое можно показать даже средствами InVision. Кнопка не нужна :)

Человеку по ту сторону экрана надо дать знать о том, что есть автосохранение, данные сохранены и так далее

Це підтримую

Кнопка не нужна

А ось тут вже складніше. Якщо документ є кінцевим результатом роботи користувача, то можна обійтися без неї. Якщо документ є одним з етапів певного процесу — вона стане трігером для початку наступних ітерацій.

И это всё можно предусмотреть правильно составив ux архитектуру. Если так сделать не получается, а ошибки происходят постоянно, то вопрос уже не в инструменте.

Що ви розумієте під виразом

правильно составив ux архитектуру

?

Простий приклад, якщо у вас є механізм автозбереження документа, чи потрібна вам кнопка save?

Конечно ДА. При разработке прототипа надо думать о том, что у вас есть 5 минут для того, чтобы пользователь, даже не очень технически дружественный, разобрался в вашем продукте. Потому что если не разберется — вы его теряете.

Потому что если не разберется — вы его теряете.

Це працює для загальновживаних продуктів, але не так вже й страшно для корпоративних.

Конечно ДА.

Ок, знайдіть її в гуглдоксах.

В корпоративных продуктах пользователь от вас не уйдёт, но большая вероятность допустить ошибку. Цена человеческой ошибки в B2B может стоить тысячи $.

Може й буде коштувати — різні речі. Ви можете допустити помилку, яка призведе до знищення людства. Ефект метелика. ;)

Марина уже ответила)
Гугл доксами пользуются как сопутствующим продуктом, а не основным + там есть четкое сообщение, что все изменения сохранены. С историей версий и разными форматами для скачивания. Я не думаю, что вы разрабатываете новые гугл доксы или продукт такого уровня.
Отсюда и более высокие требования к интерфейсу и взаимодействию. Гугл может допускать ошибки, вы — нет. Что дозволено Юпитеру, не дозволено быку.

Підписатись на коментарі