Окт. 22

Як проводити Design Sprint 2.0, або Створюємо та тестуємо продукт

Я співзасновник і Team Lead в IT-компанії Uptech і Plai, а також сертифікований фасилітатор Design Sprints. Хочу поділитися з вами досвідом, як валідувати свою ідею чи побудувати власну концепцію за допомогою Design Sprint 2.0. Також розповім про те, як ми вирішили підвищити ефективність роботи нашої команди завдяки поліпшеному обміну зворотним зв’язком і як Design Sprint допоміг нам досягти цієї мети. Підсумувавши наші досягнення, ми створили прототип зручного для користувача застосунка й зібрали конструктивні відгуки про нього.

Ця стаття буде корисна як продакт- і проджект-менеджерам, так і дизайн-командам, яким треба швидко провалідувати свої гіпотези.

Design Sprint 5-day Schedule

То що ж таке Design Sprint 2.0

Design Sprint — це 5-денний процес, який дає відповіді на критичні бізнес-питання за допомогою дизайн-мислення, прототипування й тестування різних ідей разом з користувачами. Він призначений для швидкого розв’язання складних завдань, створення нових продуктів або ж удосконалення наявних. Цей процес розробили Джейк Кнапп, Джон Зерацький і Браден Ковіц у Google Ventures та описали в книжці «Спринт». Багато компаній, зокрема Google, Uber, Slack і Lego, використовують Design Sprint для успішного виконання цілої низки завдань.

Design Sprint 2.0 — це оновлений 4-денний процес, розроблений в AJ&Smart, що ґрунтується на оригінальних принципах попередньої версії. У ньому було лише зоптимізовано початковий процес, який тепер триває на день менше. Наша команда пройшла в онлайн-режимі майстер-клас із Design Sprint 2.0, прочитала чи не половину інтернет-ресурсів про спринти й почала їх застосовувати, щоб на власній практиці дізнатися про найефективніші методи впроваджування цього підходу.

Підготовка

Щоб провести Design Sprint ефективно, а не просто повеселитися, треба ретельно підготуватися.

Процес

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

Модель «Double Diamond»

Загалом весь процес Design Sprint відповідає фазам моделі «Double Diamond», за якою спочатку ми вивчаємо й намагаємося максимально зрозуміти сферу, яку досліджуємо (розфокусування й розгалуження на діаграмі), тоді зосереджуємося на конкретних проблемах (концентруємось і рухаємось до точки фокусування) і больових точках (pain points). Після цього розробляємо різні рішення для подолання вже визначених проблем (розфокусування й розгалуження на діаграмі), тестуємо ці рішення та вибираємо з них найкращі (знову концентруємось і рухаємось до точки фокусування).

День 1 (I частина) — знайомство команди й визначення проблеми: експертні інтерв’ю, заглиблення в проблему та генерування можливостей її розв’язання (через формування запитань HMW і Can We... та постановку Long-Term Goal), а також побудова map того, як функціонує продукт/сервіс (інший об’єкт Design Sprint) і як він взаємодіє з усіма причетними до нього учасниками.

День 1 (II частина) — генерування рішень за допомогою презентації ідей і вправи 4 Part Sketching.

День 2 — презентація рішень, що були підготовані напередодні, голосування й вибір найкращих з них. У другій половині дня — підготовка User Test Flow (схеми того, як користувач застосовує продукт/сервіс) і Storyboard (візуалізація всієї подорожі по продукту/сервісу з достатньою деталізацією та цілковитим узгодженням з тим, що входитиме до прототипу). Пошук користувачів для тестування рішень.

День 3 — прототипування рішення й дальший пошук користувачів для тестування.

День 4 — тестування розроблених рішень з користувачами. Вибір і пріоритетизація незначних змін, які потрібно внести в розроблений прототип на основі фідбеку від користувачів.

Щоб розібратися з усіма деталями процесу, ми спершу прочитали книжку «Спринт», а також використовували докладну інструкцію від AJ&Smart і переглядали їхні відео на YouTube, щоб урахувати всі поради й рекомендації щодо кожної вправи.

Ідея

Важливим складником підготовки є вибір правильної ідеї або проблеми, яку потрібно розглянути під час спринту. Вона має бути досить великою, щоб залучити до цього процесу групу людей, які працюватимуть не покладаючи рук усі 4 дні. Утім не надто глобальною, щоб можна було створити прототип за 1 день.

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

Найкраще Design Sprint застосовувати для розв’язання таких завдань:

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

Команда

У Design Sprint узяли участь такі члени команди (на фото зліва направо):

Андрій Бас — фасилітатор (немає на фото);
Діма Коваленко — керівник проекту й бізнес-експерт; ухвалював фінальне рішення під час Design Sprint;
Микола Мельник — дизайнер;
Галина Галкіна — Android-розробник.
Діма Домашенко — дизайнер;
Олег Кривицький — дизайнер.

Команда «Design Sprint»

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

Команда повинна звільнити свій робочий графік на весь період Design Sprint, щоб мати змогу на 100% зосередитись на проблемі, а не відволікатися на інші завдання.

Інструменти

Перед спринтом потрібно добре підготуватися. Забронювати кімнату для переговорів, підготувати блокноти для нотаток, наліпки, крапки для голосування, дошки, папір, фломастери, перекуси під час перерв... Весь список можна переглянути тут.

День 0. Перед Design Sprint

Перед спринтом ми провели дослідження ринку щодо наших конкурентів (як-от 15Five, Lattice, Culture Amp тощо) та підготували список плюсів і мінусів уже наявних рішень. Усі рішення конкурентів перевірили самостійно. Завдяки такій підготовці ми добре ознайомилися із цією сферою й були готові кинути їй виклик.

День 1. Визначте виклики й підготуйте рішення

Мета 1-го дня — з’ясувати, з яким саме викликом ми стикаємося, і створити кілька шляхів його розв’язання. Для цього провели інтерв’ю з експертами та сформували запитання «Як ми могли б...» (How Might We...).

Почали з інтерв’ю експертів. Оскільки ми самі мали бути користувачами рішення, яке збирались розробити, то вирішили зосередитись на власній компанії. Як експертів — людей, які працюють у цій галузі й розуміють проблему — запросили наших членів команди. Для правильного проведення такого інтерв’ю ми послуговувалися посібником групи Nielsen Norman.

Поки експерти розмовляли, решта команди записувала запитання «Як ми могли б...» (HMW). Мета цієї вправи — записати всі ключові проблеми, які турбують експертів. Після категоризації та голосування звузили низку наявних запитань HMW до найважливіших, серед яких:

Як ми могли б зменшити власні зусилля й ділитися зворотним зв’язком на місці за менш як 10 секунд?
Як ми могли б побороти страх і дискомфорт, щоб поділитися зворотним зв’язком?
Як ми могли б заохочувати культуру зворотного зв’язку?

Запитання HMW

Довгострокова мета

Після мозкового штурму й голосування треба виокремити 2-річну мету. У нас вона звучала так: «Кожна взаємодія в команді включає зворотний зв’язок».

Для вимірювання мети ми обумовили:

10% членів команди щодня беруть участь у надаванні зворотного зв’язку;
від взаємодії до зворотного зв’язку проходить менш як 1 день.

Sprint questions

Запитання «Спринту» схожі на запитання HMW, але вони мають конкретніший характер і формуються для команди Design Sprint передусім з метою допомогти визначити перешкоди, які можуть завадити в досягненні поставленої мети.

Нашими Sprint questions були:

Чи можемо ми усунути емоційні й психологічні бар’єри в колективі?
Чи можна зробити обмін зворотним зв’язком простішим, для того щоб члени команди мали змогу поділитися ним якнайшвидше?
Чи можемо ми розробити модель такої взаємодії, яка дала б змогу щодня збирати відгуки 10% членів команди?

Робота над Sprint questions

Map

Ми намалювали map, щоб допомогти візуалізувати user flow і мати повне уявлення про таку взаємодію. Розділили його на кілька важливих етапів: взаємодію, обмін зворотним зв’язком (де користувач долає важливий психологічний бар’єр), підготовка та обмін відгуком (або його одержання).

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

Map

Lightning Demos

Після обідньої перерви ми провели Lightning Demos. Мета цієї вправи — сформувати множину ідей, які згодом використовуватиме колектив для створення своїх рішень. Відомо, що чи не кожна нова ідея — це лише свіже поєднання кількох уже наявних. Щоб надихнутися й зібрати різноманітні рішення/ідеї, команда провела чудові дослідження та продемонструвала приклади того, як працюють інші продукти: monobank, Uber, сповіщення в iPhone, Google Calendar, Lattice, 15Five, Auchan тощо.

Кожен з названих продуктів містить цікаві рішення й ідеї, які можна імплементувати в нашому кейсі.

Команда працює над Lightning Demos

Скетч

Перший день закінчується генеруванням рішень, яке проводиться в 4 етапи. Перші три з них — Note-taking, Doodling і Crazy 8s — це вправи на візуальну розминку. Четвертий етап — це скетчинг, під час якого члени команди придумали власні концепції для нашого продукту, щоб згодом вибрати найкращий варіант для подальшого прототипування. Кожне з таких рішень складалося з 3 основних кроків, мало влучну назву й деталізоване пояснення. Не варто забувати про анонімність усіх концепцій, щоб наступного дня під час голосування члени команди не були упереджені у своєму виборі.

Концепція

Висновки першого дня

Перший день спринту є найважчим і найбільш насиченим як за кількістю різноманітних вправ, так і за фокусом, якого вони вимагають. Упродовж цього дня ухвалюється багато важливих рішень, тож саме тоді задається тон усіх наступних днів. Тому дуже важливо приходити на спринт підготованим!
Деякі труднощі в команди викликало розуміння Sprint questions і HMW questions. Здавалося, що це ті самі запитання. Згодом ми дослідили, що Sprint questions формуються радше в негативному контексті для роботи з перешкодами, а HMW questions ставляться натомість у позитивному контексті й націлені на досягнення мети (а не роботу з перешкодами). Ось розміщене хороше відеопояснення відмінності між цими двома видами запитань.
Під час роботи з map дуже легко заглибитись у деталі та змарнувати забагато часу. Мета map — дати загальне розуміння шляху користувача, тому ставте часові ліміти на всі вправи й строго їх дотримуйтеся. Не забувайте, що Design Sprint — це швидка валідація й рух уперед, а не знаходження «ідеального» рішення.
Після кожного дня важливо збирати команду і ще раз наголошувати, що було зроблено й чим можна пишатися, а також ділитися одне з одним зворотним зв’язком. Це підтримує мотивацію й допомагає оперативно розв’язувати проблеми (якщо вони є) та підвищувати ефективність роботи команди.

День 2. Проголосуйте за рішення і створіть розкадрування

Мета другого дня — вибрати рішення, яке команда має протестувати, і заповнити всі необхідні для цього деталі на Storyboard.

Презентація рішення

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

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

Наприкінці презентації кожної концепції фасилітаторові було б добре запитати: «Хто-небудь розмістив крапку в цій концепції щодо ідеї чи функції, про які я не згадував?» І справді, кілька разів виявлялося, що члени команди помітили пропущені фасилітатором ідеї. Такий підхід дає змогу всім членам команди бути на одній хвилі.

Презентація концепцій

Голосування

Опісля голосування на опитуванні «Straw Poll» (синхронному голосуванні) команда зробила свої ставки за найкращу концепцію. Усі четверо учасників команди проголосували за одну й ту саму ідею. Пізніше керівник проекту також вибрав саме ту концепцію.

Ключова ідея цієї простої та добре продуманої концепції полягала в тому, щоб почати зі сповіщень, які спонукатимуть користувачів давати відгуки. Застосунок пропонує кожному користувачеві певну групу, яка складається із членів його команди та з якою він може поділитися зворотним зв’язком. У такому разі користувач повинен провести по фотокартці іншого члена команди пальцем уліво, щоб пропустити, або вправо, щоб надати зворотний зв’язок (так само, як у Tinder). Щоб залишити відгук, треба пройти кілька дуже простих кроків. До того ж до системи можна було додати власні фільтри, щоб вона могла автоматично підлаштовуватися під потреби команди.

Найкраща ідея

User Test Flow

Під час вправи User Test Flow кожен член команди прописав 6 кроків, які користувачі програми повинні виконати з моменту входження в неї й аж до результативного обміну відгуками. Ми представили одержані User Test Flow і проголосували за найкращий варіант. Цей крок призначений для того, щоб полегшити й пришвидшити наступний етап.

User Test Flow

Storyboard

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

Згодом ми розмістили кроки користувача у 8 комірках і почали малювати екрани концепції. Вирішили повторно намалювати їх, щоб оновити кілька кроків. Загалом на Storyboard у нас пішло 3 години, під час яких ми також обдумували різні рішення та підходи. Наприкінці цього дня у нас виявилось аж 11 екранів (замість очікуваних 8), але деякі з них були доволі простими.

Storyboard

Висновки другого дня

Може здатися, що вправа з оглядом усіх концепцій дещо показова. І хоч усі роботи презентуються як анонімні, та завдяки почерку, особистому стилю тощо майже всі члени команди розуміють, де чий концепт. Проте дистанціювання концепту від особистості, тобто без прив’язки до автора, все-таки дає змогу краще сфокусуватися на самій роботі. Це допомагає найкращим ідеям вигравати, що дуже важливо для результативності самого Design Sprint.
Вправа User Test Flow є насправді допоміжною перед вправою Storyboard. Вона допомагає краще сфокусувати команду навколо шляху користувача в майбутньому концепті. Ця вправа показує, що навіть після двох днів роботи над концепцією у членів команди можуть бути різні бачення.
Під час Storyboard важливо уникати групового прийняття рішень чи надиктовування тексту, адже в такому разі можна очікувати лише посереднього результату. Найефективніше — розділити завдання між людьми або невеликими командами, а потім об’єднати результати їхньої роботи. Важливо також підготувати весь супутній текст/контент для прототипування наступного дня.

День 3. Прототип

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

Паперовий прототип

Паперовий прототип — це найпростіший із можливих підходів для тестування майже будь-якої програми. Розділивши роботу між усіма членами команди, за 1 годину мали вже готовий прототип. Завдяки такій злагодженій роботі ми відчули єдність колективу і радість від досягнення мети. Цей прототип протестували двічі: між членами команди Design Sprint (Андрієм і Миколою) та з одним зовнішнім користувачем (Оленою). Таке швидке тестування додало всім упевненості перед наступним днем.

Під час тестування склали список майбутніх удосконалень для паперового прототипу й тих місць, де в користувачів виникала плутанина. Такі вдосконалення помітили на стікерах, які розмістили на Storyboard у відповідних частинах. Після цього проголосували за 4 найважливіші зауваження й удосконалили Storyboard на основі вибраних пропозицій.

Паперовий прототип

Цифровий прототип

Оскільки в нас уже були детальний Storyboard, паперовий прототип і 3 дизайнери в команді, працюючи одночасно, приблизно лише за одну годину ми створили на Figma цифровий прототип.

Цифровий прототип

Пошук і графік інтерв’ю з користувачами

Протягом цього дня Діма Д. працював над плануванням і сценарієм інтерв’ю користувачів. Оскільки наш застосунок розроблявся для внутрішнього використання, було вирішено запросити 4 членів нашої команди та 2 зовнішніх експертів. Для останніх розмістили відповідний пост у Facebook. Дуже багато користувачів зголосилися допомогти в тестуванні, тож ми розпланували дзвінки. Незважаючи на те, що рекомендується провести 5 інтерв’ю, вирішили провести їх 6, щоб одержати цінну інформацію від більшої кількості людей.

Висновки третього дня

Етап паперового прототипу дає дуже хорошу мотивацію й значно поліпшує його лише за якусь годину-дві. Хоча цього етапу й немає в офіційній версії Design Sprint, ми таки рекомендуємо його проводити.
У команді важливо мати дизайнера, який відповідатиме за розроблення цифрового прототипу. Без такої людини результат вийде розмитим.
Підготовку до інтерв’ю й набір тестерів краще почати ще напередодні. Якщо вам треба знайти користувачів з інших міст/країн, для цього добре підходять реклама у Facebook або Craigslist. Перед самим інтерв’ю важливо мати весь його сценарій і попрактикувати співбесіду один з одним для виявлення слабких місць.

День 4. Тестування прототипу з користувачами

Мета четвертого дня — провести тестування прототипу, одержати зворотний зв’язок і прийняти рішення про наступні кроки щодо продукту.

Інтерв’ю

Щоб розробити остаточні тести й ретельно підготуватися до співбесіди, ми розпочали роботу на годину раніше. Намалювали на дошці велику таблицю з іменами всіх інтерв’юєрів і переліком функціоналу, про які хотіли одержати відгук. Перше інтерв’ю було заплановане на 11-ту ранку. Воно дуже допомогло нам вникнути в цей процес і налаштувати правильний відеозапис. Після таких інтерв’ю вам може знадобитися близько 2 годин для виправлення виявлених вад і вдосконалення обраного підходу або прототипу.

Інтерв’ю з користувачем

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

Результати тестування прототипу

Висновки четвертого дня

Брати інтерв’ю в користувача доволі важко. І 6 інтерв’ю на день — це надто багато, тому 5 було б таки достатньо.
Важливо залучати до проведення інтерв’ю всіх членів команди (а не тільки дизайнерів чи продуктових менеджерів). Розробники, біз-деви чи інші експерти також зможуть це робити ефективно після короткого інструктажу більш досвідчених колег і за наявності скрипту. Це дасть усій команді змогу краще усвідомити цінність спілкування з користувачами й мотивуватиме робити це й надалі. Такі вправи формують емпатію і розвивають продуктовий підхід.
Перед тестуванням самого прототипу важливо встановити хороший контакт із користувачем, знайти з ним спільні теми, трохи пожартувати тощо. Наприклад, коли ми одержуємо підтвердження, що дзвінок можна записати, то інколи жартуємо, що «викладемо цей дзвінок на YouTube і надішлемо співбесіднику публічне посилання». Клієнти сміються, адже розуміють, що це неможливо.
Після 4-го дня спринту команда буде дуже втомлена. Це чудовий час, щоб розрядити обстановку і відсвяткувати результат. Подякуйте всій команді за хорошу продуктивну роботу. Вони точно це заслужили!

5 день. Після Design Sprint

Наступного тижня після Design Sprint ми згрупували відгуки користувачів у категорії/загальні фітчі. Потім за допомогою крапок проголосували за найважливіші зміни, які потрібно внести (за червоні чи сині стікери).

Опісля сформували 14 фітчів, які можна було реалізувати. Спершу намалювали шкалу впливу й зусиль і розмістили картки у відповідному масштабі — залежно від того, наскільки вони складні для виконання та як вплинуть на програму. Наприкінці обвели групу карток у верхньому лівому куті (найменше зусиль, найбільший вплив).

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

Команда Design Sprint

Підсумок

Нашій команді сподобався процес Design Sprint. Багато продуктових команд розповідає про Design Thinking та інші модні теми, але мало хто замислюється над тим, як застосувати їх до реальних проектів. Design Sprint — це дуже практичний і покроковий процес застосування принципів Design Thinking для розв’язання складних завдань і підготовки нових продуктів. Такий підхід створює належну атмосферу в колективі для розвитку творчого мислення у розв’язанні проблем. Ми задоволені цим підходом до розроблення продукту та його кінцевим результатом.

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