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

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

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

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

Пам'ятаю той день в деталях. Сутеніло... Менеджер проекту, сиділа якраз навпроти мене, запросив техлида. В кімнату увійшов хлопець. Його обличчя було злегка напружене і по ньому з легкістю можна було зрозуміти, що нічого доброго від нашої зустрічі він не чекає, але нотки інтриги все ж були присутні судячи з питальним зморшки на лобі. Менеджер коротко розповів йому, що ось, мовляв, у нас тут новий проект, благословив в дорогу, і наостанок урочистим рухом мишки скинув специфікацію на 152 сторінки на пошту бідоласі. Єдине, що промовив той, вже покидаючи нашу кімнату: «Сподіваюся, там хоч не 200 сторінок читати, як минулого разу?»

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

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

По правді кажучи, та ситуація раз і назавжди дала мені зрозуміти, що так робити не можна. Не можна ускладнювати життя розробникам, команді і замовнику, в кінці кінців. Знайомство з проектом повинно бути приємним і цікавим. Це як перше побачення. Від нього залежить все.

З тих пір я переглянула підхід до створення вимог, включивши в їх розробку прототипування як обов'язковий етап. Це дозволяє всім стейкхолдерам швидко зрозуміти ідею проекту і дати свій фідбек, що дуже важливо для запуску успішного продукту. Ясна річ, що багато залежить від проекту, побажань замовника, ну і ще тисячі речей: прототипування може бути не включено в естімейт, на нього може не бути часу, бажання і т. д. В цих випадках я раджу використовувати трохи принципів з політики nudge (як правильно підштовхувати стейкхолдерів до «гарних» рішень), ну або хоча б намагатися в умовах обмежених ресурсів робити будь-які замальовки системи — на серветці, у блокноті, і прикріплювати це до вашої документації. Це однозначно набагато краще, ніж нічого.

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

Піднімаємо руки на користь прототипування

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

Отже, моє основне завдання — остаточно переконати вас у користь прототипування і схилити використовувати прототипи на своїх проектах. Наведу кілька важко оспорюваних фактів:

Відносно замовників:

Щодо розробників:

Якщо проаналізувати вищеперелічене, то маємо:

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

Отже, ось так робити не можна:

а ось так — не можна:

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

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

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

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

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

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

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

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

2. Позначаємо весь функціонал

Навіщо? — Замовник і розробники повинні розуміти, що їх чекає.
Отже:

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

3. Робимо коментарі в прототипі

Рис. Використання коментарів в прототипі

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
Розділ Різне

Рекомендуємо:

«З компанії стало йти в два-три рази менше людей». Як Genesis перебудував процес найму
Ruby/Rails дайджест #30: реліз Ruby 2.7.0-preview1, відео доповідей конференції RailsConf 2019, продуктивність JIT
iOS дайджест #32: Special - WWDC'19
Як в KeepSolid розробили LezGo — навігатор для спільних автоподорожей
SAP Commerce Cloud: що вам треба знати про роботу з платформою