×

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

Хочу поделиться своими знаниями по прототипированию и показать, как с помощью прототипов улучшить качество вашего продукта.

Вот перечень того, что будет охвачено в статье:

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

Несколько лет назад со мной приключился один курьёз. В компанию, где я работала, заходил новый проект. Как зачастую и бывает, заказчик был активист в плане работы, в меру капризный, генерировал кучу идей, НО, естественно, «...очень важный и перспективный» для компании. Как бизнес-аналитику, мне первой предстояло принять на себя информационный удар: разобраться с тем, что есть на входе, структурировать и подготовить документацию. Дни напролет мы с заказчиком висели на скайп-коллах, обсуждали малейшие подробности того, как должна работать система. Параллельно я писала спецификацию. И вот настал долгожданный момент передачи проекта в разработку.

Помню тот день в деталях. Смеркалось... Менеджер проекта, сидевший как раз напротив меня, пригласил техлида. В комнату вошёл парень. Его лицо было слегка напряжено и по нему с легкостью можно было понять, что ничего хорошего от нашей встречи он не ждет, но нотки интриги все же присутствовали судя по вопросительным складкам на лбу. Менеджер вкратце рассказал ему, что вот, мол, у нас тут новый проект, благословил в путь-дорогу, и напоследок торжественным взмахом мышки скинул спецификацию на 152 страницы на почту бедолаге. Единственное, что произнес тот, уже покидая нашу комнату: «Надеюсь, там хоть не 200 страниц читать, как в прошлый раз?»

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

Естественно, можно разбить документацию, скажете вы, делать ее итеративно и т.д., но все это глобально не изменит ситуацию и к тому же не даст целостное восприятие продукта.

По правде говоря, та ситуация раз и навсегда дала мне понять, что так делать нельзя. Нельзя усложнять жизнь разработчикам, команде и заказчику, в конце концов. Знакомство с проектом должно быть приятным и интересным. Это как первое свидание. От него зависит все.

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

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

Поднимаем руки в пользу прототипирования

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

Итак, моя основная задача — окончательно убедить вас в пользе прототипирования и склонить использовать прототипы на своих проектах. Приведу несколько трудно оспоримых фактов:

Касательно заказчиков:

  • крайне редко читают документацию, потому что на 100% уверены, что там всё то, о чем они говорили / думали / мечтали;
  • бывают крайне удивлены, если при разработке откуда-то берутся gaps в фичах, ведь «мы уже всё обсудили»;
  • огорчаются, когда заплатили кучу денег за разработку, а продукт так и не стал успешным.

Касательно разработчиков:

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

Если проанализировать вышеперечисленное, то имеем:

  1. ВСЕ люди лучше воспринимают информацию визуально.
  2. Документация — необходимое, но недостаточное условие для запуска проекта.
  3. Начинать разработку продукта без фидбека от реальных юзеров — путь в никуда.

Итак, вот так делать можно:

а вот так — нельзя:

Best Practices в прототипировании

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

1. Разбиваем систему по ролям

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

Рис. Система с несколькими ролями и различным функционалом для каждой роли

  • Система с наследованием функционала по ролям.

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

Здесь будет достаточно показать одну роль, включающую в себя максимальный скоуп функционала системы, например, роль администратора, как это видно в моем случае:

Рис. Система с наследованием функционала по ролям

2. Обозначаем весь функционал

Зачем? — Заказчик и разработчики должны понимать, что их ждет.
Итак:
  • иерархически перечисляем весь функционал системы;
  • прорисовываем воркфлоу основного сценария (альтернативный — если есть время);
  • как правило, достаточно обычного меню, чтобы показать скоуп системы.

Рис. Функционал системы

3. Делаем комментарии в прототипе

  • зачастую комментарии являются ограничениями проекта, поэтому помогут в будущем правильно сформировать требования;
  • не больше 2 — 3 комментариев на 1 мокапе;
  • кратко. Не нужно писать спецификацию в комментарии;
  • как вариант — можно разбить комментарии на следующие:
    • для разработчиков;
    • нерешенные вопросы для заказчика;
    • предложения по улучшению.

Рис. Использование комментариев в прототипе

4. Соблюдаем версионность

  • каждое изменение в прототипе после обсуждения с заказчиком / разработчиками = новая версия прототипа;
  • версии создаются в пределах роли (если есть разделение по ролям).

Рис. Версионность в прототипировании

5. И пара советов, чего лучше не делать:

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

Как выбрать удобное средство прототипирования и не выглядеть аборигеном

Выбор средства прототипирования имеет огромное значение, поскольку именно от него зависят:

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

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

Я выделила 3 основных фактора, которые влияют на выбор средства прототипирования:

1. Заказчик

*Все кейсы расположены по частоте их появления на проекте (от большей к меньшей).

Что говорит заказчик?Что делать вам?
Прототип должен быть максимально привлекательным, т.к. будет представлен потенциальным пользователям, инвесторам и т.д. Либо просто за те же деньги было бы неплохо получить максимум от прототипа. Выбирайте профессиональное средство для создания прототипов, которое позволяет имитировать реальную систему, линковать страницы и делать элементы кликабельными, а также имеет большие библиотеки элементов и готовых темплейтов для оптимизации работы.
В таком случае я обычно использую Axure RP или Figma.
Предпочтений по выбору средства прототипирования нет, но есть пожелания создать прототип максимально быстро.Лучше всего создать вайрфрейм (черно-белый некликабельный план страниц системы). Это позволит показать основной функционал системы и не потребует много времени на прорисовку деталей, не столь важных на данной стадии проекта. Для таких задач мне идеально подходит Balsamiq.
Совершенно неважно в чем будет сделан прототип.Выбор за вами. Руководствуйтесь входными данными по времени и вашему владению средством, описанными ниже.
Прототип должен быть обязательно кликабельным.Есть два варианта решения задачи:
1. Использовать профессиональное средство прототипирования (Axure RP, Figma и др.). Как вариант, можно использовать тот же Balsamiq, который также позволяет линковать страницы. Но при этом вы столкнетесь с рядом трудностей:
  • линкуются лишь страницы, и имитировать, например, выезжающий pop-up не получится;
  • в экспортируемом файле совершенно непонятно, какой из элементов является кликабельным, если только заранее не знать об этом.
2. Сделать вайрфреймы или мокапы (статические версии прототипа), а затем слинковать их при помощи, например, Invision.
Прототип как таковой не нужен, нужны зарисовки системы, чтобы показать отдельный функционал.Можно воспользоваться любым средством для рисования (MS Paint, MS Visio и т.д.). Сами же зарисовки системы нужно обсудить на митингах с заказчиком и с командой. После этого я бы советовала вставить их в спецификацию, чтобы наглядно было видно о чем идет речь в тексте.
Всю жизнь работал с одним средством прототипирования, привык к нему и не видит необходимости что-то менять.Необходимо оценить ваш уровень владения данным средством. Если есть возможность его использовать — вперед. Если нет — аргументированно предложить альтернативы.
Не собирается оплачивать еще и лицензию на предложенное вами средство.В этом случае лучше использовать либо имеющиеся корпоративные средства, либо бесплатные альтернативы.

2. Время

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

3. Владение средством прототипирования

Какие ограничения по владению средством?Что делать вам?
Не сталкивались ранее с выбранным средством прототипирования.Всегда полезно изучить что-то новое. Но, естественно, нужно делать это не в ущерб проекту. Заказчик никогда не одобрит трату времени и денег на ваше овладение тулом — он платит за создание продукта.
Идеальный вариант — осваивать что-то новое в перерывах между проектами.
На самом деле, практически все средства прототипирования имеют схожие алгоритмы для создания прототипов — а стало быть, хорошо освоив одно средство, вы с легкостью переключитесь на другое.

И напоследок, небольшой сравнительный анализ от меня по двум наиболее часто используемым средствам прототипирования — Balsamiq и Axure RP:

BalsamiqAxure RP
✓ простой интерфейс ✓ более профессиональный, большой функционал
✓ быстрое создание вайрфреймов ✓ прорисовка мелких деталей, занимает время
✓ выглядит как нарисованный от руки ✓ прототип выглядит как готовая система
✓ можно линковать страницы ✓ можно линковать, настраивать события и абсолютно полностью имитировать поведение реальной системы
✓ экспорт в изображения, pdf формат ✓ экспорт + возможность использовать браузерную версию для расшаривания, которая размещена в Axure cloud (придает презентабельности прототипу)
✓ секьюрность при расшаривании проекта
✓ командная работа
✓ библиотеки

Выводы

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

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


Спасибо за Гуся Наде Кушнир


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

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

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

Схожі статті




37 коментарів

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

Тут помогла бы стадия «Я вас внимательно слушаю», когда идет диалог РО/РМ/ВА с заказчиком. Получили требования, набросали прототип, показали заказчику, послушали. Там, глядишь, вот те окна и вот эти свистелки окажутся не нужны. А разработчикам с того — меньше мешков под глазами и техлид лучше спит.

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

А что именно вы пытаетесь решить такого рода прототипами? Зачем они ? Для кого ?
Судя по рисункам это не MVP. И это уж точно не прототип UI от дизайнеров.
Это и не прототип дизайна/архитектуры системы. Потому как в нем отсутствуют структурные связи (целостная картина). Тем более что в разработке этого прототипа отсутствовал техлид.
Если это был прототип требований от заказчика, то он ИМХО содержит много лишней информации (визуальной), и даже вводит в заблуждение...что из этого требование , а что просто часть прототипа/заглушки

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

Кстати, сам для себя когда-то начинал делать конструктор подобного рода. Идея простая: на рабочий стол добавляется сущность. Это нулевой уровень абстракции некоторого семантического среза (семантики) Например, колодец. Кому-то важно знать, что в нем. А кому-то его глубину. Кому-то есть ли там насос, а кому-то есть ли рядом фонарь. Все это в целом набор разных уровней абстракции разных семантик. Если все смешано — так заказчик иногда выдает когда у него нет ТЗ или собственноручно составленное ТЗ — получается эдакий огроменный информационный ком. Если щелкнуть по колодцу от него по разные стороны должны были вкладки введенных семантик показываться — для выбора нужной и спуска на более глубокий уровень абстракции потом. Вот такая получалась итерационная штука — каждый кто был заинтересован могу свою веточку закинуть в нужный уровень нужной семантики. По мере реализации росла бы и детализация.

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

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

а эту «специфику проекта» боженька на скрижалях записал и изменить ее (для всеобщего блага) вообще никак невозможно?

Прототип? Так это еще надо кликать по нему уныло и пресно...
Предлагаю делать мультфильмы! Абстрактно и понятно всем. А главное — кликать не надо. Набор сценариев уже от заказчика пришел. Осталось только дизайнеру от руки нарисовать взаимодействия. Яркие, увлекательные примеры. Мульти Айти.

Не дочитал, но подозреваю кто-то открыл для себя agile-разработку.

Прототипирование — это один из видов процесса анализа требований. Или Вы считаете, что только в agile практикуется анализ?

Я больше к тому, что в agile и прототипирование, и анализ — это уже часть процесса разработки, обе вещи делаются постоянно и это позволяет двигаться быстрее и гибко. Так что даже если вы замените 150-страничный анализ красивым прототипом — это не решит проблему того, что клиент передумает уже завтра и придётся делать новый прототип или новые 150 страниц.

Екатирина спасибо за статью и популяризацию!
Я не очень вдумчиво прочитал, но полностью с вами согласен!
Я сам не всегда применял такое — то ли нет времени, то нет ощущения что это приносит пользу другим (нет позитивного фидбека и поддержки), то создаваемый продукт может быть на базе какой то платформы и это формирует какой-то подход и ограничения.
Но так где я это применял — это было очень полезно, как для стейкхолдеров, как для команды — так и для самого себя: найты разрывы, увидеть пропуски в требованиях, промоделировать прохождение флоу через прототип.
Для меня полезно систематизировать мысли, и мотивацию продолжать попытки использовать это, и уделить время инструментам ( я раньше использовал Visio, Excel даже :), LucidChart, и конечно Paintbrush со кусками скриншотов :))), а иногда просто фотография нарисованного рукой на бумаге).
Еще раз спасибо!
п.с. для разработчиков — я согласен, что нарисованные Екатироной особенности поведения и мышления разработчиков — имеют место быть :) , но не нужно совершенно воспринимать это как претензию или там обиду, и т.п. Это просто то что замечаешь в людях, где то усредняешь и пытаешься подстоиться. В этом и есть работа IT BA — стать посредником между разными сторонами, и ты пытаешься найти хороший баланс для этих отношений. Или по простому — там где разработчики говорят на одном языке с заказчиком и выполняет всю работу с требованиями — там не нужны аналитики :)

в акшуре тоже можно от руки, но обычно в серых тонах все, и все

Да, конечно, можно.

Но как по мне, если использовать акшур, то уже для более изящных решений (я имею ввиду не черно-белые зарисовки). Например, если я хочу «удивить» заказчика и с начала знакомства показать высший пилотаж, то часто делаю прототип именно в акшуре — всегда беспроигрышный вариант, потому что в акшуре можно делать кучу всяких интересных вещей, от которых заказчики в восторге. Ну, или когда нужно представить пользователям, как будет выглядеть система и собрать фидбек.

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

Опять же, это все зависит от проекта, времени и от Вас. Но в целом тенденция такая.

Спасибо, Екатерина! Отличная статья, не знаю сознательно или нет, но выглядит так, что в своей работе над продуктами, Вы движетесь в направлении активно пропагандируемым Marty Cagan, который иногда называют Modern Product Discovery.

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

Касательно разработчиков:

не любят читать требования ни в формате юзер-стори, ни в виде классической спеки;

эээ, нет

при виде требований тратят пару минут на их просмотр, а потом расстаются до лучших времен;

но нет же

предпочитают сделать митинг по вводу в проект, погуглить, посмотреть аналоги, но уж точно не перечитывать список требований;

неужели и такие бывают?

понимают ценность текстовых требований лишь на более поздних этапах разработки.

интересный у вас опыт...

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

но в то же время что-то что непременно захотят выложить в прод а потом спрашивать как с полностью готового продуманного рабочего продукта

ого... и такое бывает?

Частіше, ніж не буває

Согласен по всем пунктам.Чаще встречал разработчиков, которые я бы сказал требуют хоть какую-то спецификацию. Но часто приходится делать все без неё. А юзер стори, считаю вообще одним из важных моментов документации, так как позволяет понять несколько использование продукта отличается от представлений разработчика. А они зачастую существенно отличаются)

Наконец-то начали писать толковый материал.
Я устал от статей обо всем.
Поддерживаю тех, кто делиться дельными советами и практиками.
Спасибо.
Больше интересной информации можете найти тут t.me/BA_PO_PM_PdM

да перестань, статья о «как работать чуть менее неправильно».
201X год, новый продукт, новый заказчик — техлида и дизайнера зовут уже тогда, когда [малоопытным аналитиком и без peer-review] написаны 150 страниц требований, причем с заказчиком (продакт-оунеру) им общаться не дают.
Ну да, прототипы помогли бы. Как подорожник

Екатерина, спасибо за статью.
Все-таки, доу не совсем бесполезен :-)

Дополняя статью, «Как выбрать инструмент для прототипирования в 2018 году?» habr.com/...​any/sberbank/blog/412727

Мне вот любопытно, а в какой момент в изначальной истории должен был появиться дизайнер?

Дизайнер подключился параллельно с передачей спеки разработчикам.
Но суть истории не в этом)) а в том, что дизайнеру, разработчику, тестировщику, заказчику и т.д. легче воспринимать требования, если они хоть немного визуализированы. Как-то так...

Разве не UX дизайнер, основываясь на спеках должен делать вайрфреймы и прототипы?

Все проекты разные и роли тоже. Супер, если у Вас на проекте есть выделенная роль юиксера. Но чаще его может не быть. Тогда это делает бизнес-аналитик (90% случаев), продукт онер, проджект менеджер и т.д.
Мысль одна — не суть важно кто создает прототип — его лучше создавать, чем нет.

Кстати, обычно у меня на проектах я делаю первые зарисовки системы, после чего подключают дизайнера (ну, или, в Вашем случае + юикс-дизайнера), которые придают моему прототипу «продаваемый» вид.

Ох уж эти проджект-менеджеры юиксеры-прототипщики...

Согласен, гораздо веселее, когда сам заказчик нарисовал на салфетке прототипы и сказал «делайте по ним». Никаких доморощенных UX-решений, только хардкор.

— Были у заказчика on-site. Привезли документацию.
— А где она?
— Да вон, стопка салфеток лежит.

Мысль одна — ... — его лучше создавать, чем нет.

Это для меня не секрет. Удивлён, что это открытием стало для вас после как минимум двух (200 страничная спека и 150-страничная, которые упоминаются в статье) больших проектов.

Здорово. Теперь-то мы с Вами «on the same page»

Должен конечно. Но если его нет вообще или его ресурс равен 4 часам в неделю на проекте?
Я согласен что по серьезным и важным вещам UX должен привлекаться уже на этапе прототипирования. UX — отдельное важное направление и специализация.
Но есть и обратная сторона медали — требования очень тяжело «получить» только проводя воркшопы и записывая их текстом. Стейкхолдеры часто не могут себе представить какой продукт их ждет и потом на первом demo\uat наступает прозрение. Или увидев прототип они могут обогатить\изменить требования.

Сейчас многие компании стараются заполучить «универсального специалиста», поэтому часто в описании вакансий можно встретить BA/UX specialist или UI/UX specialist. Это нормально, когда нет узкого распределения обязанностей: один рисует вайрфрейм, второй его дорабатывает по паттернам юзер поведения, а третий — опять перерисовывает его в продаваемый вид.

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