Дизайн-мислення, Round Robin та брейншторми — як отримувати менше правок й ефективно розв‘язувати завдання

Мене звати Денис Яровий, зараз я обіймаю посаду Payments Product Manager у студії Plarium Ukraine. До переходу на нову позицію я 6 років був UX-дизайнером і займався внутрішніми сервісами для співробітників. За цей час спроєктував адмін-панель для агентів підтримки, систему запуску внутрішньоігрових подій, інструменти для оброблення відгуків і запуску Push-нотифікацій тощо.

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

До Plarium я працював розробником в аутсорс-компанії. У якийсь момент я зрозумів, що мене не задовольняє результат моєї роботи — здавалося, що я писав класний код, але кінцевий продукт виходив зовсім не таким класним. А хотілося бачити результатом своєї роботи щось вартісне.

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

Моє бачення змінили три речі: досвід, книга The Inmates Are Running the Asylum і курс із дизайну на Coursera. На курсі я познайомився зі справжнім дизайн-циклом. Це коли ти починаєш з розуміння проблеми й далі проходиш за кожним етапом, про які я розповім пізніше. Спробувавши такий підхід, я зрозумів, що хочу займатися тільки цим.

Як ми звикли розв’язувати проблеми: метод перебирання варіантів

Інструмент problem-solving, доступний навіть голубам

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

Він полягає в тому, що ми підбираємо шляхи виконання завдань один за одним. Спробували один спосіб розв’язання проблеми. Він не підійшов — пробуємо далі, допоки знайдемо дієвий варіант.

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

У процесі експерименту голубів помістили в коробку з автоматизованою годівницею — коли птах клює кнопку, висипається корм. Потім умови змінили, і корм перестав сипатися після кожного натискання. Голуб натискав на кнопку — корм не падав.

Голуб починав повторювати дії, які він робив перед тим, як натискати на кнопку. Бо нові умови були незрозумілі, і птах починав перебирати: «А що, коли я на одній лапці постою?», «А що, коли я поверну голову?».

Тому цей метод є найрозповсюдженішим інструментом розв’язання різноманітних завдань — від отримання корму до робочих тасків.

Недоліки методу

Але метод перебирання варіантів неідеальний і має певні недоліки.

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

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

Але є метод, який справляється з проблемами більш ефективно й менш ресурсозатратно. Це дизайн-мислення.

Як працює дизайн-мислення: підхід, орієнтований на людину

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

«Дизайн-мислення — це орієнтований на людину підхід до інновацій, який спирається на набір інструментів дизайнера для інтеграції потреб людей, можливості технологій і успіх бізнесу».

Цей підхід складається з трьох основних етапів.

Джерело: IDEO

Розуміння завдання

Крок 1. Знайти, кому це потрібно і навіщо

Коли людина приходить із завданням чи ідеєю, перше, що я роблю, ставлю запитання: «Щоб що?». Відповідь дає змогу зрозуміти, чи принесе розв’язання цього питання якусь користь і чи треба взагалі над цим працювати. Інколи замовник може прийти з готовим рішенням, але це рішення може не розв’язувати справжню проблему або розв’язувати, але не ефективно. У такому разі треба шукати першопричину — «саме ту проблему», для якої замовник придумав рішення.

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

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

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

Але бувають випадки з неочевидною вигодою, яку треба досліджувати глибше за допомогою запитань. Це дає змогу знайти першопричину і «полікувати» саме її, а не симптоми.

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

Дизайнери-початківці кажуть: «Подивлюся, чи влазить ця кнопка», «Подивлюся, у якому стилі можна зробити кнопку». Вони починають одразу думати про те, як можна цю фічу додати. Але навіщо вона потрібна взагалі? Треба дізнатися.

Замовники кажуть: кнопка потрібна, щоб завантажувати таблицю.
— Окей. А навіщо?
— Щоб потім можна було цю таблицю занести в Excel і побудувати графіки.
— Окей. А навіщо?
— Бо ці графіки найкраще візуалізують показники, які потім потрібно показати менеджеру.
— Окей. А навіщо?
— Менеджер ухвалює рішення на основі показників, які отримує з місячного звіту.

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

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

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

Крок 2. Провести польові дослідження

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

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

Наприклад, ми робили новий продукт для системних адміністраторів. Зібравши детальну інформацію про завдання, я прийшов до них на робоче місце і побачив великий вайтборд на стіні. Там вони трекали свої релізи та їх статус.

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

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

Після цього переходимо до практики.

Пошук і вибір рішення

Крок 3. Розфокусувати увагу й знайти найбільшу кількість рішень

Щойно завдання чітко описано, людина автоматично починає думати над рішенням. Обмірковувати: «А що, коли так спробувати? Або так?». Це той самий метод перебирання варіантів, недоліки якого ми описали вище.

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

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

Є багато методів штурму рішень. Розкажу про два, які я найактивніше використовую в роботі.

Round Robin

Це колективний спосіб, який полягає в доопрацьовуванні ідей одне одного.

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

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

Ілюстрацію підготував я сам

Брейншторм

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

Наприклад, на дошці в мене є конкретно сформульоване запитання, яке починається з «Як ми можемо...». Далі я усно переказую деталі задачі.

Завдання моїх колег — придумати щонайменше три ідеї, як ми можемо зробити це. На мозковий штурм у них є 10 хвилин.

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

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

Крок 4. Застосувати критерії до згенерованих варіантів

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

Ми оцінюємо наші варіанти за двома критеріями:

  • impact — це те, наскільки ідея потенційно принесе гроші або заощадить їх;
  • effort — скільки ресурсів треба витратити для втілення ідеї в життя.

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

З effort найкраще впораються девелопери, тому що вони будуть потім це розробляти й можуть дати попередню оцінку трудовитрат. Може, щось взагалі неможливо реалізувати або це потребуватиме років роботи й у цьому немає сенсу.

Крок 5. Вибрати найкращий варіант

Далі ми з колегами відбираємо варіанти рішення за критеріями impact та effort. На штурм-колі я беру ідею, озвучую її та запитую: «Як думаєте, наскільки добре цей варіант розв’язує нашу проблему?». І ми оцінюємо impact таким чином. Потім питаю: «Наскільки трудовитратною є реалізація?». І ми оцінюємо effort. І так по черзі обговорюємо кожну ідею з тих, що ми згенерували.

Після цього всі варіанти ми візуалізуємо в матриці 2×2. Наприклад, так виглядає матриця impact/effort.

Джерело: адаптовано з build.co

Це дає змогу одразу побачити, що варто робити 100%: це те, у чого високий impact і низький effort. Також бачимо, що можна взагалі не робити й що треба ще додатково оцінити та проговорити, бо завжди є сіра зона, у якій середній impact і середній effort.

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

Перевірка та впровадження рішення

Крок 6. Перевірити гіпотезу

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

Перевіряти гіпотези й робити прототипування треба до того, як це рішення віддали в розроблення.

Уявімо таку ситуацію: ви працюєте над інтернет-магазином. У вас є гіпотеза, що, додавши на сторінку продукту відгуки про нього, ви покращите конверсію.

Як перевірити цю ідею, не розробляючи бекенд? Можна попросити реальні відгуки покупців або зробити фейкові на цій сторінці — і просто зверстати блок без системи додавання справжніх відгуків. І потім виміряти, чи вплинуло це на конверсію. Так можна перевірити, працюють відгуки чи ні.

Є цікавий приклад у компанії EveryPlate. Усе почалося з того, що бізнесмени з США вирішили зробити доставлення рецептів і нарізаних продуктів, які вже готові до приготування. Була гіпотеза, що в багатьох домогосподарок є проблема: вони не знають, що приготувати. Засновники майбутньої компанії EveryPlate подумали: «А що, коли ми будемо, по-перше, давати список рецептів на тиждень і, по-друге, привозити всі продукти вже підготовленими до приготування за цими рецептами?».

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

Якщо ваша гіпотеза не підтвердилася, повертайтеся на попередній етап, виберіть інший варіант із високим impact і низьким effort та протестуйте його.

Корисні ресурси про дизайн-мислення

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

Добірка корисних статей з дизайн-мислення від Nielsen Norman Group — компанії, що займається проєктуванням та UX. Також на їхньому сайті є цікавий формат: у коротких відео на 3-5 хвилин вони розкривають одну тему, зокрема те, що стосується дизайн-мислення.

Design Thinking 101 — з цього подкасту можна зрозуміти, як працює дизайн-мислення в різних сферах бізнесу, дізнатися цікаві кейси й корисні поради для застосування підходу.

Design Thinking Handbook — книга Елі Вулері, директора відділу дизайнерської освіти в компанії InVision. Матеріал допоможе детальніше заглибитися в те, як застосовувати дизайн-мислення на практиці.

Чек-лист виконання завдань за дизайн-мисленням

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

1. Поставити запитання людині, яка приходить із завданням.

  • Чого ми хочемо досягти? Тут можна також використовувати метод «5 чому» — запитувати «чому», поки не зʼясуєте першопричину. Можливо, ви зрозумієте, що насправді треба розв’язувати зовсім іншу проблему.
  • У чому користь для бізнесу? Що це принесе компанії?
2. З’ясувати потреби користувачів будь-яким наявним методом. Якщо у вас є доступ до користувачів, спробуйте глибинні інтерв’ю та спостереження. Якщо немає, то таку інформацію також можна отримати з відгуків і звернень у сапорт.

3. Отримати всі відповіді й сформулювати завдання в одне речення.

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

5. Відібрати з цього пулу рішень найкращі варіанти за критеріями impact та effort. Для наочності можна це візуалізувати схематично.

6. Обрати одне найкраще рішення за показниками та, якщо це можливо, зробити прототип, щоб перевірити гіпотезу.


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

👍ПодобаєтьсяСподобалось25
До обраногоВ обраному14
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Написано гарно, доволі змістовно. Маю кілька уточнень для уникнення холіварів:
1. «...підхід, фреймворк» — тобто НЕ методологія, а спроба систематизувати набір рекомендацій і адаптувати їх під найбільшу можливу кількість ситуацій.
2. В статті описана не «магічна пігулка», а набір можливостей «рекомендацій» для швидкого дослідження, тобто це все можна аналізувати і робити довше, складніше, жорсткіше... Проте не завжди треба :)
3. Дизайн часто суб’єктивний — не варто обмежуватись тим, що описав автор, проте можна брати як основу.

Ну і на останок:
1. Пріоритезація або «Вибрати найкращий варіант» — основою підходу є система суб’єктивного оцінювання, тобто якщо Ви зміните фокус — у Вас зміниться система оцінки і (відповідно) обирати потрібно інші варіант.
2. Банальність: частіше за все, якщо Ви знаєте для кого Ви вирішуєте проблему (і що це за проблема) — це автоматично вибудовує частину логічного процесу. Старайтесь просто систематизувати те, що Ви робите (так, творчий гармидер теж має місце бути але треба бути особливо уважними :)) .

Дякую за змістовний коментар, він класно доповнить статтю :)

Дуже корисна та цікава стаття!

Дякую, радий що ви знайшли щось корисне для себе :)

Крутая статья! Задела за живое, так сказать, потому что абсолютно на каждой работе я задаюсь вопросом «да кому это вообще нужно?» и «ну и каковы результаты внедрения этого?».

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