Чому варто включити в розробку прототипування

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

Ось перелік того, що буде охоплено у статті:

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

Кілька років тому зі мною трапився один курйоз. У компанію, де я працювала, заходив новий проект. Як часто і буває, замовник був активіст в плані роботи, в міру примхливий, генерував купу ідей, АЛЕ, природно, «...дуже важливий і перспективний» для компанії. Як бізнес-аналітику, мені першої належало взяти на себе інформаційний удар: розібратися з тим, що є на вході, структурувати і підготувати документацію. Днями ми з замовником висіли на скайп-коллах, обговорювали найменші подробиці того, як повинна працювати система. Паралельно я писала специфікацію. І ось настав довгоочікуваний момент передачі проекту в розробку.

Пам'ятаю той день в деталях. Сутеніло... Менеджер проекту, сиділа якраз навпроти мене, запросив техлида. В кімнату увійшов хлопець. Його обличчя було злегка напружене і по ньому з легкістю можна було зрозуміти, що нічого доброго від нашої зустрічі він не чекає, але нотки інтриги все ж були присутні судячи з питальним зморшки на лобі. Менеджер коротко розповів йому, що ось, мовляв, у нас тут новий проект, благословив в дорогу, і наостанок урочистим рухом мишки скинув специфікацію на 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, який також дозволяє линковать сторінки. Але при цьому ви зіткнетеся з рядом труднощів: линкуются лише сторінки, і імітувати, наприклад, виїжджає pop-up не вийде; в експортованому файлі абсолютно незрозуміло, який з елементів є кликабельним, якщо заздалегідь не знати про це. 2. Зробити вайрфреймы або мокапы (статичні версії прототипу), а потім слинковать їх за допомогою, наприклад, Invision.
Прототип як такий не потрібен, потрібні замальовки системи, щоб показати окремий функціонал.	Можна скористатися будь-яким засобом для малювання (MS Paint, MS Visio і т. д.). Самі ж замальовки системи потрібно обговорити на мітингах з замовником і з командою. Після цього я б радила вставити їх в специфікацію, щоб наочно було видно про що йде мова в тексті.
Все життя працював з одним засобом прототипування, звик до нього і не бачить необхідності щось змінювати.	Необхідно оцінити ваш рівень володіння даним засобом. Якщо є можливість його використовувати — вперед. Якщо ні — аргументовано запропонувати альтернативи.
Не збирається оплачувати ще й ліцензію на запропоноване вами засіб.	В цьому випадку краще використовувати наявні корпоративні кошти, або безкоштовні альтернативи.

2. Час

Які обмеження по часу?	Що робити вам?
На фазу прототипування не закладено естімейт.	Навіть у цьому випадку я раджу постаратися зробити невеликі замальовки функціоналу. Нехай це буде приємним бонусом для замовника. Всі люблять подарунки. Плюс, таким чином, ви однозначно завоюєте прихильність замовника до себе і компанії, зокрема.
Часу для створення повноцінних прототипів катастрофічно не вистачає.	Робіть замальовки самого важливого і головного: не розтрачуйте зусилля на допоміжний функціонал, контент, зовнішній вигляд і т. д.

3. Володіння засобом прототипування

Які обмеження щодо володіння засобом?

Що робити вам?

Не стикалися раніше з обраним засобом прототипування.

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

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

Balsamiq	Axure RP
? простий інтерфейс	? більш професійний, великий функціонал
? швидке створення вайрфреймов	? промальовування дрібних деталей, займає час
? виглядає як намальований від руки	? прототип виглядає як готова система
? можна линковать сторінки	? можна линковать, налаштовувати події і абсолютно повністю імітувати поведінку реальної системи
? експорт в зображення, pdf формат	? експорт + можливість використовувати браузерную версію для розшарювання, яка розміщена в Axure cloud (надає презентабельності прототипу)
	? секьюрность при розшарювання проекту
	? командна робота
	? бібліотеки

Висновки

Важлива деталь при роботі з прототипами — крім створення прототипів потрібно також уміти правильно представляти їх. Кілька разів я ставала на одні і ті ж граблі і просто відправляла прототип на рев'ю замовнику або розробникам, ігноруючи стадію його презентації. Це невірний шлях. Нічого доброго з цього не виходило. Кожен сприймає по-своєму те, що бачить. Та й дивитися може не туди, куди треба було б. Тому крім створення прототипу подбайте і про його представлення.

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

Дякуємо за Гусака Наді Кушнір

Читайте також: «Прототипування для менеджерів: навіщо це потрібно і які бувають прототипи»

Опубліковано: 25/06/19 @ 10:00
Розділ Різне

SEO Блог