Робота дизайнера рідко йде по прямій. Задача не перетворюється на макет одним рухом: спершу треба зібрати контекст, звузити його до рішення, випустити, подивитися на дані й повернутися на початок. Дизайн-мислення (design thinking) — це вміння свідомо проходити це коло, замість стрибати від першої ідеї у Figma.

Дизайн-мислення: модель подвійного діаманта

Дизайн-мислення — це підхід до вирішення задач, де ви спершу розширюєте погляд, а потім звужуєте його до рішення. Це базовий спосіб мислення в UX/UI дизайні. Модель для цього малюють як два діаманти поруч. Перший діамант — простір проблеми: ви набираєте якомога більше контексту, спостерігаючи за людьми й читаючи дані, а тоді сходитеся до чіткого формулювання того, що взагалі треба вирішити. Другий діамант відповідає за простір рішення: знову розходитеся у варіантах, потім обираєте той, який підете втілювати. Звідси й назва: подвійний діамант (double diamond).

Головне правило моделі просте. Не проскакуйте з простору проблеми у простір рішення завчасно. Спокуса зробити це велика: щойно прилітає задача, руки самі тягнуться малювати екрани. Але поки проблема не розібрана до кінця, ви не бачите її ширини й ризикуєте вирішувати геть не те. Тому в дизайн-мисленні послідовність завжди однакова: спочатку opportunity, потім problem discovery, і лише тоді solution discovery.

Джерела задач: звідки дизайнер дізнається, що робити

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

• Користувачі напряму. Інтерв'ю, опитування, тестування. Сюди ж належить user shadowing, коли ви просто мовчки спостерігаєте, як людина користується продуктом. Це якісні дані, які видно на власні очі.
• Внутрішні канали. Рев'ю в App Store, звернення в підтримку, фідбек від сейлів, внутрішнє (коридорне) тестування. У B2B саме сейли часто знають про продукт найбільше: і сильні його місця, і найболючіші.
• Аналітика. Хітмапи, записи сесій, продуктові метрики. Вони фіксують, як люди поводяться насправді.
• Бізнес. Стейкхолдери й задачі бізнесу: стратегічний контекст від фаундерів і власників продукту.

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

Сім етапів: від розбору задачі до релізу

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

1. Розбір задачі. Розкладаєте її на дрібніші частини, щоб зрозуміти проблематику вглиб.
2. Збір інформації: наявної і бракуючої. Головне тут: побачити, де саме інформації бракує. Наявне ви й так знаєте.
3. Формалізація задачі і скоупінг. Обсяг, підзадачі, склад команди, метрики, які будете міряти.
4. Створення рішення. Формулюєте гіпотезу й будуєте під неї потік. 
5. Збір фідбеку: внутрішнього і зовнішнього. Колеги, тестувальники, розробники. Перевіряєте, чи все працює на всіх платформах.
6. Підтримка розробки і тестування перед релізом. Дизайнер лишається поруч із розробкою до самого релізу.
7. Оцінка релізу і наступні кроки. Дивитеся на дані й вирішуєте, куди рухати далі.

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

Вартість і цінність кожного рішення

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

Звідси й ставлення до MVP. Перша версія не мусить бути гарною. Її завдання інше: якнайшвидше дати дані. Часто для перевірки ідеї не потрібен навіть програміст. Вистачає дизайнера, продакт-менеджера й умовного Telegram-бота, що приймає запити й повертає відповідь. Так починали в Lezo: повноцінний інтерфейс з'явився лише десь через рік, а саму ідею спершу гоняли через простого бота, поки команда перевіряла, чи взагалі є попит. І будували спочатку під компанії: гроші приносили саме вони.

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

Сильний кейс: рішення, підтверджені цифрами

Готовий процес найкраще видно у кейс стаді. І сильний кейс стаді вартий уваги тоді, коли кожне рішення прив'язане до виміряного результату, а не до того, що «стало гарніше». Візьмімо продукт, над яким працював лектор: Rohlík, чеський сервіс доставки продуктів.

Почнемо з секції рецептів. Вона відкрила новий сценарій використання (jobs to be done): людина заходить по цілий рецепт і докуповує все за ним. Це піднімає повернення. Поряд команда додала варіативність: дорожчий і дешевший варіант того самого продукту та кнопку, що вкидає всі інгредієнти рецепта в кошик одним дотиком.

Далі йдуть шопінг-листи. У найпростішому вигляді це вибрані товари, зібрані в окремі списки, які купуються одним дотиком. Кнопка кількості тут навмисно не кидає товар у кошик автоматично. Список збирають, щоб повертатися до нього знову. Згодом зверху наросла функція Plan a weekly list: задаєте період, і список сам падає в кошик.

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

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