Хочу поделиться своими знаниями по прототипированию и показать, как с помощью прототипов улучшить качество вашего продукта.
Вот перечень того, что будет охвачено в статье:
- все успешные продукты начинаются с прототипов;
- почему хороший прототип — часто плохой прототип;
- как выбрать удобное средство прототипирования и при этом не выглядеть аборигеном;
- правильное представление прототипа зачастую гораздо сложнее, чем его создание.
Несколько лет назад со мной приключился один курьёз. В компанию, где я работала, заходил новый проект. Как зачастую и бывает, заказчик был активист в плане работы, в меру капризный, генерировал кучу идей, НО, естественно, «...очень важный и перспективный» для компании. Как бизнес-аналитику, мне первой предстояло принять на себя информационный удар: разобраться с тем, что есть на входе, структурировать и подготовить документацию. Дни напролет мы с заказчиком висели на скайп-коллах, обсуждали малейшие подробности того, как должна работать система. Параллельно я писала спецификацию. И вот настал долгожданный момент передачи проекта в разработку.
Помню тот день в деталях. Смеркалось... Менеджер проекта, сидевший как раз напротив меня, пригласил техлида. В комнату вошёл парень. Его лицо было слегка напряжено и по нему с легкостью можно было понять, что ничего хорошего от нашей встречи он не ждет, но нотки интриги все же присутствовали судя по вопросительным складкам на лбу. Менеджер вкратце рассказал ему, что вот, мол, у нас тут новый проект, благословил в путь-дорогу, и напоследок торжественным взмахом мышки скинул спецификацию на 152 страницы на почту бедолаге. Единственное, что произнес тот, уже покидая нашу комнату: «Надеюсь, там хоть не 200 страниц читать, как в прошлый раз?»
В общем-то, ничего такого, рабочие моменты. Я сделала свою работу, есть детальная спецификация. А то, что кому-то нужно перечитать с ходу, на секундочку, полторы сотни страниц чистого текста, чтобы войти в курс проекта — не мои проблемы. Работайте, ребята!
Естественно, можно разбить документацию, скажете вы, делать ее итеративно и т.д., но все это глобально не изменит ситуацию и к тому же не даст целостное восприятие продукта.
По правде говоря, та ситуация раз и навсегда дала мне понять, что так делать нельзя. Нельзя усложнять жизнь разработчикам, команде и заказчику, в конце концов. Знакомство с проектом должно быть приятным и интересным. Это как первое свидание. От него зависит все.
С тех пор я пересмотрела подход к созданию требований, включив в их разработку прототипирование как обязательный этап. Это позволяет всем стейкхолдерам быстро понять идею проекта и дать свой фидбек, что очень-очень немаловажно для запуска успешного продукта. Понятное дело, что многое зависит от проекта, пожеланий заказчика, ну и еще тысячи вещей: прототипирование может быть не включено в эстимейт, на него может не быть времени, желания и т.д. В этих случаях я советую использовать немного принципов из политики nudge (как правильно подталкивать стейкхолдеров к «хорошим» решениям), ну или хотя бы стараться в условиях ограниченных ресурсов делать любые зарисовки системы — на салфетке, в блокноте, и прикреплять это к вашей документации. Это однозначно гораздо лучше, чем ничего.
В конце концов, в создании прототипов есть один очень приятный момент для вас — когда вы на стадии выяснения требований и разработки документации, то перспектива увидеть конечный продукт отдалена во времени и довольно туманна. Прототипирование же позволяет прикоснуться к системе здесь и сейчас, что не может не радовать вас, если вы такой же нетерпёха, как и я.
Поднимаем руки в пользу прототипирования
Давайте заранее договоримся, что в статье прототипом буду называть любой продукт, созданный в процессе визуального представления системы. Хотя на самом деле, это не совсем правильно: прототип — это один из видов такого представления, наряду со скетчем, вайрфреймом и мокапом.
Итак, моя основная задача — окончательно убедить вас в пользе прототипирования и склонить использовать прототипы на своих проектах. Приведу несколько трудно оспоримых фактов:
Касательно заказчиков:
- крайне редко читают документацию, потому что на 100% уверены, что там всё то, о чем они говорили / думали / мечтали;
- бывают крайне удивлены, если при разработке откуда-то берутся gaps в фичах, ведь «мы уже всё обсудили»;
- огорчаются, когда заплатили кучу денег за разработку, а продукт так и не стал успешным.
Касательно разработчиков:
- не любят читать требования ни в формате юзер-стори, ни в виде классической спеки;
- при виде требований тратят пару минут на их просмотр, а потом расстаются до лучших времен;
- предпочитают сделать митинг по вводу в проект, погуглить, посмотреть аналоги, но уж точно не перечитывать список требований;
- понимают ценность текстовых требований лишь на более поздних этапах разработки.
Если проанализировать вышеперечисленное, то имеем:
- ВСЕ люди лучше воспринимают информацию визуально.
- Документация — необходимое, но недостаточное условие для запуска проекта.
- Начинать разработку продукта без фидбека от реальных юзеров — путь в никуда.
Итак, вот так делать можно:
а вот так — нельзя:
Best Practices в прототипировании
Если вы уже осознали всю важность прототипирования, то самое время научиться создавать прототипы правильно. Вот несколько кейсов, к которым я пришла в результате долгой работы с ними:
1. Разбиваем систему по ролям
- Система с несколькими ролями и различным функционалом для каждой роли.
Рис. Система с несколькими ролями и различным функционалом для каждой роли
- Система с наследованием функционала по ролям.
Это тот случай, когда роли расположены в иерархическом порядке, т.е. глобальная роль имеет доступ ко всему функционалу, а скоуп фич для нижестоящих ролей постепенно уменьшается по мере движения к роли с наиболее ограниченными возможностями по использованию системы.
Здесь будет достаточно показать одну роль, включающую в себя максимальный скоуп функционала системы, например, роль администратора, как это видно в моем случае:
Рис. Система с наследованием функционала по ролям
2. Обозначаем весь функционал
Зачем? — Заказчик и разработчики должны понимать, что их ждет.Итак:
- иерархически перечисляем весь функционал системы;
- прорисовываем воркфлоу основного сценария (альтернативный — если есть время);
- как правило, достаточно обычного меню, чтобы показать скоуп системы.
Рис. Функционал системы
3. Делаем комментарии в прототипе
- зачастую комментарии являются ограничениями проекта, поэтому помогут в будущем правильно сформировать требования;
- не больше 2 — 3 комментариев на 1 мокапе;
- кратко. Не нужно писать спецификацию в комментарии;
- как вариант — можно разбить комментарии на следующие:
- для разработчиков;
- нерешенные вопросы для заказчика;
- предложения по улучшению.
Рис. Использование комментариев в прототипе
4. Соблюдаем версионность
- каждое изменение в прототипе после обсуждения с заказчиком / разработчиками = новая версия прототипа;
- версии создаются в пределах роли (если есть разделение по ролям).
Рис. Версионность в прототипировании
5. И пара советов, чего лучше не делать:
- НЕ делаем слишко красиво:
- ограничивает дизайнера;
- вводит в заблуждение заказчика (ожидает, что это финальный вариант системы).
- НЕ детализируем:
- ограничивает разработчиков;
- отвлекает от основного флоу;
- в случае малейших изменений — много перерисовывать;
- это никому не нужно на этапе прототипирования.
- НЕ тратим время на текстовый контент.
Как выбрать удобное средство прототипирования и не выглядеть аборигеном
Выбор средства прототипирования имеет огромное значение, поскольку именно от него зависят:
- внешний вид прототипа;
- простота использования прототипа стейкхолдерами;
- степень покрытия функционала;
- быстрота создания прототипа, поскольку все мы знаем, что хорошее запоздалое решение = никому не нужное решение.
Осознанно или нет, но если вы задались целью создать прототип, то выбор средства — это как колесо сансары — вам неизбежно придется его пройти. Однако задача не в том, чтобы безмолвно покориться первой ссылке результата поискового запроса Google «создать прототип», начать рисовать, а затем на середине пути понять, что это не то, что нужно. Тут главное тщательно проанализировать ситуацию касательно именно вашего проекта и продукта и затем принять решение.
Я выделила 3 основных фактора, которые влияют на выбор средства прототипирования:
1. Заказчик
*Все кейсы расположены по частоте их появления на проекте (от большей к меньшей).
| Что говорит заказчик? | Что делать вам? |
| Прототип должен быть максимально привлекательным, т.к. будет представлен потенциальным пользователям, инвесторам и т.д. Либо просто за те же деньги было бы неплохо получить максимум от прототипа. | Выбирайте профессиональное средство для создания прототипов, которое позволяет имитировать реальную систему, линковать страницы и делать элементы кликабельными, а также имеет большие библиотеки элементов и готовых темплейтов для оптимизации работы. В таком случае я обычно использую Axure RP или Figma. |
| Предпочтений по выбору средства прототипирования нет, но есть пожелания создать прототип максимально быстро. | Лучше всего создать вайрфрейм (черно-белый некликабельный план страниц системы). Это позволит показать основной функционал системы и не потребует много времени на прорисовку деталей, не столь важных на данной стадии проекта. Для таких задач мне идеально подходит Balsamiq. |
| Совершенно неважно в чем будет сделан прототип. | Выбор за вами. Руководствуйтесь входными данными по времени и вашему владению средством, описанными ниже. |
| Прототип должен быть обязательно кликабельным. | Есть два варианта решения задачи: 1. Использовать профессиональное средство прототипирования (Axure RP, Figma и др.). Как вариант, можно использовать тот же Balsamiq, который также позволяет линковать страницы. Но при этом вы столкнетесь с рядом трудностей:
|
| Прототип как таковой не нужен, нужны зарисовки системы, чтобы показать отдельный функционал. | Можно воспользоваться любым средством для рисования (MS Paint, MS Visio и т.д.). Сами же зарисовки системы нужно обсудить на митингах с заказчиком и с командой. После этого я бы советовала вставить их в спецификацию, чтобы наглядно было видно о чем идет речь в тексте. |
| Всю жизнь работал с одним средством прототипирования, привык к нему и не видит необходимости что-то менять. | Необходимо оценить ваш уровень владения данным средством. Если есть возможность его использовать — вперед. Если нет — аргументированно предложить альтернативы. |
| Не собирается оплачивать еще и лицензию на предложенное вами средство. | В этом случае лучше использовать либо имеющиеся корпоративные средства, либо бесплатные альтернативы. |
2. Время
| Какие ограничения по времени? | Что делать вам? |
| На фазу прототипирования не заложен эстимейт. | Даже в этом случае я советую постараться сделать небольшие зарисовки функционала. Пусть это будет приятным бонусом для заказчика. Все любят подарки. Плюс, таким образом, вы однозначно завоюете симпатию заказчика к себе и компании, в частности. |
| Времени для создания полноценных прототипов катастрофически не хватает. | Делайте зарисовки самого важного и главного, не растрачивайте усилия на вспомогательный функционал, контент, внешний вид и т.д. |
3. Владение средством прототипирования
| Какие ограничения по владению средством? | Что делать вам? |
| Не сталкивались ранее с выбранным средством прототипирования. | Всегда полезно изучить что-то новое. Но, естественно, нужно делать это не в ущерб проекту. Заказчик никогда не одобрит трату времени и денег на ваше овладение тулом — он платит за создание продукта. Идеальный вариант — осваивать что-то новое в перерывах между проектами. На самом деле, практически все средства прототипирования имеют схожие алгоритмы для создания прототипов — а стало быть, хорошо освоив одно средство, вы с легкостью переключитесь на другое. |
И напоследок, небольшой сравнительный анализ от меня по двум наиболее часто используемым средствам прототипирования — Balsamiq и Axure RP:
| Balsamiq | Axure RP |
| ✓ простой интерфейс | ✓ более профессиональный, большой функционал |
| ✓ быстрое создание вайрфреймов | ✓ прорисовка мелких деталей, занимает время |
| ✓ выглядит как нарисованный от руки | ✓ прототип выглядит как готовая система |
| ✓ можно линковать страницы | ✓ можно линковать, настраивать события и абсолютно полностью имитировать поведение реальной системы |
| ✓ экспорт в изображения, pdf формат | ✓ экспорт + возможность использовать браузерную версию для расшаривания, которая размещена в Axure cloud (придает презентабельности прототипу) |
| ✓ секьюрность при расшаривании проекта | |
| ✓ командная работа | |
| ✓ библиотеки |
Выводы
Немаловажная деталь при работе с прототипами — помимо создания прототипов нужно также уметь правильно представлять их. Несколько раз я становилась на одни и те же грабли и просто отправляла прототип на ревью заказчику или разработчикам, игнорируя стадию его презентации. Это неверный путь. Ничего хорошего из этого не выходило. Каждый воспринимает по-своему то, что видит. Да и смотреть может не туда, куда нужно было бы. Поэтому помимо создания прототипа позаботьтесь и о его представлении.
Нужен или нет прототип — решать вам. Единственного правильного решения здесь нет, и всё зависит от конкретного случая. Но я уверена, что его наличие никогда не будет лишним и позволит сделать ваш продукт более юзер-ориентированным и немного качественнее, а это именно то, за что мы все боремся.
Спасибо за Гуся Наде Кушнир
Читайте также: «Прототипирование для менеджеров: зачем это нужно и какие бывают прототипы»