Як я переосмислив створення AI-агентів для корпоративних клієнтів OneReach.
ПРОЄКТ #2
2023–2026
No-Code Agent Builder
Роль
Провідний і єдиний продуктовий дизайнер
Команда
1 PM, 7 розробників, 1 QA, 3 розробники рішень
Терміни · Платформа
2023–2026 · B2B enterprise, веб
Ключові результати
Швидші запуски для клієнтів
Клієнт із ритейлу запустився за кілька днів, а не тижнів, бо почав із готового агента.
Зрозуміло, з чого почати
Нові користувачі перестали питати «З чого почати?». Дашборд їм це показує.
Менше часу на пошук налаштувань
Розробники рішень кажуть, що з новим конструктором «працювати набагато легше».
Контекст
OneReach.ai переводила своїх корпоративних клієнтів зі скриптових чат-ботів на AI-агентів. Старий підхід давав низький відсоток вирішених запитів, велике навантаження на підтримку й надто складні дерева логіки. Саме Agent Builder мав зробити цей перехід можливим.
Але продукт швидко переріс свій MVP. Щоб створити агента, доводилося копатися в документації, а іноді й писати GraphQL. Навіть наші власні розробники рішень, експерти, які створюють агентів для клієнтів, гаяли час на пошук налаштувань і перевірку документації. Кожне повільне створення агента означало повільніший запуск для клієнта. А деякі клієнти хотіли створювати частини рішень самостійно, у власних акаунтах, тож інструмент мав бути достатньо простим і для них. Водночас конкуренти пропонували схожі продукти, з якими було легше почати.
Я прийшов у проєкт як єдиний дизайнер, щоб зробити створення агентів швидшим і простішим: насамперед для наших розробників рішень, а також для команд клієнтів, які працюють поруч із ними.
Етап 1
Коли я почав, Agent Builder ще був MVP. Нові функції постійно додавалися, і структура їх уже не витримувала. Для деяких флоу потрібен був GraphQL, а більшість назв була написана для інженерів.
Я поговорив з нашими активними користувачами й зібрав близько 18 больових точок. Більшість із них зводилася до трьох речей:
Важко почати. Люди тримали документацію відкритою в іншій вкладці, навіть щоб створити простого агента.
Важко щось знайти. Навігація не допомагала зрозуміти, де ти зараз.
Важко відкотити зміни. Не було способу зберегти версію чи скасувати зміну.
Гіпотези
Тож я зробив три ставки:
Допомога всередині продукту
Якщо додати підказки й короткий тур, користувачам не доведеться йти в документацію.
Сховати складне
Якщо залишити на головному екрані лише основні налаштування, а решту перенести у вкладку «Advanced», новачки працюватимуть швидше.
Нехай перший варіант зробить AI
Якщо AI-асистент створює базового агента з короткого опису, ніхто не починає з чистого аркуша.
Ми так і не виміряли, наскільки допомогли підказки. Згодом їхню роль перебрали AI-асистент і дашборд з Етапу 2.
Ми також додали історію версій, тож користувачі нарешті могли зберігати зміни й відкочуватися.
AI-асистент виявився найважливішою зміною всього проєкту. Але тоді я ще про це не знав.
Вкладка «Advanced» здавалася чистим рішенням. Вона прибрала шум із головного екрана. Але водночас непомітно поділила наших користувачів на дві групи: Basic і Pro.
Я побачив цю проблему лише в другому раунді досліджень.
Моя думка
Перші припущення часто бувають хибними, і це нормально. Рання перевірка на реальних користувачах варта більше, ніж місяці досліджень наперед. У цьому й суть MVP: швидко вчитися, мало витрачати й вкладатися лише в те, що працює.
Етап 2
Продукт продовжував рости, і питання ставало складнішим: що насправді вважати «Advanced»? Користувачам доводилося пам’ятати, де що лежить. Варто було відійти на каву, і вони знову губилися.
Цього разу я хотів почути менш технічних користувачів, а не лише досвідчених розробників, які знали інструмент напам’ять. Я почав з опитування, але відповіли небагато, і воно нам мало що дало. Тож я повернувся до інтерв’ю.
Моя думка
Чесно, мене трохи засмутило, що відповіло так мало людей. Але опитування — це лише інструмент. Якщо не вдається отримати кількість, роби ставку на якість. Інтерв’ю показали, як люди насправді мислять, і робочі процеси, яких ми зовсім не очікували.
Саме тоді все склалося. А що, як поділ на Basic і Pro взагалі не мав сенсу?
Щоб перевірити це, я провів відкритий card sorting (картковий сортинг) із 6 користувачами. Вони самі групували функції й давали назви групам. Потім я провів tree testing із 3 іншими користувачами, щоб перевірити нову структуру.
Користувачі групували функції за контекстом, а не за складністю.
Що ми дізналися:
Налаштування «Advanced» не були просунутими. Прості налаштування були сховані, а справді складні — розкидані по всьому інтерфейсу.
Користувачі мислять контекстом, а не рівнем навичок. Функції, які вони вважали пов’язаними, жили на різних рівнях нашої навігації.
Ніхто не знав, як виглядає «готово». Користувачі не розуміли, з чого почати і чого бракує до релізу.
Розмови з нашими розробниками рішень додали ще одне відкриття: вони щоразу створювали тих самих агентів з нуля для різних клієнтів.
Ці висновки привели до трьох змін.
Що ми запустили
Гіпотеза
Якщо згрупувати налаштування за контекстом, а не за рівнем навичок, користувачі знаходитимуть їх з першої спроби.
Навіть після першого редизайну користувачі все ще губилися в пошуках налаштувань. Card sorting показав чому: поділ на Basic і Advanced не відповідав тому, як люди думають про створення агента.
Тож я перебудував навігацію довкола контексту, а не рівня навичок. Тепер налаштування розташовані там, де користувачі очікують їх знайти, а основні категорії йдуть першими.
Після релізу розробники рішень сказали нам, що із сервісом стало набагато легше працювати. Деякі категорії досі мають технічні назви, тож дещо ще треба вивчити, але набагато менше, ніж раніше.
✓ Здебільшого підтверджено
Над назвами ще треба попрацювати.
Гіпотеза
Якщо перший екран показує, що потрібно готовому агенту, користувачі знатимуть, з чого почати і чого бракує.
В інтерв’ю постійно звучало одне питання: «Я не знаю, з чого почати і чого достатньо, щоб агента можна було запустити». Ніхто не міг сказати, як виглядає повністю готовий агент.
Тож я перетворив перший екран на дашборд із покроковим налаштуванням і чеклистом швидкого старту. Він показує лише те базове, що потрібно агенту для запуску, а кожна картка веде просто на потрібну сторінку налаштувань.
Після запуску нові користувачі перестали питати, з чого почати. Більшість із них залишалися на цьому першому екрані: спілкувалися з AI-асистентом і дивилися, як змінюється дашборд, поки їхній агент набирав форми.
✓ Підтверджено
Користувачі бачили, з чого почати і чого бракує.
Гіпотеза
Якщо ми запропонуємо готових агентів, команди адаптуватимуть їх замість того, щоб будувати з нуля, і запускатимуться швидше.
Спілкуючись із командами клієнтів, я дещо помітив: вони часто копіювали агента, який уже працював, і змінювали його, замість того щоб створювати нового. Їм було простіше редагувати, ніж починати з чистого аркуша.
Тож я спроєктував бібліотеку найпопулярніших готових агентів, дій і каналів. А ще я наполіг на одній речі: дати кожному агенту характер. Кожен агент із бібліотеки отримав аватар, ім’я і своє місце в UI. Я хотів, щоб створення агента відчувалося живим.
Клієнт із ритейлу запустив свого агента на основі шаблону за кілька днів замість тижнів.
✓ Підтверджено
Команди адаптували готових агентів замість того, щоб починати з нуля.
Вплив
Для розробників рішень
Вони витрачають менше часу на пошук налаштувань і можуть почати з шаблону, а не будувати кожного агента з нуля.
Для клієнтів
Швидші запуски, бо команди починають із готового агента, а не з чистого аркуша.
Для нових користувачів
Дашборд показує, що потрібно готовому агенту, тож вони знають, з чого почати. Налаштування тепер там, де їх очікують знайти.
Для продукту
Тепер люди формують свого агента в розмові з AI-асистентом, а UI використовують, щоб бачити, що змінилося. З іменами, аватарами й характером створення агента почало відчуватися як поява нового колеги.
Висновки
01
AI-асистент виявився найбільшою зміною. Користувачі перестали клікати по формах і почали просто говорити чату, чого хочуть. Чат міг зібрати для них агента повністю або провести їх через процес запитаннями. UI став місцем, де видно, що змінилося.
Те саме ми бачимо і в інших наших продуктах: чат стає головним інструментом для створення. І це розв’язує проблему, з якої почався цей проєкт. Поговорити з чатом набагато простіше, ніж читати гору документації.
02
На Етапі 1 я міг би провести глибше дослідження. Але, чесно кажучи, найважливіші інсайти з’явилися лише пізніше, коли більше реальних користувачів почали створювати агентів. Невеликі ітерації допомогли нам рухатися швидше й відшліфувати UX краще, ніж це зробив би один великий редизайн.
03
Після релізу нового UI я помітив, що картка Flow builder на дашборді стала майже зайвою. Тепер MCP покривають більшість каналів та інструментів. Тоді додати її не було помилкою, але це показує, як швидко все змінюється з AI. Дизайн має бути готовим відпускати функції.
Продуктовий дизайнер
© 2026 Віталій Дудка